When using ADB2C for authentication in a Blazor Webassembly project, the authentication/logout seems to log out and shows a page with the request to close all browsers.
Anyway if the user just uses the back button in the browser she/he is still able to access the contents and is treated as still loged-on.
So, how to get a real logout?
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.
To sign out the user, redirect the user to the end_session endpoint that is listed in the OpenID Connect metadata document(example) :
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Fjwt.ms%2F
Reference: Azure Active Directory B2C: Web sign-in with OpenID Connect
Related
I'm having trouble understanding how the Principal information is sent in the authentication request to the IDP (e.g. Azure AD) during the SSO authentication process.
I checked the AuthnRequest example shown in this Azure AD article, but it doesn't contain any information about the user that needs to be authenticated:
https://learn.microsoft.com/en-us/azure/active-directory/develop/single-sign-on-saml-protocol
If the user information are not included in the authentication request, can anyone explain to me how the IDP will identify the user in this case?
The AuthnRequest is a browser redirect to the Azure IdP. The Azure IdP doesn't know who the user is either. So it displays an Azure login screen in the browser. The user then logs in to Azure (now Azure knows who the user is) and the Azure IdP redirects the browser to the AssertionConsumerService (ACS) URL of the SP with the SAML AuthnResponse from the IdP identifying the user.
The next time the user's browser is redirected to the Azure IdP by an AuthnRequest, Azure looks at the cookies and knows the user has already authenticated and immediately redirects the browser back to the ACS with the SAML AuthnResponse.
The AttributeStatement in the AuthnResponse identifies the user if the IdP has agreed to release personally identifying information about the user to that SP.
Of course, if the user does not have an account in Azure they cannot login. Azure will know who they are from their login information, which is usually their userPrincipalName, which looks like username#example.com.
As the comment suggests, the username can be in the AuthnRequest but this is not often used. The SP should not ask for the username as the username "belongs" to the user (although ultimately it "belongs" to the IdP) and the IdP may not be willing to release that information to the SP. If the SP doesn't need to know who the user is, just that they have permission to access the service, then username is irrelevant. Permissions are often granted based on the Attribute set in the AttributeStatement and this can be done without the SP ever needing to know the username of the user.
If the SP supports personalisation, such as preferences for a user, not knowing the username isn't an issue. A SAML attribute such as eduPersonTargetedID can be released by the IdP that has the same value for that combination of IdP/SP (to stop cross-service tracking) and the SP can use that to store preferences for the user without ever needing to know the username.
A common way of using SAML is to replace a username/password login screen with the SAML flow:
user goes to https://app.com
app sees the user isn't authenticated (no cookie, session or whatever). This is when a non SAML app displays a login screen.
app redirects user to their IdP. Easy in the case of a single IdP. app does not use Subject in AuthnRequest.
user's IdP displays the login screen for the IdP.
user authenticates at IdP
IdP redirects browser to the app's ACS URL.
app inspects SAMLResponse, looks at the Attribute set and decides whether the user (still possibly anonymous) can get access.
if, e.g. user has an Attribute "eduPersonEntitlement" with a value "http://app.com/entitled" then app creates a session for the user and "logs them in" to app.
when user's session at app expires, app sends them back to their IdP to see if they are still entitled to access the app.
In azure ad portal, after registering the application through enterprise application blade,we assign users and groups for the application .
we can perform single sign on configuration settings where we give
redirect urls , upload saml certificate.
SAML tokens contains information about the user known as claims. A
claim is information that an identity provider states about a user
inside the token they issue for that user. In SAML token, this data
is prsented in \ SAML Attribute Statement.
By default, the Microsoft identity platform issues a SAML token to
your app that contains a NameIdentifier claim having value of the
username ( user principal name) in Azure AD, which can uniquely
identify the user. The SAML token also can contain additional claims
like user’s email address, first name, and last name which can be
configured in a section Attributes and claims , which are included in
token .We can edit this section according to the claims required for
the application about user principal.
References:
SAML 2.0 token claims reference | Microsoft Docs
azure active-directory-saml-claims-customization(github.com)
sample reference:SAML_Token_Configuration
i have a relying party application(web application) registered in AAD B2C and i am inviting the users to my groups in my tenant, for that, i sent the invitation url to them and user signup/sign in and enter in my application.
this process works perfectly if i test this flow in incognito window, but it saves my (inviter) credentials and on even clicking the invitation link this link dont sign up with the email mentioned in invitation rather it signs in with the already signed in(inviter) account.
any help would be much appreciated.
This is the normal behavior. When a user successfully authenticates with a local or social account, Azure AD B2C stores a cookie-based session on the user's browser.
It is not expected that the invitee will be using the same browser as the inviter.
You do however have some options in configuring session behavior: https://learn.microsoft.com/en-us/azure/active-directory-b2c/session-behavior?pivots=b2c-user-flow#configure-azure-ad-b2c-session-behavior
For instance you can disable KMSI so that a persistent cookie will not be saved in the browser. That means users have to login every time the browser is restarted. But it resolves your problem. In any case, you should work under the assumption that invitees will open the invite link on their own machines with their own browsers.
I have a single claims provider in my Azure B2C custom policy - an SSO with our Azure Active Directory (AAD).
I can see that when there is only a single claims provider then B2C does not bother with presenting the B2C login page with only one button - rather it takes you directly to login with the only provider you have configured.
This presents me with the following problem because I, and many of my Company's users, am automatically logged in to the AAD. When I log out of the application that is secured by B2C the logic is to return to the B2C login page but instead it straight away logs me back in again.
What I would like is to log out and be presented with the login screen, rather than automatically being logged in again. I can change the app so that on logout you are actually redirected to a "you have been logged out" page, but this is not desirable.
How can I "force" the login page to show even though there's only one option available to the user?
In OpenID Connect you add prompt=login to force authentication when redirecting to the B2C Policy.
There is an equivalent parameter for SAML. I don't know if the built-in flows will propagate this, but if you are doing custom policy you certainly can go back to the federated identity provider and force authentication again.
See the prompt parameter here: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc#send-the-sign-in-request
I have created azure ad b2c custom sign-in policy with KMSI(keep me sign in) option, and using it in blazor server application,
But automatic sign in not working after browser close, Need to click 'Login' button.
After click login button no need to enter credential again, if at the time of previous sign-in KMSI check box checked.
But I want to sign-in automatically if at the time of sign in KMSI check box checked.
Could you check the authorization request the app sends to Azure AD B2C, whether it contains the prompt=login query string parameter? If yes, please make sure to remove this param.
This is expected, your app cookie is not persisted, so the app has no idea you’re still logged in at B2C. Therefore you have to click login in the app and then you get SSO through AAD B2C.
You could maintain a cookie set by the app to automatically send the user via the login endpoint if they had signed in previously with KMSI. You can use a claims resolver to send the KMSI claim into the token so your app can understand the user logged in with KMSI.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/claim-resolver-overview
I tested KMSI functionality on my side, and I can repro your symptom. My test is based on this demo: https://github.com/Azure-Samples/active-directory-b2c-dotnet-webapp-and-webapi
This is my test process below:
Registering a local account.
Login by this account, and enabled KMSI
I logged in successfully:
Close the browser, reopen it and got to my app index, my index page is allowed to be visited by anonymous, so it not knows who am I: I think this is the issue that you are concerned about:
But when I click “Claims” tag which users are needed to be authenticated, it redirected to my b2c domain :
As I enabled KMSI, so there is a cookie under my b2c domain:
As this cookie exists, B2C will provide me with the resource I requested for: b2c side sends a request to redirect URL with id token and code :
Finally, it redirected to “Claim” page and this app knows who am I :
In a word, there are two kinds of sessions here: a session between user and B2C and a session between the user and your application.
Once you close your browser, by default, you will lose the cookie that user on your application, so users access to some page with no auth needed of your app after reopening the browser, there will be no cookie, your application not know the user. But on the B2C side, this cookie will be persisted there due to KMSI. Only users request some functionality needs to be authenticated on your app, users will be redirected to the B2C domain and B2C will send users’ information to your app will make KMSI work.
In my opinion, maybe extending the lifetime of your application cookie will be a solution here. At the same time, you also need to expand session timeout to make sure that your application could recognize that long lifetime cookie. But as we know, it will be a high consumption for server RAM if it holds lots of sessions.
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