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