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).
Related
I've got a single page application that currently uses Azure AD B2C authentication to allow users to sign in, and then use the auth cookies to talk directly to internal services. There is now a requirement that we use two factor auth on top of the existing AD auth. We've already rolled our own 'second factor' auth, and we need to be able to integrate with that (I'd much rather use the built in MFA that Azure provides, but for this question assume that isn't an option).
Our issue is that we don't want to call our MFA service until the user has authenticated succesfully with AD - but of course, once they have, they are already authenticated, and it's too late.
When Azure AD hands back to us via the call back (we are using CookieAuthenticationEvents), is there any way to defer the access token being available until our own second factor auth step succeeds?
Just as juunas suggested, try to use custom polices which are designed primarily to address complex scenarios.
Reference:
Custom policies in Azure Active Directory B2C
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 working on an ASP.Net MVC application which will handle two types of users
External Users (Need to authenticate using Azure B2C with username as login instead of email as login)
Internal Users (which already exist in Corporate Azure AD)
What is the right way of implementing it?
One option is to run two separate instances of the application configured against each IDP. Keep each type of user stick to one app instance.
I tried to register AD and AD B2C in one app by registering two OpenIdConnect services but having problems when the user tries to access a resource without first logging into the application. Without knowing the type of the user I cannot specify AuthenticationSchema in the Authorize tag.
I am sure people have done this before so if you someone who knows how to do it, then please guide me..
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.
I'm currently trying to implement a multi-tenant Azure AD application that will use Microsoft Graph API's to monitor and analyze Office 365 "metadata" for members of the tenant domain. For example, the application might monitor One Drive user space over time. The architecture of the application will include an AngularJS SPA client along with a web application back-end. The idea is that the web application allows for both local registration (e.g. traditional sign up using an email address and password) in addition to Azure AD authentication. In the case of local registration, the user might be able to associate an Azure AD tenancy with the local account in the future, for example.
I'm struggling to understand how various authentication mechanisms should work. For example, I think that there should be two levels of authentication in the case of Azure AD: one authentication for the users of the client SPA, and another authentication used by the back-end for making continuous calls to the Microsoft API's, requesting refresh tokens, etc.
How might this architecture be implemented using the various Azure AD authentication scenarios Microsoft has already provided examples for?
If my initial inclination that I will have two applications registered with Azure AD (for example, the SPA registered as a native application, say, and the web application registered by itself), how will users allow access to both of them, and what would this workflow look like? In addition, what would the flow of user requests look like? The SPA would make a request to the back-end using its Azure AD token, but what will the back-end do to receive its authentication token and make calls to the Microsoft API's?
How might I best incorporate Azure AD authentication along with local registration into my application?
Generally speaking, you can associate your each user to his entity in Azure AD tenant in your backend server / database. As every user in Azure AD has several unique properties in the entity object. You can use the user's email or objectId as mentioned at Claims in Azure AD Security Tokens as the external column in your user table.
When your user authenticate your site via ADAL.JS, you can grab the access token in your backend server via the Authentication header. You can use the access token to request for the resources protected by Azure AD. And the access token is a JWT token, which you can decode directly to get the user basic claims as we mentioned before. You can retrieve the claim which you stored in your user table and match the special user registered in your server for requesting the resource protected by your self.