I've implemented SSO using SAML authentication on Asure AD in my banking application. I have a scenario where I've to let a manager/supervisor log in to approve a transaction. A regular rep would not have authority to approve, the manager would come in and physically login in (keeping the rep's session intact) and approve a transaction and then logout. Is it possible to have multiple sign ins in the same browser instance through Azure AD?
UPDATE - Per what I researched and mentioned by Carl as well, Azure AD does not support multiple users to login in an application in the same browser instance.
Yes, in the same tenant, users with different roles can perform multiple logins in the same browser. Log in to the Azure portal and you can see that accounts with different roles in the upper right corner can be switched back and forth.
These identities have already validated their credentials for this session, and have an auth token. Switching between these accounts now will not prompt you for their passwords again.
Update:
Even if two accounts are in the same domain, they cannot be logged in at the same time. Currently, only two browsers can be used for two accounts in the same domain.
SAML SSO is a form of delegated authentication. The user is authenticated at the identity provider site (eg Azure AD) which sends a SAML assertion containing user identity information to the service provider site. The service provider trusts this information and establishes a local authentication session for the user using the information contained in the SAML assertion. SAML assertions often contain the user's email address but any user identity information may be included.
You can achieve multiple sign-ins on the same browser , Kindly check this link.
Related
I'm designing a single-page app (SPA) and API that will support multiple tenants, including in the same client browser. Imagine an experience similar to the Azure Portal, where users can switch between identities that they have signed into Azure AD with, except that in this case I'm using Azure AD B2C. All sign-ins happen via a single Azure AD B2C instance. Importantly, the tenants do not necessarily have to be aware of each other since they are white-labeled -- the user might be redirected to https://multitenant.app/tenantA and sign in via B2C, and have a totally different experience when directed to https://multitenant.app/tenantB and signing in via B2C there. The two tenants do not need to share data between themselves on the client.
How might I go about:
1) designing the client so that requests to https://multitenant.app/tenantX are directed to Azure AD B2C in a way that enables sign-in using the rules for tenantX, and
2) designing the client so that the MSAL.js library correctly provides a token store containing tokens specific to tenantX when the user has navigated to https://multitenant.app/tenantX in the browser?
Currently I'm expecting to need to intercept requests to the backend API on the client, determine if a redirect to B2C is necessary first in order to sign in to the tenant that the request is for, and attach the appropriate access token for that tenant to the API request. (All this is assuming that I use the Implicit Flow so that I have the access & refresh tokens available on the client.)
Does this make sense? Is there a better way? I've debated using session cookies issued by the server so that the browser handles the "intercept-requests-and-attach-credentials" aspect of this, so maybe that's an option that would avoid the need to maintain all these tokens on the client?
And how does this work when the client signs into B2C? Can I tweak/disable the B2C SSO capabilities sufficiently so that a single user agent (browser) can still obtain multiple different tokens (for different identities)?
The approach needs to be a bit different. This is how Microsoft do it with their "tenant picker" in the Azure Portal.
We hold a mapping of in which tenants your account lives in
We then list the tenants in a tenant picker UI in the app
When you switch tenants, we do an SSO authentication to the new resource (ie the selected tenant) to get a token to it
We use the new token to evaluate your rights in this tenants subscription
To translate this in AAD B2C you can:
Hold a mapping of identifier to 'tenant'
On authentication, call your API to get a list of tenants. Use this sample to list the tenants in the authentication flow
The user selects the tenant, or maybe you do it like Microsoft and have a default preference, in which case the step above is skipped using a B2C precondition. This way the user only goes through selecting a tenant in the auth flow once. Afterwards they use an in-app tenant picker (read on...)
The token issued to the user has the tenant inside it as a claim, this will then be used to do authorization when this token arrives are your API.
In the SPA, now render a tenant picker, use the same API as used in step 2 essentially
The user can select a new tenant in the SPA, use id_token_hint (example) to seed a new B2C user journey with the selected tenant. The user will get SSO through this journey and get a new token with the new tenant inside it as a claim.
I saw a post today on linkedIN to say Azure B2B now accepts Google IDs (e.g. people with a Gmail account)
It said this is achieved via Federation, (using google as the identity provider)
As far as I am aware you have been able to do this for a while (or was that because it was in public preview), whereby someone could enter their gmail account but in the background (after the simple on boarding process was completed) this gmail account is linked to a place holder Azure AD account (represented by a GUID).
So in the announcement of Azure AD now accepts google IDs, is this the case where a preview service is now main stream ? or is this something new?
My main question is below
As far as I understand federation (please correct me if I am wrong) although your own Identity provider together with your own STS (secure token service, which is trusted by the replying party) provides you with a token (signed SAML/JWT) with is then presented to the replying parties STS (which then creates is own token from the information in the token you provided), you still need an instance of an object (user/group etc) in the Replaying parties system to check if said instance is allowed access to a resource based on the token (looking at the ACL on the resource and the information in the token). So although the replying party does not need to maintain the users password to authenticate them (done by the trusted Identity Provider) an instance of an object still needs to be created/exists on the Relaying Party system (to match the token information e.g. group membership for example) to the ACL on the actual object trying to be accessed
is the above correct?
Thanks very much
A User is always created in Azure AD, as it is in this case as well.
This applies to users created in Azure AD, synced from on-prem AD, invited from other AAD tenants, personal MS accounts, and now Gmail accounts.
Before Google B2B, if you invited a Gmail user, a personal Microsoft account would be created for them in the background, which would then be added as a Guest in the AAD tenant.
Now if you enable Google B2B, when you invite a Gmail user, they'll log in on the Google login page instead of the AAD login page.
So now instead of creating an MS account invisibly, the Google account itself is added as a Guest User, and AAD relies on Google to authenticate the user.
I am using Azure B2C to connect my own openid connect server using OpenID onnect (Preview) provider. I configured every thing, system is working fine.
But one thing is when a new user logs in through my own openid connect server, Azure AD B2C creates this user in Azure AD which is connected to Azure B2C.
My intention is that, My client application has to call Azure B2C. Azure B2C should display list of identity providers. one among those providers is my own openid connect server. Then user can input his credential in my own openid connect server and verified and return back to Azure B2C with id_token. after this step Azure AD B2C is asking me to create this user in Azure AD. why this is happening ?
I cannot provide my user details to any intermediate systems. Please help me on this.
The same scenario is happening for gmail users also. but only first time login or when we change some signin policy attributes.
Based on my experience, even for externally authenticated users (social sign-in) AAD B2C always creates an object in its local store (which is actually an Azure AD directory). I can't speak authoritatively, but a couple of reasons for this would be 1) the ability to generate and maintain an immutable ID for a user that is somewhat independent of the social IdP, and 2) the ability to collect and store additional attributes which are not available from the social IdP.
I believe you can make the process invisible to your users - they don't necessarily have to be prompted to enter additional attributes or to create a user - but it will still happen in the background.
I have made an Azure AD B2C policy using external identity providers. I want, that when signing out of the app, the user should also be signed out from the external identity provider he used while signup. I read this on Azure documentation here.
As, written here,
While directing the user to the end_session_endpoint will clear some of the user's single sign-on state with Azure AD B2C, it will not sign the user out of the user's social identity provider (IDP) session. If the user selects the same IDP during a subsequent sign-in, they will be reauthenticated, without entering their credentials. If a user wants to sign out of your B2C application, it does not necessarily mean they want to sign out of their Facebook account entirely. However, in the case of local accounts, the user's session will be ended properly
Is there any other way of dealing with this issue, or to do a force logout from Azure as well as from external identity providers ?
Nope. And this how it should work.
You have a wrong way of thinking. When I sign out of your app I would be veeeeery mad at you if you sign me out of Google too (for example).
This can't be done with Azure B2C. Although some people would argue that this is how it's meant to be and that keeping Social IDP's session alive is the expected behavior, I would argue that there are perfectly valid scenarios when this is not the case.
For example, for business apps that run on shared company devices. In our case, workers grab an iPhone from a locker and sign in to the app to do their job for the day. We allow them to sign in using their Social IDP credentials. At the end of their shift when they sign out and next person signs in using the same Social IDP, they will automatically get signed in as the previous user. You can see the problem, right?
I think, it would still be nice to have some way to end the Social IDP's session as well.
I have 3 websites using a single B2C tenant. I have been asked to set it up so that when a user signs out of one website, sign out of them all.
Likewise if their account is deleted.
I thought that I would have to introduce a call to Azure on every request to determine if the user is still logged in, but as far as I can see, there isn't a Graph API endpoint that would allow me to determine the user status.
Am I thinking about this the wrong way? Is there a way to do this easily using B2C, Graph API, the Active Directory client etc.?
Maybe there is an option when setting up the OpenIdConnectAuthenticationOptions for example.
According the description on Azure Document:
While directing the user to the end_session_endpoint will clear some of the user's single sign-on state with Azure AD B2C, it will not sign the user out of the user's social identity provider (IDP) session. If the user selects the same IDP during a subsequent sign-in, they will be reauthenticated, without entering their credentials. If a user wants to sign out of your B2C application, it does not necessarily mean they want to sign out of their Facebook account entirely. However, in the case of local accounts, the user's session will be ended properly.
So you can directly use the end_session_endpoint. You can find it in the metadata document for the b2c_1_sign_in policy endpoint, e.g.:
https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=b2c_1_sign_in
You can refer to Azure Active Directory B2C: Web sign-in with OpenID Connect for more info.
Any further concern, please feel free to let me know.
I might be late. But if that helps. A.c to docs
When you redirect the user to the Azure AD B2C sign-out endpoint (for both OAuth2 and SAML protocols), Azure AD B2C clears the user's session from the browser. However, the user might still be signed in to other applications that use Azure AD B2C for authentication. To enable those applications to sign the user out simultaneously, Azure AD B2C sends an HTTP GET request to the registered LogoutUrl of all the applications that the user is currently signed in to.
Applications must respond to this request by clearing any session that identifies the user and returning a 200 response. If you want to support single sign-out in your application, you must implement a LogoutUrl in your application's code.
This is called single sign out .
Please refer to https://learn.microsoft.com/en-us/azure/active-directory-b2c/session-overview#single-sign-out
Microsoft has an API for this by now. I link to the following blog, as the documentation is currently wrong.
microsoft developer blog: revokeSignInSessions & invalidateAllRefreshTokens
Request
POST https://graph.microsoft.com/beta/users/{id}/revokeSignInSessions
Response
HTTP/1.1 204 No Content