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.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.vmware.com