I'm developing an add-in that integrates with a product of the company that i work. So to use the add-in the customer need to have a system login which Microsoft would not have.
What are the guidelines for submitting an add-in of this nature?
Must i indicate something in the manifest file?
<Hosts>
<Host Name="Workbook" />
</Hosts>
<Requirements>
<Sets DefaultMinVersion="1.2">
<Set Name="ExcelApi" MinVersion="1.2"/>
</Sets>
</Requirements>
<DefaultSettings>
<SourceLocation DefaultValue="" />
</DefaultSettings>
It sounds like our Enterprise policies may be applicable to your scenario. Please see this blog post for more information.
When you are ready to submit to AppSource, you will need to ensure you provide a system login in the test notes to ensure the validation team can fully test your submission.
Related
I have an application running on B2C as part of customer deployment we federate with the customers AD so they can log in with their own corporate identity.
We then create matching groups in the B2C to control behaviors in the app.
We have a request that a customer wants to create the groups in their AD and then pass it across so that they can manage their users and access in one place.
I can see how I can add the claims I want when setting up a user flow but I cant see any option for groups. Is it possible to do or do i have to query the external AD (matching the way I query for groups in the B2C directory)
Thanks
While technically possible, I still have question for the benefit of doing this.
I will try to briefly describe how this would technically work. If not clear - I will have to summ-it on Github. This is only possible using custom policy. So you have to follow: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-technical-profile
Edit the Menifest of the application registration in federated AAD. There you have to indicate that you require group membership claim:
"groupMembershipClaims": "All",
Extend the claims schema in your custom policy extensions by adding a new claim:
<ClaimsSchema>
<ClaimType Id="idpGroupMemberships">
<DisplayName>Group Memberships in the IdP</DisplayName>
<DataType>stringCollection</DataType>
<UserHelpText>This is read only for the user</UserHelpText>
</ClaimType>
</ClaimsSchema>
Later in the technical profile, copy the incoming groups claim into your outputclaims:
<OutputClaims>
...
<OutputClaim ClaimTypeReferenceId="idpGroupMemberships" PartnerClaimType="groups" />
</OutputClaims>
Finally, you have to include that new claim in your relying party policy:
<RelyingParty>
<DefaultUserJourney ReferenceId="SuSiLocalFbStaykovNet" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="OpenIdConnect" />
<OutputClaims>
...
<OutputClaim ClaimTypeReferenceId="idpGroupMemberships" />
</OutputClaims>
<SubjectNamingInfo ClaimType="sub" />
</TechnicalProfile>
</RelyingParty>
Using this approach you will get the Groups as GUIDs (these will be the objec IDs of the groups in federated AAD). If you want to get the Groups as names and not GUIDs, it is only partially supported and more complicated. Check out this doc here: https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-group-claims#configure-the-azure-ad-application-registration-for-group-attributes
Not exactly an answer but some insight why this might be useful.
While technically possible, I still have question for the benefit of doing this.
I have a smaller organization and a public facing B2C offer and a management UI that handles the customer requests. Some sensitive data is on an internal SQL server and we have for historical reasons and some elder software an on-premise AD. I have now running AAD B2B with hybrid connection and SQL via hybrid connection. Customers running on B2C. Because it's technically just one app, it's also just one login --> ADB2C with a social IDP pointing to AADB2B, that internally is backed by the on-premise AAD.
That all works very well and is exactly what we need. I came here with the same question as the OP to forward the security group information to the token to handle some access restrictions in the management UI.
Hence, for me the scenario makes absolutely sense. Just my 2 cent.
Within a single Azure AD B2C Tenant I have a directory of Users. Also, I have 2 Applications registered. Call them App1 and App2.
Assume that a User has registered his/her Account coming from (and being redirected back to) App1, now that the user is in the common User directory, he/she could also sign in to App2 and I can't do anything about it.
It doesn't make much sense to me, and I need to restrict it. How can I control which Apps the Users can access? A User could have access to any amount of registered Applications. I can't seem to find that in the Azure Portal...
Of course I can apply any solution also on App side, e.g. by checking some claim or something, but still, I need to know how to manage such restrictions. (this could be a fully custom way)
You would have to implement in B2C exactly what you said you'd implement in the app
by checking some claim or something
Apart of your B2C user journey you would introduce a precondition to check whether a claim exists or equals a certain value. This would require custom policies. There isn't an easy way to "error" out, but you could create a self asserted page that just shows an error message with a dummy input claim.
You're much better off building this logic in your application.
<OrchestrationStep Order="3" Type="ClaimsExchange">
<Preconditions>
<Precondition Type="ClaimEquals" ExecuteActionsIf="false">
<Value>app_permission</Value>
<Value>portalapp</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
</Preconditions>
<ClaimsExchanges>
<ClaimsExchange Id="AppRestrictionExchange" TechnicalProfileReferenceId="TechnicalProfileHere" />
</ClaimsExchanges>
</OrchestrationStep>
I was told that Tableau server requires these 2 SingleLogoutService elements below that are not in the SAML metadata from Azure AD. If I add these, it works.
Is it supported to manually add these?
Is there a plan to add these in the future to the metadata on AAD?
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.microsoftonline.com/f4094948-32fb-4c4b-b659-63b99f22a08d/saml2" />
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://login.microsoftonline.com/f4094948-32fb-4c4b-b659-63b99f22a08d/saml2" />
WE never heard this as a requirement from the Tableau side. Can you please specify that you are using Tableau server or cloud version? If this is server then which version of it?
You can add more Logout URLs int he metadata as you need but note that Azure AD does not support SOAP biding or Redirect binding for SAML Logout. Only POST biding is supported.
i have implemented the Form Based Authentication for my Report Server(SSRS),
now my question is how to remove authentication for a single report.
i have deployed one report in the report server and i want to view it from external network without asking any username/password for that particular report..!
if i gave <authentication mode="None" /> in web.config file this will remove all the authentication which i don't want.
i tried this also but it's not working
https://www.linkedin.com/pulse/ssrs-anonymous-authentication-problem-solved-frans-van-der-geer
please help..
The default behavior of a DNN installation is to prevent users from saving their account credentials in their browser.
I believe this is done by changing the ID of the credential input controls on the login page(s), but I am not sure.
Is there a setting or common method for fixing this so that users can save their credentials?
Edit: I'm not talking about the separate issue of whether a user's session is "remembered" by clicking "remember me". I'm just referring to enabling web browsers' login/pw storage. It can't be too horrible to enable if Amazon allows it.
It's actually done by setting an autocomplete=off attribute on the textbox. I don't believe that this is exposed through a setting (i.e. the only way to change it is to change the control that your authentication provider uses, which is a fairly big undertaking).
EDIT: After reading further on this, it seems this solution is less secure than the one provided here.
If you are talking about the issue where remember me doesn't work, you just need to make a simple change to your web.config file. Just increase the value of the timeout setting in the authentication -> forms section it's also a good idea to add slidingExpiration="true"
<authentication mode="Forms">
<forms name=".DOTNETNUKE" protection="All" timeout="10080" cookieless="UseCookies" slidingExpiration="true" />
</authentication>