I want to do some automated tests of a web app (web api) in Azure that is secured with AAD. The customer is using on-premises AD to synch users and groups to AAD and is using ADFS to authenticate the users. This is enough, I believe, to stop me from using UserPasswordCredential to programmatically sign in a test user. So I have asked the customer to create me some cloud-only users that will be used in the automated tests. But we can’t add these users to the AAD groups, presumably because they are synched back to on-premises AD.
The web app is designed to check if its users are in a particular AAD group, but my test users can’t be in that group, so we may have to modify the app to check for multiple groups instead, and put the cloud-only tests users into a cloud-only group, so that we can add the cloud-only group to the list of groups allowed to call the web app.
Is this the best approach, or am I missing a better solution?
UsernamePasswordCredential is meant to work with ADFS via federated tenant, as long as the proper endpoint is enabled in ADFS.
Related
I am setting up an SSO Enterprise APP in Azure AD and there is a feature called provisioning which requires a Scim endpoint for Azure AD to sync users between the SAAS app AD in "real-time"
The application grants access to a user based on the groups the user belongs too. This works well when SAML is used because i can include the groups as part of the SAML request, but i am having a lot of trouble mapping the groups in the Scim call, using the Provisioning functionality, so that the user does not need to launch the app to be provisioned.
Is there a way i can map the groups a User belongs to as part of the provisioning call?
I have tried mapping different values in customappsso config with no success.
Azure AD Provisioning manages group objects directly and populates values into each group's "members" attribute. The SCIM protocol does not allow manipulation of a user's group memberships via updates targeted to the user itself.
You should just need to ensure that your SCIM endpoint supports calls to /groups, that you have groups enabled in provisioning, and that the groups are assigned/otherwise in scope for provisioning in the AAD app.
I want my application to be able to use an external user pool from my customers Azure AD, instead of them having to maually create every user in my application, when they already have them in Azure AD.
Initially, I though of using only OIDC for this as I can just create the user in my application upon the first login. But OIDC does not allow me to logout and deactivate the user in my application when they are deleted in Azure AD. This is an important requirement for my application.
To solve this, I think I could combine OIDC and SCIM:
Azure AD provisions the users to my application through SCIM endpoints. When deactivated, Azure notifies my application through the SCIM endpoints and I can delete their session and deactivate them in my application.
Login is handled with OIDC. When I have a valid OIDC token I create a session in my app. This way I don't have to manage passwords or multi factor authentication in my app.
Does it make sense to use SCIM and OIDC together?
Yes, it makes sense to use SCIM and OIDC together in the way that you describe.
It also has other advantages to "pre-provision" with SCIM: for example, when users want to address accounts other users that have not logged in yet. Adding such a user to a group would not work with "just-in-time account provisioning" since the account would not exist (yet).
I am doing login from Azure AD.Client is SPA(angular using MSAL). If user is not Authenticated, it redirect to Microsoft Login Screen (using MSAL). On successful login, it return an access token.
My roles will be stored in a database. I need to add the roles of that user as part of claim in access token. I am not finding the way to do it.
I do not want to make another call from SPA to API to get the DB roles.
Please suggest some good approach.
Any links explaining the approach will also be very helpful.
I am still in design phase but not able to find the best approach.
In one microsoft site, i found that we can fetch the roles from DB but details were not there.
most of the places, it is written that we need to provide roles in Azure AD users menifest file.
In regular Azure AD, the "roles" claim is exclusively sourced from app role assignments for the signed-in user (or groups the user is a member of), to the app roles for the app the user is signing in to.
There's no feature currently in Azure AD which will connect to an arbitrary database, make a database query in the appropriate form, and include the results in the roles claim in the resulting ID Token.
I can think of three options to achieve your scenario:
After sign-in, call an API to retrieve the roles. Though you mention this is not desirable, it's probably the simplest approach, so it's worth listing. As a result of the user's sign-to you app, you app will usually obtain an access token to an API. If you set up your API to be secured with Azure AD (directly, or through Azure API Management), your SPA could simply get the necessary access token as part of sign-in, and at that point it's trivial to make a REST call to retrieve the role details for the user (and possibly other information useful to rendering your app).
Synchronize (or copy) your role information from your database to Azure AD. For each role, create an app role in the Azure AD app registration. For each user-role association, either create an app role assignment to directly assign the user (user -> app role), or assign a group to the app role and add the user to the group (user -> group -> app role. Keeping this in sync is probably not trivial, so if your scenario allow to move the role information to Azure AD app role assignment, you can forget the database entirely (making Azure AD the authoritative location). Of course, this might not work for your specific case.
Use Azure AD B2C and a custom sign-in policy. You could create an Azure AD B2C tenant, set up a custom sign-in policy to use your (regular) Azure AD tenant as the identity provider, and configure the policy to enhance the claims by calling a REST API to retrieve your roles. In this approach, you still need to have a REST API which can provide the role information, so rather than doing the setup and migrating your app, you may prefer simply calling the API from your SPA (option 1, in this list).
I am developing a multi-tenant Office 365 daemon that requires access to user calendars.
I have successfully registered in the company tenant (Tenant1) that has deployed this app using certificates and I am able to get access tokens.
Now I created a separate AAD tenant (Tenant 2) and logged in to daemon app using administrator account of Tenant 2, it prompted the Admin Consent screen and I provided consent. There was no errors returned.
When I tried to get an app token however, I am able to get a token but with blank permissions. If I call the Office 365 API using this token, I get a 401.
I was of the view that service principal objects should be created. Also I am unable to see this app in Tenant 2 app registrations.
Do all my consumers have to register this app manually in their AD tenant and modify application manifest file to add certificate details?
I am not sure about the benefit of multi tenancy if that's the case.
I found the follow in the Azure Active Directory documentation:
The following diagram illustrates the relationship between an application's application object and corresponding service principal objects, in the context of a sample multi-tenant application called HR app. There are three Azure AD tenants in this scenario:
Adatum - the tenant used by the company that developed the HR app
Contoso - the tenant used by the Contoso organization, which is a consumer of the HR app
Fabrikam - the tenant used by the Fabrikam organization, which also consumes the HR app
You do not need to have each tenant register your application. In fact, you shouldn't since having dozens (or hundreds) of unique App IDs floating around would only create headaches for you.
Each tenant does however need to execute the Admin Consent workflow. This will authorize the App ID you've registered on your end to access the scopes you've requested.
Generally, I recommend using the v2 Endpoint and the apps.dev.microsoft.com portal for registering your app. While you can also register your app in your own Active Directory, the portal makes it a lot easier to manage.
The general process is:
Register you application in the Registration Portal
Populate the "Application Permissions" in the Microsoft Graph Permissions section.
Launch the Admin Consent workload using https://login.microsoftonline.com/common/adminconsent?client_id=[APPLICATION ID]&redirect_uri=[REDIRECT URI]
Get a beer
A couple of tips:
The Registration Portal only supports MSA (i.e. personal) accounts at the moment. I'd suggest creating a new Outlook.com account for this purpose so you can easily share the credentials with folks who need them internally.
If you create a shared Outlook.com account, you should also set up forwarding rules for all of the interested parties internally. This is in case something should every go wrong or change down the road and you need to recover the account.
I wrote a v2 Endpoint and Admin Consent primer that you might find helpful. They assume you're using the Authorization Code flow but the concepts remain the same for Client Credentials.
We have a multi-tenant Saas application providing sign in using our username/pwd authentication system and using Azure AD (OAuth 2.0 flows). When a user signs in using Azure AD, we can get the user's profile using https://graph.windows.net/{tenantid}/me. We want however to get more information using the memberOf or getMemberGroups operations to retrieve the user's groups in the tenants directory, to map specific groups from the tenant to an organizational structure in our application. However these operations always fail with a Forbidden statuscode. Are we missing required permissions or is it just not possible to query for the groups and roles of another tenant.
Thanks in advance
This is totally possible, but today requires that you request the "Read Directory" permission. This permission does require and admin of the tenant to consent. We are looking at adding some additional fine grained permissions for Graph API that will allow users to consent (to get group membership information).
Another option for you is to configure your application to request group membership claims (which should appear in any user or JWT token). You can do this by going to the azure management portal and getting to your app's config page. From there download the application manifest file and update the groupMembershipClaims property. You can see most of the properties in the application manifest described here: https://msdn.microsoft.com/en-us/library/azure/dn151677.aspx. Once updated, you can upload this app manifest file, and this will configure your application accordingly. Once done, AAD will issue group membership claims in the token. Dushyant has written a nice blog about authorizing access to a web app, using group membership claims or app roles. You can find it via Alex Simons blog post here: http://blogs.technet.com/b/ad/archive/2014/12/18/azure-active-directory-now-with-group-claims-and-application-roles.aspx
HTHs