SAML is an important standard used in the SaaS world.
The cloud service provider need to maintain the users.
If a user leave the company, we no longer want the user to be able to access the cloud service.
The problem is that the administrator within the company may not be aware or may not have the visibility or the control over the user store in the cloud service.
Remember that the client company may use multiple services. The IT administrator in the client company will need to keep track all the services that the user has access and figure out how to get the user out of the systems.
The IT administrator really wants to have one switch to turn off all the access.
The things become more complicate as the user may just change the job role, and the IT administrator may need to change the permissions granted to the user in each of the service the user has access to.
If the cloud service does not integrate with the client company's IT system, the entire system won't flow very well.
--
From the user's perspective, they have to remember the user name and password here and there. When the company is using more and more SaaS application, maybe they have the same user id, maybe they have different user id, it is easy for the person to lose track.
From the owner or the administrator of the service provider's perspective, they have maintain the user and password database. This task itself is huge security liability. They will rather not to manage the user database locally. The service provider would rather focusing on their application service, such as CRM, ERP, etc.
Although managing the user and password store locally works, none of these parties is happy.
When the user from the client company would like to login to a cloud service, they connects to the local IDP first. The local IDP knows that the user would like to connect to the cloud service. It issues a token, which describes the user and notify that the user is an authenticated user, and send the token to the service provider.
The service provider will now let the user to do what they would like to do (without additional authentication).
Under this environment, the service provider does not need to know the user password.
Now everybody is happier:
Scenario before SAML
Traditionally, the user and password need to be created in the service provider.The cloud service provider need to maintain the users.
If a user leave the company, we no longer want the user to be able to access the cloud service.
The problem is that the administrator within the company may not be aware or may not have the visibility or the control over the user store in the cloud service.
Remember that the client company may use multiple services. The IT administrator in the client company will need to keep track all the services that the user has access and figure out how to get the user out of the systems.
The IT administrator really wants to have one switch to turn off all the access.
The things become more complicate as the user may just change the job role, and the IT administrator may need to change the permissions granted to the user in each of the service the user has access to.
If the cloud service does not integrate with the client company's IT system, the entire system won't flow very well.
--
From the user's perspective, they have to remember the user name and password here and there. When the company is using more and more SaaS application, maybe they have the same user id, maybe they have different user id, it is easy for the person to lose track.
From the owner or the administrator of the service provider's perspective, they have maintain the user and password database. This task itself is huge security liability. They will rather not to manage the user database locally. The service provider would rather focusing on their application service, such as CRM, ERP, etc.
Although managing the user and password store locally works, none of these parties is happy.
Scenario After SAML is used
Assume that the client company has an active directory(AD). The IT administrators manage the AD locally. Within the client company, there is an identity provider (IDP). The IDP connects to AD.When the user from the client company would like to login to a cloud service, they connects to the local IDP first. The local IDP knows that the user would like to connect to the cloud service. It issues a token, which describes the user and notify that the user is an authenticated user, and send the token to the service provider.
The service provider will now let the user to do what they would like to do (without additional authentication).
Under this environment, the service provider does not need to know the user password.
Now everybody is happier:
- When a person leave the company, the IT administrator will simply disable the entry in the active directory. The IDP will not let the user in after the entry is disabled.
- The user is happier as there is no multiple user and password. he just simply logins to the local IDP and he can access all the services that trust the IDP.
- The service provider is happier as they do not need to maintain the user and password database.
No comments:
Post a Comment