Transcription: SAML 2.0: Technical Overview - YouTube

- Share This:

Hi, my name is Peter Bjork and I'm a senior staff architect at VMware.

In this video I will explain the basics of the Federation protocol SAML.
I previously recorded an identity and access management overview video.
If you are new to the concept of Federation, I highly recommend you watch that video before watching this.

One click on the link in the top right corner to get to the video SAML saw the light of day back in 2001 and version 2.
0 came in 2005.
Saml is an open standard and is often used to provide single sign-on to web-based applications.

The protocol can be used for both authentication as well as authorization.
The SAML protocol has three entities - the user agent, which typically is the user's web browser the service provider or the SP, which is the application you try to access, and, lastly, the identity, provider or IDP.
When configuring SAML Federation, you establish a trust relationship between the service provider and the identity provider, a user who wants to access a service provider must first authenticate into the IDP.

If the user manages to successfully authenticate and is authorized, the IDP generates a SAML assertion.
The assertion is sent to the application and since the application trusts, the IDP, the user is allowed access and since the user is already authenticated into the IDP, the user can single sign-on to other applications.
Let's go one step deeper into the SAML flow.

The identity provider knows about your users and their attributes.
Your service provider has its own knowledge about the users.
When the identity provider generates an assertion, it populates it with a user identifier and sends it over to the SP.

The SP now validates the assertion, but we cannot just send it in clear text or completely unprotected, so the IDP must first sign the assertion.
This way the SP can validate the issuer of the assertion and thereby trusted next.
The SP reads: the user identifier and try to map it to a user in its own user store, and in this case it fails.

Since the user attribute is not found for Federation to work, we need to establish some integration rules.
For example, the SP might dictate that the user, identifier and format should be the email address.
Then the IDP must agree and be configured to match this.

When both sides have the same configuration, the SAML assertion can be mapped to a user object at the service provider and thereby the service provider can allow access.
The configurations or rules for integration is critical to successfully establish a SAML Federation.
These configurations can be entered manually into your SP or IDP, but often you collect the requirements and capabilities into an XML metadata file.

This file contains the settings and the certificate of the system.
Now you can exchange these files to configure the Federation.
This metadata exchange is what establishes the trust the metadata file contains.

The format for the user, identifier called the name ID formats.
The names of the name ID formats are standardized and looks like this don't be fooled by the SAML 1.
Mentioning this simply indicates when this format was introduced to the standard, they are still very much valid for SAML 2.

0, the most common name ID formats are unspecified or email.
It is not super critical that you use the format email when sending an email address as the user identifier.
The most important thing is that both sides are configured the same.

The metadata often contains the sender's certificate as well using the certificate.
The receiving end can validate the signing of the assertion and know it came from a trusted party.
The entity identifier, is also included in the file.

This will uniquely identify the sender or receiver we'll come back to the metadata in a short while, but first, let's have a look at how a user can initiate the authentication flow.
We have two main ways of initiating the flow of authentication.
The first is called the IDP-initiated flow in this flow.

The user starts by accessing the identity provider.
The user is prompted for authentication and once done, the user can request a service.
If the user is authorized, the IDP generates a SAML assertion using the user agent.

The assertion is sent to the SP using a post message.
It is the user agent who acts as the transport mechanism for the assertion.
The SP verifies the assertion Maps it to a local user, and then the session can start.

The second method of initiating the authentication flow is referred to as the SP initiated flow.
Here the user starts by reaching out to the service provider, since the user is not authenticated.
The SP redirects, the user to the identity provider, using a request for authentication message once the user is validated, the IDP generates the SAML assertion.

The assertion is sent to the SP via the user agent and the session can start.
These were the two examples of how the a flow of authentication can be initiated, but it doesn't really say how the assertion itself was sent in SAML.
There is something called bindings.

This explains how messages and assertions are technically sent between the SP and the IDP.
The HTTP redirect binding can be used for requests for authentication messages sent from an SP to an IDP HTTP POST is the most common one.
This can be used both for transporting the assertion and request messages.

The SAML artifact binding is a little special and need some more clarification when using SAML artifact.
The IDP generates two messages: one is the SAML artifact and the second is the assertion.
The artifact is a very message containing a unique identifier.

