I'm setting up an SSO solution using Azure AD and the IdP, using SAML2 token Authentication.
Our Service providers are both on premise and off premise applications. Although I understand the principles of SSO in these environments, I need clarity around SP Initiated SSO.
When an end user, who is working from home using their personal PC, tires to access an off site application, via a URL, how does the SP recognize, or identify which IdP it should redirect their browser to for validation?
SP Initiated has the flow:
User --> application --> IDP --> authenticate --> back to application with token.
The application is configured for the IDP URL.
The SP would have previously been configured (by administrators, developers, etc.) with information about the IdP. One of those pieces of information is the "Login URL", which is the IdP URL to which the SP should send the authentication request.
The IdP would also have been preconfigured with information about the SP, for example, where to send the IdP's authentication response (a.k.a. "assertion") containing information about the user. (That is known as the "Assertion Consumer Service")
In an SP initiated flow SP simply does not redirect the user to IdP , but accepts the user credentials and makes an authentication request to IdP.
An SP would set the IdP url in it's code or configuration based on the implementation it chooses.
You could also exchange metadata file between SP and IdP.
A meta data file is nothing else but an XML file which tells the basic Organization , poc and URL info. So you could ask for SP meta data for your IdP to recognize SP and SP could ask for your IdP's meta data to identify you when an assertion reaches there.
This site provides a good understanding of how a meta data looks like :
https://www.samltool.com/online_tools.php
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
We have configured OKTA as an IDP in Azure AD. While testing the IDP(OKTA) authentication flow, it throws error.
Configured Okta & Azure AD using below microsoft link as reference.
https://learn.microsoft.com/en-us/azure/active-directory/b2b/direct-federation
What we did so far?
Registered company "example.com" in OKTA.
Created a custom SAML app in OKTA to export the OKTA IDP metadata
Configured the app SSO settings as above reference link
Imported OKTA metadata as external IDP in AzureAD
Followed below steps to test IDP Authentication Flow
Logged in with the existing user in OKTA
After successful authentication, user is redirected to dashboard page
Here, when we click on custom app chiclet, instead of getting redirected to Microsoft apps portal, it throws below error -
AADSTS50107: The requested federation realm object 'http://www.okta.com/xxxxxxxxxxxxxxxxxxxx' does not exist.
i think direct federation doesn't support idp initiated login, you need to login using tenant context.
have you seen that note in the link you pasted ?
Direct federation guest users must sign in using a link that includes the tenant context (for example, https://myapps.microsoft.com/?tenantid= or https://portal.azure.com/, or in the case of a verified domain, https://myapps.microsoft.com/\.onmicrosoft.com). Direct links to applications and resources also work as long as they include the tenant context. Direct federation users are currently unable to sign in using common endpoints that have no tenant context. For example, using https://myapps.microsoft.com, https://portal.azure.com, or https://teams.microsoft.com will result in an error.
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.
I am setting up basic SAML support for a web application. Each user this application (identified by email address) can belong to multiple organisations/companies of the application. I would like to let individual organisations to enable SSO via SAML for users that are members of their organisation.
The communication between me (the SP) and the Idp (e.g. Okta, OneLogin) works just fine from the technical side. But I haven't figured out how to ensure that a user requesting access to my application via SAML is actually the user who she pretends to be, given that she might have signed up for a user profile before SAML was enabled for the organisation.
Is there some sort of "linking" that needs to take place in order to "connect" an existing user profile with a specific Idp?
An IdP contains a set of user identities. When your SP and IdP exchange its metadata, you set a circle of trust, so all users that the IdP contains will be trusted by the SP.
Some IdPs has the ability to restrict what users access what SP, or the ammount of information of a user will be send to the SP, but at the end, you as SP may trust all the info that the IdP provides.
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