SAML 2.0: Technical Overview

Aug 15, 2023

SAML 2.0: Technical Overview

This content is dated but it still contains relevant and valuable information.
This video will explain the basics of the SAML protocol, focusing on what an IT administrator tasked with setting up federation must know.

VMware End-User Computing (EUC) solutions empower the digital workspace by simplifying app \u0026 access management, unifying endpoint management \u0026 transforming Windows delivery. Learn more on the Digital Workspace Tech Zone: https://techzone.vmware.com.

Content

5.84 -> Hi my name is Peter Bjork and I'm a senior staff architect at VMware in this

12.21 -> video I will explain the basics of the Federation protocol SAML I previously

18.9 -> recorded an identity and access management overview video if you are new

23.49 -> to the concept of Federation I highly recommend you watch that video before

27.81 -> watching this one click on the link in the top right corner to get to the video

35.09 -> SAML saw the light of day back in 2001 and version 2.0 came in 2005 SAML is an

43.829 -> open standard and is often used to provide single sign-on to web-based

48.56 -> applications the protocol can be used for both authentication as well as

55.399 -> authorization the SAML protocol has three entities the user agent which

63.149 -> typically is the user's web browser the service provider or the SP which is the

69.719 -> application you try to access and lastly the identity provider or IDP when

78.09 -> configuring SAML Federation you establish a trust relationship between

82.229 -> the service provider and the identity provider a user who wants to access a

88.17 -> service provider must first authenticate into the IDP if the user manages to

94.529 -> successfully authenticate and is authorized the IDP generates a SAML

100.049 -> assertion the assertion is sent to the application and since the application

106.009 -> trusts the IDP the user is allowed access and since the user is already

113.119 -> authenticated into the IDP the user can single sign-on to other applications

122.84 -> let's go one step deeper into the SAML flow the identity provider knows about

129.09 -> your users and their attributes your service provider has its own knowledge

136.23 -> about the users when the identity provider generates an

141.569 -> assertion it populates it with a user identifier and sends it over to the SP

148.67 -> the SP now validates the assertion but we cannot just send it in clear text or

154.739 -> completely unprotected so the IDP must first sign the assertion

160.76 -> this way the SP can validate the issuer of the assertion and thereby trusted

168.47 -> next the SP reads the user identifier and try to map it to a user in its own

175.23 -> user store and in this case it fails since the user attribute is not found

181.61 -> for Federation to work we need to establish some integration rules for

187.29 -> example the SP might dictate that the user identifier and format should be the

192.72 -> email address then the IDP must agree and be configured to match this

209.48 -> when both sides have the same configuration the SAML assertion can be

214.73 -> mapped to a user object at the service provider and thereby the service

219.26 -> provider can allow access the configurations or rules for integration is

225.98 -> critical to successfully establish a SAML Federation these configurations

231.739 -> can be entered manually into your SP or IDP but often you collect the

236.239 -> requirements and capabilities into an XML metadata file this file contains the

242.33 -> settings and the certificate of the system now you can exchange these files

248.299 -> to configure the Federation this metadata exchange is what establishes the

257.18 -> trust the metadata file contains the format for the user identifier called

268.31 -> the name ID formats the names of the name ID formats are standardized and

274.669 -> looks like this don't be fooled by the SAML 1.1 mentioning this simply

280.52 -> indicates when this format was introduced to the standard they are

285.02 -> still very much valid for SAML 2.0 the most common name ID formats are

291.11 -> unspecified or email it is not super critical that you use the format email

297.05 -> when sending an email address as the user identifier the most important thing

301.669 -> is that both sides are configured the same the metadata often contains the

308.63 -> sender's certificate as well using the certificate the receiving end can

313.7 -> validate the signing of the assertion and know it came from a trusted party

318.46 -> the entity identifier is also included in the file this will uniquely identify

323.96 -> the sender or receiver we'll come back to the metadata in a short while but

329.72 -> first let's have a look at how a user can initiate the authentication flow we

336.56 -> have two main ways of initiating the flow of authentication the first is

341.63 -> called the IDP-initiated flow in this flow the user starts

346.94 -> by accessing the identity provider the user is prompted for authentication and once

353.09 -> done the user can request a service if the user is authorized the IDP generates

360.47 -> a SAML assertion using the user agent the assertion is sent to the SP using a

367.91 -> post message it is the user agent who acts as the transport mechanism for the

374.96 -> assertion the SP verifies the assertion Maps it to a local user and then the

381.53 -> session can start the second method of initiating the authentication flow is

391.43 -> referred to as the SP initiated flow here the user starts by reaching out to

396.68 -> the service provider since the user is not authenticated the SP redirects the

402.47 -> user to the identity provider using a request for authentication message once

408.53 -> the user is validated the IDP generates the SAML assertion the assertion is

414.83 -> sent to the SP via the user agent and the session can start these were the two

421.49 -> examples of how the a flow of authentication can be initiated but it

426.62 -> doesn't really say how the assertion itself was sent in SAML there is

431.33 -> something called bindings this explains how messages and assertions are

436.33 -> technically sent between the SP and the IDP the HTTP redirect binding can be

444.08 -> used for requests for authentication messages sent from an SP to an IDP

451.729 -> HTTP POST is the most common one this can be used both for transporting the assertion

