Very Basic about SAML and how it is used :)

SAML (Security Assertion Markup Language)covers a lot of use cases.

What I’m going to talk about is the use case, which seems to be in use now, where we have a multi-tenanted SaaS service.

The main use case here is, imagine that we have

1. A cloud service let’s say it’s some online CRM system which provides multi-tenanted services.

2. We have a customer and they have a user population

So what happens is that the customer wants to access the services of the CRM system,

As we know, the classic way the CRM system can have a big database of users and passwords and other information about users,

Then the customer tries to connect to the CRM system, then the system verifies that the submitted data is valid with the information contained in the CRM system.

If the information is matched, it should be allowed.

Let us consider the possible problems with this classic method.

The administration may run into problems.

If one of the Employee (Emp1) leaves the company, then no longer want them to have access to this data.

The problem again is that the administrator may or may not have control over or direct visibility into the CRM system. Maybe they can go and do one of these things manually. But suppose the CRM system is actually using multiple SAS services. And finding out which ones Emp1 can use, should be done very quickly, and this adds to a complex problem.

OR

Emp1 changes the job role and they may need to change permissions in the CRM system. However, this can be a complicated problem.

The Employee may run into problems.

Sometimes this person uses different SAS applications, maybe they have the same user ID, or maybe they don’t, then the person should remember these credentials.

The engineer who implemented the CRM system may have problems.

Now they have to deal with the fact that they run a user password database which is a huge security responsibility.

None of the players in this scenario are actually happy with their results.

So this is what SAML is trying to solve and in fact, successfully solves.

Now let’s show you a revised stream of how it works.

We presume that this company,

let’s suppose they have Active Directory and managed by an administrator and somewhere up here we have something called an Identity Provider.

So what happens now is when this user wants to log on

1. As an initial step, what they do is they connect Identity Provider
2. The system knows who this user is because they’re vouched for by the company’s Active Directory and it knows that this user wants to connect to CRM system
3. Then Identity Provider this system issues a token (SAML TOKEN) to the user, which describes this is the user and sends it to the CRM system.
4. The CRM system knows for sure that it is the user and now the CRM system allows users to do whatever needs to be done on that system without knowing the user and the password.

Now those issues will be solved,

• Administrators can disable a user in the Active Directory and now the identity provider will no longer issue these tokens to non-employee users.
• Emp1, life is simplified because that user just has to log in once to this system with the same user and password as the user would use to get to Active Directory which is the one, the user uses for in-house resources as well.
• CRM engineers, no longer have to worry about maintaining multiple databases of users and passwords.

SAML TOKEN: Containing user information, anything else we can put in other information, for example, which groups, where the user belongs, we can get a job rank, and any kind of information that may be useful and meaningful to the target application.

For example, you may have different permissions here depending on which department you work for. If you work in the sales department then you will get one set of rights here. If you work in the marketing department, you get a different set of rights. This token may contain more than your identity.

This terminology is called IDP-initiated because the user started out by talking to the Identity Provider (IDP), and IDP issued SAML TOKEN and then sent it to the CRM system.

So I had described one method, the user logs in first by going to the Identity Provider,

There is the other way, which

A very common mechanism and perhaps the most common mechanism is where the user goes to the application directly (CRM system with this example)

But with that second method, the CRM system doesn’t know who this is.

There are no tokens connected in there either a SAML token explicitly or some other token /cookies or whatever that this service may have used, therefore the system doesn’t know who this is.

So what happens is redirecting to the identity provider (where the user is coming from) and then verifying that the user is still a valid user, issuing a token, and redirecting the user to the CRM system, with the same SAML TOKEN.

Terminology is what’s called sp-initiated because of the authentication flow is initiated by the Service provider (the application or resource of the thing providing the service).

Thanks for Reading…... 😄