Name: SAML 2.0:技術概述 (SAML 2.0: Technical Overview)
Uploaded: 2021-01-14T11:18:43.000Z
Duration: 15 min 35 s
Description: 【看影片學英語】數萬部 YouTube 影片，搭配英漢字典即點即查，輕鬆掌握單字發音與用法，長久累積看電影不必再看字幕。

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