456.86 -> and request messages the SAML artifact binding is a little special and need

463.159 -> some more clarification when using SAML artifact the IDP generates two messages

469.69 -> one is the SAML artifact and the second is the assertion the artifact is a very

477.23 -> message containing a unique identifier the artifact is sent to the SP via the

483.98 -> user agent then the service provider sends an artifact resolve message to the

489.2 -> IDP in order to retrieve the real assertion so with the SAML artifact

496.37 -> binding the SP and the IDP must communicate with each other with this

504.53 -> new knowledge we can return to our metadata file we need to be in an

509.09 -> agreement on how we should exchange messages between the SP and the IDP so

515.51 -> now we have a pretty much complete metadata file with this we can establish

520.28 -> a SAMLFederation between two entities let's move our focus to the SAML

526.85 -> assertion itself once we authenticated the user and verified the authorization

534.32 -> the IDP generates the SAML assertion it adds the name ID with the correct name

540.56 -> ID format for user identification but the method used to authenticate into the

547.7 -> IDP is of great importance it dictates our confidence level of who the user is

554.29 -> therefore this is something we need to add to the SAML assertion when the SP

560.84 -> receives the assertion it can decide to accept the level of authentication used

565.46 -> or deny access or send the user back to the IDP for a stronger authentication

570.98 -> method the identification of an authentication method is referred to as

576.68 -> the SAML context classes here are a couple common context classes where

582.83 -> password protected transport is by far the most commonly used one but you are

588.59 -> not restricted to a fixed list of context classes anyone can make up

593.36 -> their own as long as both the SP and the IDP are in an agreement the Federation

599.33 -> will work a typical user object has attributes tied to it

605.87 -> so of course it makes total sense to add attributes in the SAML assertion

611.01 -> more details about the user as with most other things with SAML we need to

617.64 -> specify the format of the attribute and both SP and the IDP must be configured

623.61 -> with the same formats we need to specify the conditions for the SAML assertion

629.25 -> things like the valid time for the assertion protecting it from replay

633.96 -> attacks as well as to whom this assertion is sent the intended audience

640.55 -> we also need to identify the issuer of the assertion so the SP knows who

645.93 -> generated this assertion and lastly the whole assertion needs to be hashed and

651.57 -> signed to provide protection from being tampered with with that I would say we

657.48 -> have a pretty good understanding of the SAML protocol and its terminology now I

662.43 -> think it's time to put this knowledge into practice let's start with an IDP

667.86 -> initiated flow for this demo I'm using Firefox as my browser and I've added a

674.1 -> SAML debugger called SAML Tracer to it I've already logged into my IDP and as

681.57 -> you can see I'm presented with a catalog of applications I decide to launch one

687.21 -> of the applications I'm entitled to I'm getting single signed on into the

692.16 -> application my SAML Tracer captured one SAML message let's click on it to have

699.24 -> a closer look at what was sent to the SP

703.88 -> here you can see the intended receiver you see the unique identifier of who

710.85 -> sent the message further down in the assertion section you find the

717.27 -> SAMLp:status in this case it says success but SAMLp:status is a good

723.06 -> parameter to keep an eye on when troubleshooting integration you have the

729.9 -> digest value which is used to validate that the assertion hasn't been tampered

734.25 -> with and you have the signature in the subject section we find the name ID format in

743.15 -> this case it is using unspecified and the value passed to the service provider

748.1 -> to identify me is my email address you see the conditions for the assertion the

755.75 -> time it is valid and for which audience the authentication context class is

762.08 -> there as well here it sent PasswordProtectedTransport lastly we

769.37 -> have the attribute section here you can find pretty much anything and it all

774.589 -> depends on what the SP requires the important thing is to make sure that the

779.3 -> name format is the same on both sides and of course that the value is mapped

784.43 -> correctly on both sides next I want to demonstrate an SP initiated flow but

792.29 -> first I need to log out from my application if configured to do so the

798.589 -> logout operation will send a SAML logout message here you can see the

803.42 -> destination for sending the logout message to the IDP you see who sent the

808.43 -> message and for which user the logout command is issued I'll keep my session

818.089 -> with the IDP itself for this demo for an SP initiated flow I start at the service

827.72 -> provider the service provider sends me to the IDP and since I'm already logged

837.23 -> in I'm not prompted for authentication and now SAML Tracer saw two SAML

843.26 -> messages the first is the request for authentication and authorization message

848.54 -> this is sent from the SP to the IDP here you can see the destination of the

854.72 -> request when I clicked on login I was sent to the IDP and wasn't prompted for

862.64 -> any authentication this was because I had already an existing session with the

867.62 -> IDP sometimes you as an SP want to force an reauthentication

873.71 -> and the SP can specify for ForceAuthN to true there is an ID listed the SP uses

882.11 -> this ID to keep track of the request

887.47 -> next we have the response from the IDP sent to the service provider this

893.27 -> assertion is very similar to the assertion we looked at earlier but one

897.68 -> difference is the in response to parameter this is the same ID as sent in

903.68 -> the request message to help the SP know if a particular session and its

908.6 -> authentication request was successful or not with that I thank you very much for

915.29 -> watching this video I hope you found it informative and helpful if you want to

921.5 -> learn more please visit https://techzone.vmware.com

Source: https://www.youtube.com/watch?v=SvppXbpv-5k