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
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 one application integrated with Azure B2C directory. Our problem is, login page is redirecting to Azure B2C portal (Own custom page) for authenticate or Authorize users and then revert back to the original website.
I need to open popup with my own website login design and at the backend, I am able to call Azure B2C REST api to validate users.
How I can create REST API for Login in Azure B2C portal?
Let me know if you have any information about the same.
As juunas said in the comment, you could use resource owner password credentials(ROPC) flow to validate users at the backend. You could call the API with the POST request at the end. Note: ROPC supports local accounts only.
Try to create resource owner user flow first.
You need to replace the username and password with the user's to be verified.
POST https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/B2C_1A_<ROPC_Auth name of the flow>/oauth2/v2.0/token
username=<username>
&password=<password>
&grant_type=password
&scope=openid <application-id> offline_access
&client_id=<application-id>
&response_type=token+id_token
I have a 2 application using a single AD B2C tenant. I want to logout the user from both websites when the user signs out to either one of them. I'm using email for local accounts.
In AAD, there is a LogoutUrl registered on each application which receives a GET request to users currently signed in to. Source
I wonder if there is workaround for AD B2C like in AAD.
PS: I am using this repo as reference.
Azure AD B2C doesn't support Single Log Out and we weren't able to find a workaround.
I've understood that in B2C scenarios Microsoft has assumed that IdPs are "social-media" type and considered it is not of end-users interest to be logged out of Facebook when they log out of some service to which they've authenticated via Twitter. Makes sense in that scenario.
However, in government-provided IdP scenarios it is usually a hard requirement to be able to support SLO.
We considered it to be more of a limitation by-design in B2C than technical, so we moved to using another authentication service provider that supports SLO. Apparently a wise choice as I haven't at least heard anything regarding SLO and Azure B2C as of today.
According to the documentation that is possible:
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.
The suggested answer was from 3 years ago.
Please have a read here.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/session-behavior?pivots=b2c-custom-policy#single-sign-out
Apparently, B2C does support single sign out, but I could not get it to work despite following the steps and I'm looking for answers on SO.
I am not sure if I am asking this question correctly or not, but if a user is authenticated through MS Azure, can Azure send the identity of the user to another system through HTTP header variable?
If so, what if the HTTP server on the other system is Apache based and not IIS. Is it still possible? If yes, how is it done?
Thanks
The closest option available in the Azure AD offerings is Header based SSO.
Header-based single sign-on works for applications that use HTTP
headers for authentication. This sign-on method uses a third-party
authentication service called PingAccess. A user only needs to
authenticate to Azure AD.
If you could expand your question a bit more, maybe we can help with a better answer
So the flow as I understand is like follows..
Salesforce redirects the user to Azure AD
Azure AD authenticates the user (uses SAML) and sends the SAML token back to salesForce
The user who signed in to SalesForce now redirects to a Siebel App?
The expectation is that the user would not have to authenticate again for Siebel?
The quick answer is that Azure AD will authenticate the user using header-based, SAML or OpenID only if the Siebel app is registered with Azure AD.
Without registration, Azure AD has no knowledge about this app (Siebel) and wont deal with it.
During registration, Siebel developers can choose if they want to use SAML, header based or OpenId for authentication and Azure AD will automatically Single sign-on an already signed in user (like in this example the user has already signed-in to SalesForce) to Siebel and wont prompt the user for credentials.
This question is related to
passport-azure-ad, does it parse & validate token?
I've tried to master using the passport-azure-ad module. I successfully log in my user with OpenID Connect, pick up the access_token and use it directly my REST API's which are secured by app.get('myapi',passport.authenticate('oath-bearer',
{failureRedirect: '/'}),
function(req,res){});
However, if i try to log out from the session created by OpenID connect, the token is still valid untill it expires (typically 3600 seconds).
I'm using the access_token to secure my endpoint not hosted behind a API Gateway at Microsoft, so i guess revocation of the access_token is not straight forward.
Is there any way i can check if the access_token is revoked using passport-azure-ad ? What is the best practise?
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
As if you are using a common Azure AD application in v1, you also can find the end_session_endpoint in the metadata document at, e.g.:
https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/.well-known/openid-configuration
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.