Placeholder Image

字幕列表 影片播放

  • 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

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

字幕與單字

單字即點即查 點擊單字可以查詢單字解釋

B2 中高級 美國腔

SAML 2.0:技術概述 (SAML 2.0: Technical Overview)

  • 45 1
    Caurora 發佈於 2021 年 01 月 14 日
影片單字