In Identity & Access Management, Federation is one of the most important concept. With more and more organizations building an enterprise IAM system, all the organizations wants to use Federation to single sign-on the user to different applications. Even though SAML is generally used for Account Mapping or Account Linking use cases, technically it should work with OpenID Connect (OIDC) as well. For this blog, let’s use SAML. Examples of some applications :
- Timesheet
- Payroll
- SaaS application hosted by a third-party
In the Federation world, there are two main concepts :
- Account Mapping
- Account Linking
Account Mapping
SAML Spec explains the most basic Account Mapping use case.
Let’s take the example of a Payroll application that is used in any organization. In most of the cases, Payroll application is hosted by a third-party SaaS based organization and employees single sign-on to those applications.
The key actors in this use case are :
Enterprise IAM : Identity Provider
Timesheet application : Service Provider
Employee : End user
How it works?
- When a new employee joins the organization, a new user record is created in the identity provider data store.
- Identity provider should somehow send a request to the Service Provider i.e. the payroll application to create a new record for this employee. SCIM is generally used for this purpose. Refer Wikipedia for more details about SCIM.
- Identity provider and Service Provider should decide on a common attribute to identify the user, say employee ID which is unique for each employee.
- When the user logs in using the Enterprise IAM login page, a SAML assertion is posted back to the Service Provider with employee ID as one of the attribute.
- Service Provider will validate the SAML assertion and then automatically find the local user record based on the employee ID.
- The main point to note here is user logs in only in one place i.e. Enterprise IAM login page. Service Provider automatically maps the incoming SAML assertion to a local user profile based on the employee ID.
- Any other permissions for this user within the Service Provider i.e. Payroll application is either sent in the SAML assertion attributes or stored in the application’s local database.
Just-in-Time Provisioning
- Just-in-Time provisioning is a slight variation of the Account Mapping use case
- In this same Payroll example, when a new employee is on-boarded, no user record is created in the Service Provider
- When the employee tries to access the Service Provider, a new user record will get created automatically in the Service Provider during first time login using the SAML assertion attributes posted by the Identity Provider.
- For all subsequent logins, the same user record on the Service Provider side will be used to identify the logged in user.
- One disadvantage of this approach is that it is not easy to pre-provision all the required permissions for the logged in user before first time login because no user record exists in the Service Provider side.
Account Linking
SAML Spec explains the most basic Account Linking use case.
Let’s take the example of a third-party SaaS application which can be accessed only by certain employees. Also, let’s assume that this SaaS application creates local user credentials for all the employees who can access this application.
The key actors in this use case are :
Enterprise IAM : Identity Provider
Third-Party SaaS application : Service Provider
Employee : End user
- When an employee needs access to the SaaS application, there should be some kind of a process to create user credentials for this employee in the SaaS application. It can be either using a special self user-registration link or an Administrator can create a local user for this employee.
- Now, when the user logs in using Enterprise IAM login page, Identity provider will post a SAML assertion to the Service Provider i.e. SaaS application. Identity Provider can send the employee ID as part of the SAML Assertion since it is always unique. Please note that any unique identifier can be used for this purpose.
- SaaS application will check the local account linking database to see if the incoming SAML user’s employee ID already has a link to one of the SaaS user profile.
- If there is no link record, SaaS application will display the login page for the employee to enter the local user credentials.
- If the employee enters a valid credential, SaaS application will create a record in the local account linking database. This record will have the employee ID, local user ID and other details.
- When the same user logs in next time, SaaS application will use the local linking record to identify the logged in user.
- One disadvantage of Account Linking is that user needs to remember both the Identity Provider as well as Service Provider credentials. Also, additional work is required to pre-provision the user credentials in Service Provider side.
Thanks for reading this article. If you have any questions / suggestions, kindly leave a comment.
