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.
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 an application registered in Azure Active Directory. I use this app registration to provide a simple SSO implementation for my web application. Users go to my application, choose SSO for authentication, redirect to the login.microsoft.com page, then get sent back with the proper codes. No sweat.
The SSO part is not issue inside or outside of my tenant. I've been able to get the proper flow setup and if users are permitted access, they can login with their Microsoft account and access my application.
Email, however, is turning out to be a real issue.
Internal users in my tenant are not a problem at all. Once I get the JWT from Microsoft, I can request an access token for Graph, send emails, create drafts, delete, etc. There is no issue here.
The problem comes up when I have a user in an external tenant. They can login just fine and get a code from Microsoft, but email doesn't work. I started researching a multitenant solution with the Graph API and made some progress there. I was able to change how they request their tokens using 'client_credentials' and got the appropriate delegated app permissions set up but those permissions allow the external tenant to send emails as though they were users in my tenant. Which obviously I don't want.
I have the external users setup as guest users in my tenant. I've even gone so far as to put an Exchange Online license on the guest users account.
This is the latest error I've received:
[error] => Array
(
[code] => ResourceNotFound
[message] => Resource could not be discovered.
[innerError] => Array
(
[date] => 2021-08-09T16:08:41
[request-id] => 76d9c8ad-e2fd-4286-a8d7-5a3bb4ff3ba8
[client-request-id] => 76d9c8ad-e2fd-4286-a8d7-5a3bb4ff3ba8
)
)
I get this when I put the external user's object ID in the request for the sendMail method of the Graph API. If I put an internal user's object ID into that request, the external user can login, get a token, and send mail as that internal user just fine.
So my question is, is this even possible? Can a user in an external tenant login to my app using Azure AD SSO and also have access to send mail from their account within my application? If so, how far off base am I with my implementation?
As it is a multi-tenant application that supports SSO for external users.
As per Dev's Comment,
Not sure in your scenario, you're using Azure AD B2C (not sure it suits your scenario) or B2B and try to simulate accessing multiple mailboxes
Identity Providers for External Identities
External Guest users with personal MS Account can redeem your B2B collaboration invitations.
During Self Service sign-up user flow, personal MSA can be added as one of the Identity Provider.
No Additional Configuration required to make this identity provider available for user flows.
Email one-time passcode: When redeeming an invitation or accessing a shared resource, a guest user can request a temporary code, which is sent to their email address. Then they enter this code to continue signing in.
Email one-time passcode feature authenticates B2B guest users when they can't be authenticated through other means.
When setting up a self-service sign-up user flow, you can add Email One-Time Passcode as one of the allowed identity providers.
Reference link:
Identity providers for External Identities - Azure AD | Microsoft Docs
B2B Collaboration - Understand user tokens in B2B collaboration - Azure AD | Microsoft Docs
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.
I wanted to know if there are provisions in SAML based Single Sign-On wherein I could authenticate using token provided by IdP and then once authenticated the authorization i.e. what roles/privileges the user has must be handled at the application end. This is entirely from an Azure Active Directory perspective.
Provisions in SAML based Single Sign-On
If users exist in your IdP but are not in your instance, SAML user provisioning can automatically create the users in your instance's User [sys_user] table.
SAML user provisioning is supported for SAML 2.0 Update 1 when
Multi-SSO is enabled.
How SAML user provisioning works
When SAML user provisioning is enabled and the system encounters a new user that is not in the instance, the instance automatically creates a record in a temporary table with the name u_import_saml_user_, where is an automatically generated text identifier. The system also creates transform map that specifies the data relationships between the import table and the User table. Each IdP in identified in the system has its own transform map. The transform map is created once for each IdP. Administrators can update it as necessary.
When the user logs in, they access an IdP to log in.
The system presents a list of all IdPs that are able to use SAML
user provisioning. If there is only one IdP that can use SAML user
provisioning, that one is used automatically.
If none of the above conditions are true, the system uses the
default IdP.
Administer SAML user provisioning
To update the User table with the users in your IdP, you must first set up field mapping and then enable user provisioning through Multi-SSO IdP settings
Roles/privileges
For roles privileges and User administration you could refer here
Some Benefits of Provisioning
Implementing Just-in-Time provisioning can offer the following advantages to your organization.
Reduced Administrative Costs: Provisioning over SAML allows customers to create accounts on-demand, as part of the single sign-on process. This greatly simplifies the integration work required in scenarios where users need to be dynamically provisioned, by combining the provisioning and single sign-on processes into a single message.
Increased User Adoption: Users only need to memorize a single password to acces
s both their main site and Salesforce. Users are more likely to use your Salesforce application on a regular basis.
Increased Security: Any password policies that you have established for your corporate network are also in effect for Salesforce. In addition, sending an authentication credential that is only valid for a single use can increase security for users who have access to sensitive data.
To know some more idea You could also have a look on here
Some key resource for your reference
Configuring Azure AD as a SAML IdP
SAML Guide Line
How does SAML work? IDPs & SPs
SAML terms and their purpose
Hope It would guide your way around regarding SAML implementation. Thank you very much.
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