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.
Related
For multiple applications. we are using AAD B2C for our authentication system.
We have opted for custom policies. One of the reasons for this is that we want to allow different user groups to access different applications, in the following way:
superusers can access all Applications, including our CMS
product admins can access the customer facing CMS and the end product
product users can access the end product
For this, we have the policies:
B2C_1A_xxx_cms
B2C_1a_xxx_product
B2C_1A_xxx_customercms
In all policies, we do an API call to an internal authentication API, which validates the user's group memberships throught MS Graph API.
The problem is that these policies seem to be able to be used interchangibly:
https://{tenant}.b2clogin.com/{tenant}/b2c_1a_xxx_cms/oauth2/v2.0/authorize?response_type=id_token&scope={scope}%20openid%20profile&client_id={client_id}&redirect_uri={redirect_uri}&nonce={nonce}&client_info=1&x-client-SKU=MSAL.JS&x-client-Ver=1.4.4&client-request-id={client-request-id}&response_mode=fragment
In the above url, users can access the CMS by replacing b2c_1a_xxx_cms with b2c_1a_xxx_product, thus bypassing the group-based validation in place for the specific application.
The original implementation of our policies are based on this tutorial:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-get-started
How can we configure these policies in such a way that changing the URL and trying to log in is impossible?
Based on your requirement, I think you need a the application assignment to users feature.
But it is only available in Azure AD rather than Azure B2C.
So I suggest that you use custom attribute to control the access of the user for different applications.
“ we do an API call to an internal authentication API, which validates the user's group memberships throught MS Graph API. ”
When User A calls Policy B, this API should return back a claim into the journey that prevents it from issuing a JWT. That can be achieved by creating a “block page” using a self asserted technical profile. Call this from the orchestration step using this claim from the API to trigger it with a precondition.
I've setup single sign-on within Salesforce using Microsoft Azure. I've done this within the Setup > Settings > Identity > Single Sign-On Settings configuration menu by following the official tutorial from Microsoft. I'm successfully able to log into Salesforce using a user account in my Azure Active Directory, with just-in time provisioning enabled.
I'd like to be able to use the signed in user to then authenticate further requests to different Azure APIs, such as Azure blob storage. Is this possible using this configuration?
My assumption is that during the single sign-on process, Azure is returning some form of code or token to Salesforce which I can then use in future requests to obtain an authentication token for a specific API request. However, I'm not clear on how or where I'd access this code/token (or whether my assumption is actually correct).
When I was on the Salesforce end of AAD integration I didn't see anything that would look like session id but then again I'm not Azure guy. Might be something my client disabled.
If you followed that guide SF probably generated for you a sample Apex class for just-in-time (JIT) handling of logins and creating/updating users based on data it got from AAD.
You could edit this class, sprinkle some System.debug(JSON.serializePretty(attributes)); to see what AAD sent in the SAML assertion. (Or the assertion itself but it'll be base64-encoded from what I remember). Your SF admin will know how to add debug logging to the user you nominated as system user (who this code will be executed as).
See also https://stackoverflow.com/a/63992670/313628 and https://stackoverflow.com/a/58965058/313628
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 don't understand how the 'Scopes' in Azure B2C are supposed to be used. They are associated with an API, but not a user. I'm sure I'm missing something, but I see no practical use for something associated with an API. I've used and implemented Claims-based authentication based on a user's role in the database.
For example: ordinary users of an API should not have the authority to delete an object, but administrators should have the authority. Does someone have a practical example of how these B2C 'Scopes' can be used to limit a users access to the API?
They are associated with an API, but not a user.
That is correct. I like to think of the association to the API as defining the 'surface area' of the API. For example, this API defines 2 scopes
read
write
Now, you could define two applications. One application that only has read permissions and one that has read and write permissions.
For the common use case of one Web App and one Web API it adds no value. I've been using a scope of no-op for such cases.
I've used and implemented Claims-based authentication based on a user's role in the database
You can use custom attributes to assign "role(s)" to the user. You can set them via the Azure AD Graph API to keep the setting of them secure. You can also set them during sign-up (this is much more involved though).
When you request an access token for that user, the custom attirbute(s) you defined and set will be readable in the API to check permission(s).
Comment Feedback
If I promote or demote a user, I need to change the endpoints (policies) they access at the client.
No need to change the policies. You would update the custom attribute for that user via the Azure AD Graph API.
My problem is that I'm mystified at the an authentication system that authorizes endpoints ("scopes") instead of users
Yeah, me too! I think it might have to do w/ the purpose of the product. B2C is about self-service sign-up, password reset and federating w/ other IDPs (like FB, Google, etc). Maybe Azure AD is a better solution when you want to control permissions on a user. Not sure, still learning!
I still don't see the practicality of splitting your API into several different parts based on the security. An API should be a collection of functionally related services
You don't split your API. You can split your app(s) that utilize the API. See above.
Documentation Reference: Requesting access tokens, GitHub Issue to improve the documentation.
Roles and scopes provide the two halves for this user access control.
Roles -- such as Administrator, Member, and Guest -- determine whether an authenticated user is permitted to delete objects.
Scopes -- such as read, write, and delete -- determine whether an authorized application can delete objects on behalf of an authorizing/consenting user if this user, through their role assignment/s, is permitted to do so.
Azure AD B2C doesn't have any current support for managing roles and assignments of them to users.
It does, however, have support for managing scopes and assignments of them to applications.
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.