The artifact is sent to the SP via the user agent.
Then the service provider sends an artifact resolve message to the IDP in order to retrieve the real assertion so with the SAML artifact binding, the SP and the IDP must communicate with each other.
With this new knowledge, we can return to our metadata file.

We need to be in an agreement on how we should exchange messages between the SP and the IDP.
So now we have a pretty much complete metadata file.
With this we can establish a SAMLFederation between two entities.

Let's move our focus to the SAML assertion itself.
Once we authenticated the user and verified the authorization, the IDP generates the SAML assertion.
It adds the name ID with the correct name, ID format for user identification, but the method used to authenticate into the IDP is of great importance.

It dictates our confidence level of who the user is.
Therefore, this is something we need to add to the SAML assertion.
When the SP receives the assertion, it can decide to accept the level of authentication used or deny access or send the user back to the IDP.

For a stronger authentication method, the identification of an authentication method is referred to as the SAML context classes.
Here are a couple common context: classes where password protected transport is by far the most commonly used one, but you are not restricted to a fixed list of context classes.
Anyone can make up their own as long as both the SP and the IDP are in an agreement.

The Federation will work, a typical user object has attributes tied to it.
So, of course, it makes total sense to add attributes in the SAML assertion more details about the user.
As with most other things with SAML, we need to specify the format of the attribute and both SP and the IDP must be configured with the same formats.

We need to specify the conditions for the SAML assertion things like the valid time for the assertion protecting it from replay attacks, as well as to whom this assertion is sent the intended audience.
We also need to identify the issuer of the assertion, so the SP knows who generated this assertion and lastly, the whole assertion needs to be hashed and signed to provide protection from being tampered with.
With that, I would say we have a pretty good understanding of the SAML protocol and its terminology.

Now I think it's time to put this knowledge into practice.
Let's start with an IDP initiated flow for this demo, I'm using Firefox as my browser and I've added a SAML debugger called SAML Tracer to it.
I've already logged into my IDP and, as you can see, I'm presented with a catalog of applications.

I decide to launch one of the applications I'm entitled to I'm getting single signed on into the application.
My SAML Tracer captured one SAML message.
Let's click on it to have a closer look at what was sent to the SP here.

You can see the intended receiver.
You see the unique identifier of who sent the message further down in the assertion section.
You find the SAMLp status in this case.

It says success, but SAMLp status is a good parameter to keep an eye on when troubleshooting integration.
You have the digest value, which is used to validate that the assertion hasn't been tampered with and you have the signature in the subject section.
We find the name ID format in this case it is using unspecified and the value passed to the service provider.

To identify me is my email address.
You see the conditions for the assertion, the time it is valid and for which audience the authentication context class is there as well here it sent PasswordProtectedTransport.
Lastly, we have the attribute section here.

You can find pretty much anything and it all depends on what the SP requires.
The important thing is to make sure that the name format is the same on both sides and, of course, that the value is mapped correctly on both sides.
Next, I want to demonstrate an SP initiated flow, but first I need to log out from my application.

If configured to do so, the logout operation will send a SAML, logout message here.
You can see the destination for sending the logout message to the IDP.
You see who sent the message and for which user the logout command is issued.

I'll keep my session with the IDP itself for this demo for an SP initiated flow.
I start at the service provider.
The service provider sends me to the IDP, and since I'm already logged in I'm, not prompted for authentication and now SAML Tracer saw two SAML messages.

The first is the request for authentication and authorization message.
This is sent from the SP to the IDP.
Here you can see the destination of the request.

When I clicked on login, I was sent to the IDP and wasn't prompted for any authentication.
This was because I had already an existing session with the IDP.
Sometimes you as an SP, want to force an reauthentication and the SP can specify for ForceAuthN to true.

There is an ID listed.
The SP uses this ID to keep track of the request.

Next, we have the response from the IDP sent to the service provider.

This assertion is very similar to the assertion we looked at earlier, but one difference is the in response to parameter.
This is the same ID as sent in the request message to help the SP know if a particular session and its authentication request was successful or not with that.
I thank you very much for watching this video.

I hope you found it informative and helpful if you want to learn more.
Please visit https, //techzone.

com .

More Related Video Transcripts

Loading Recommended Videos...