Overall documentation: Article directory Github: github.com/black-ant

  • Pure binding protocol: OAuth, SAML, OIDC, CAS
  • Server protocols: RADIUS, Kerberos, ADFS
  • Authentication methods: OTP, biometric authentication (face, voice print, fingerprint)
  • Authentication server (included) : AD and LDAP

This article is mainly about SAML, who is getting older and stronger!

A. The preface

Security Assertion Markup Language (SAML) is an open source standard data format based on XML. In our application, SAML is a macro implementation that transmits authentication information in SAML format.

Typically, developers are unconnected to OAuth. At first glance,SAML is an ‘ancient’ protocol, but as you get close to it,SAML is ubiquitous in heavyweight applications such as Windows Server. One of them is the heavy use of SAML authentication, which is really old.

To clarify what SAML is:

IDP Metadata is SSO (Single Sign-on) Metadata, and SP Metadata is Client Metadata. The Metadata file contains its own authentication data (authentication address, signature, public key, etc.). The Server and Client hold each other’s metadata, encrypt each other’s metadata using the public key, verify the validity of the signature, and then request or call back using the authentication address.

2. Main concepts of SAML

2.1 Behavior Concept

The connection is explained in one sentence: the server (client) reads the metadata information, uses the specified protocol, and sends the assertion to the other party via binding!

Assertions are Assertions that are information. Assertions are objects used in SAML to describe authentication. They include when and how a user has been authenticated, and can include extended information such as the user’s Email address or phone number.

Protocols are communications: Protocols specify how different behaviors are performed. These behaviors are refined into a series of Request and Response objects, and the requests and corresponding objects contain the information specifically required for the behavior. For example, the AuthnRequest Protocol (AuthnRequest Protocol) specifies how an SP requests an authenticated user.

A Binding is a transport: The Binding defines how SAML information is transmitted using a communication protocol. For example, HTTP redirect bindings, which state that SAML information will be transmitted via HTTP redirect messages; Another example is the SAML SOAP binding, which declares SAML messages to be passed over SOAP. For example, AuthnRequest declares an HTTP-POST binding

MetaData: SAML MetaData is configuration data that contains information about the parties to SAML communication, such as the ID of the other party communicating, the IP address of the Web Service, the type of bindings supported, and the key used in the communication, etc.

2.2 Concepts

  • Authentication declaration: Indicates whether the user is authenticated. It is usually used for single sign-on.
  • Property declaration: Declares the properties that a Subject has.
  • Authorization decision statement: Declares the permission of A resource. That is, A user has the given E permission on resource R and can perform operation A.

2.3 Metadata Layer

There are four levels in the MeteData file:

  • Assertion :Assertion < SAMl :Assertion>
  • Assertion < SAMLP :AuthnRequest> + < SAMLP :Response> Protocols: Assertion < SAMLP :Response>
  • Level 3: Bindings, decide which way to transfer
  • Level 4: Profile: supporting scheme

2.4 Certificate Functions

Two points have been mentioned before. One is that the Server/Client holds the metadata of both parties. One metadata contains the detailed certificate, key information, and specific metadata file, which will be discussed later.

A certificate containing a public key for a trusted entity is published in metadata as an X.509 certificate, and the corresponding private key is securely stored locally. These keys are used for signing and encryption at the message level, while SAML messages are securely exchanged during transmission by the TLS protocol.

Phase 1: When the IDP receives the SP request, the certificate has the following functions

  • Make sure the requested trusted SP

Phase 2: When SP gets feedback from IDP, SP does the following

  • Identify from a known IDP by signature
  • Gets the content signed with the IDP private key
  • Use the IDP public key to verify the signature
//IDP MetaData key related-signing: indicates the signature. -encryption: indicates the encryption//SP MetaData key correlation- sign :Signature - encryption: encryption - ds:Signature: IDP key informationCopy the code

IDP Metedata file reference


<EntityDescriptor
    xmlns="Urn: oasis: names: tc: SAML: 2.0: metadata"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    xmlns:shibmd="Urn: mace: shibboleth: metadata: 1.0"
    xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui" entityID="http://127.0.0.1/samlServer/idp">
    <IDPSSODescriptor protocolSupportEnumeration="Urn: oasis: names: tc: SAML: 2.0: protocol urn: oasis: names: tc: SAML: 1.1: protocol urn: mace, shibboleth: 1.0">
        <Extensions>
            <shibmd:Scope regexp="false">scope</shibmd:Scope>
        </Extensions>
        <KeyDescriptor use="signing">
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>. [Signature]...</ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </KeyDescriptor>
        <KeyDescriptor use="encryption">
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>. [Public key Information]...</ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </KeyDescriptor>
        <NameIDFormat>Urn: mace: shibboleth: 1.0: nameIdentifier</NameIDFormat>
        <NameIDFormat>Urn: oasis: names: tc: SAML: 2.0: nameid - format: transient</NameIDFormat>
        <SingleLogoutService Binding="Urn: oasis: names: tc: SAML: 2.0: bindings: HTTP POST -" Location="http://127.0.0.1/samlServer/idp/profile/SAML2/POST/SLO"/>
        <SingleSignOnService Binding="Urn: oasis: names: tc: SAML: 2.0: bindings: HTTP POST -" Location="http://127.0.0.1/samlServer/idp/profile/SAML2/POST/SSO"/>
        <SingleSignOnService Binding="Urn: oasis: names: tc: SAML: 2.0: bindings: HTTP - Redirect" Location="http://127.0.0.1/samlServer/idp/profile/SAML2/Redirect/SSO"/>
        <SingleSignOnService Binding="Urn: oasis: names: tc: SAML: 2.0: bindings: SOAP." " Location="http://127.0.0.1/sso/idp/profile/SAML2/SOAP/ECP"/>
    </IDPSSODescriptor>
</EntityDescriptor>
Copy the code

SP Metedata file reference



      <md:EntityDescriptor xmlns:md="Urn: oasis: names: tc: SAML: 2.0: metadata" ID="_5p2k1rpmlbr0hphrontb6zwiplqac1xxpzvzdma" entityID="http://127.0.0.1:9081/mfa-client/saml/callback" validUntil="The 2040-05-07 T14:08:50. 499 z">
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#_5p2k1rpmlbr0hphrontb6zwiplqac1xxpzvzdma">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>GSp3lIKMQs70Q6FQYHWFhVaGKJv31AiRTuXOcyO78mk=</ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>. [IDP signature information]...</ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>. [IDP public key information]...</ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <md:Extensions xmlns:alg="urn:oasis:names:tc:SAML:metadata:algsupport">
        <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
        <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha384"/>
        <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/>
        <alg:SigningMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
        <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/>
        <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha384"/>
        <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512"/>
        <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1"/>
        <alg:SigningMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
        <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#hmac-sha256"/>
        <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#hmac-sha384"/>
        <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#hmac-sha512"/>
        <alg:SigningMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
        <alg:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
        <alg:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#sha384"/>
        <alg:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
    </md:Extensions>
    <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="Urn: oasis: names: tc: SAML: 2.0: protocol urn: oasis: names: tc: SAML: 1.0: protocol urn: oasis: names: tc: SAML: 1.1: protocol">
        <md:Extensions xmlns:init="urn:oasis:names:tc:SAML:profiles:SSO:request-init">
            <init:RequestInitiator Binding="urn:oasis:names:tc:SAML:profiles:SSO:request-init" Location="Http://127.0.0.1/client/saml/callback? client_name=samlClient"/>
        </md:Extensions>
        <md:KeyDescriptor use="signing">
            <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <ds:X509Data>
                    <ds:X509Certificate>. [Signature]...</ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </md:KeyDescriptor>
        <md:KeyDescriptor use="encryption">
            <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <ds:X509Data>
                    <ds:X509Certificate>. [Public key Information]...</ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </md:KeyDescriptor>
        <md:SingleLogoutService Binding="Urn: oasis: names: tc: SAML: 2.0: bindings: HTTP POST -" Location="Http://127.0.0.1/client/saml/callback? client_name=samlClient&amp;logoutendpoint=true"/>
        <md:SingleLogoutService Binding="Urn: oasis: names: tc: SAML: 2.0: bindings: HTTP POST - SimpleSign" Location="Http://127.0.0.1/client/saml/callback? client_name=samlClient&amp;logoutendpoint=true"/>
        <md:SingleLogoutService Binding="Urn: oasis: names: tc: SAML: 2.0: bindings: HTTP - Redirect" Location="Http://127.0.0.1/client/saml/callback? client_name=samlClient&amp;logoutendpoint=true"/>
        <md:SingleLogoutService Binding="Urn: oasis: names: tc: SAML: 2.0: bindings: SOAP." " Location="Http://127.0.0.1/client/saml/callback? client_name=samlClient&amp;logoutendpoint=true"/>
        <md:NameIDFormat>Urn: oasis: names: tc: SAML: 2.0: nameid - format: transient</md:NameIDFormat>
        <md:NameIDFormat>Urn: oasis: names: tc: SAML: 2.0: nameid - format: persistent</md:NameIDFormat>
        <md:NameIDFormat>Urn: oasis: names: tc: SAML: 1.1: nameid - format: emailAddress</md:NameIDFormat>
        <md:NameIDFormat>Urn: oasis: names: tc: SAML: 1.1: nameid - format: unspecified</md:NameIDFormat>
        <md:AssertionConsumerService Binding="Urn: oasis: names: tc: SAML: 2.0: bindings: HTTP POST -" Location="Http://127.0.0.1/client/saml/callback? client_name=SAML2Client" index="0"/>
        <md:AttributeConsumingService index="0">
            <md:RequestedAttribute FriendlyName="eduPersonPrincipalName" Name="Urn: oid: 1.3.6.1.4.1.5923.1.1.1.6" NameFormat="Urn: oasis: names: tc: SAML: 2.0: attrname - format: uri" isRequired="false"/>
        </md:AttributeConsumingService>
    </md:SPSSODescriptor>
</md:EntityDescriptor>

Copy the code

SAML process

3.1 SAML membership and interaction

SAML has two important members:

  • Service Provider (SP) : an entity that provides formal commercial services to users and usually needs to authenticate a user.
  • Identity Provider (IDP) : provides user Identity authentication to ensure that the user is the Identity declared by the IDP

SAML request flow:

  1. As a resource visitor, the requester expects to access the resources of the service provider
  2. The Form has a SAML authentication request packet in the hidden field. In fact, there is no need to manually execute the HTML. The HTML will be automatically executed into IDP through JS
  3. JS will be automatically submitted to IDP. After receiving the request, IDP will return to the verification interface (steps 2-3 are not visible on the browser).
  4. The IDP returns a page to the browser to log in to (the regular login page)
  5. The user is authenticated and successfully submitted to the IDP
  6. IDP assembles an HTML Form, which contains a Response, which contains an assertion about the successful user (user information and permissions), authentication, and private key signature, etc
  7. The HTML is automatically submitted to the SP, which returns a private key in step 6. In this step, the SP verifies the assertion against the public key
  8. All that is left is to determine that it is a legitimate user and redirect to the requested page

Member localization in SAML

Regarding the role positioning of IDP and SP, different from OAuth, authentication center and resource service are deliberately divided into two concepts. In these two probabilities, I have always had a dilemma: who has the identity information in the end?

In general, IDP is an authentication authority, and the generated credential will most likely contain only one Username. SP will then use the username directly or get more detailed information

As with many business processes, authentication returns only an ID, and the specific location of Userinfo depends on the business

3.2 Detailed interaction of SAML

Prerequisite: Hold Metedata on both sides

  • The Server holds Metedata of the Client, including the Client’s public key and redirection address
  • The Client holds Metedata of the Server, including the public key, redirection address, and signature of the Server

3.3 SAML Request format

Reference @ www.samltool.com/generic_sso…

As mentioned earlier, Metedata contains Server/Client access information, such as:

<SingleLogoutService Binding="Urn: oasis: names: tc: SAML: 2.0: bindings: HTTP POST -" Location="http://127.0.0.1/samlServer/idp/profile/SAML2/POST/SLO"/>
<SingleSignOnService Binding="Urn: oasis: names: tc: SAML: 2.0: bindings: HTTP POST -" Location="http://127.0.0.1/samlServer/idp/profile/SAML2/POST/SSO"/>
<SingleSignOnService Binding="Urn: oasis: names: tc: SAML: 2.0: bindings: HTTP - Redirect" Location="http://127.0.0.1/samlServer/idp/profile/SAML2/Redirect/SSO"/>
<SingleSignOnService Binding="Urn: oasis: names: tc: SAML: 2.0: bindings: SOAP." " Location="http://127.0.0.1/sso/idp/profile/SAML2/SOAP/ECP"/>
Copy the code

It clearly states the address and method of access: Such as urn: oasis: names: tc: SAML: 2.0: bindings: HTTP – POST assert that account to access the address through the POST in the form of a request , urn: oasis: names: tc: SAML: 2.0: bindings: HTTP – Redirect shows through the Redirect (Get) the address of access request

SAML AuthnRequest Request format

<samlp:AuthnRequest xmlns:samlp="Urn: oasis: names: tc: SAML: 2.0: protocol" xmlns:saml="Urn: oasis: names: tc: SAML: 2.0: an assertion." " ID="ONELOGIN_809707f0030a5d00620c9d9df97f627afe9dcc24" Version="2.0" ProviderName="SP test" IssueInstant="2014-07-16T23:52:45Z" Destination="http://idp.example.com/SSOService.php" ProtocolBinding="Urn: oasis: names: tc: SAML: 2.0: bindings: HTTP POST -" AssertionConsumerServiceURL="http://sp.example.com/demo1/index.php?acs">
  <saml:Issuer>http://sp.example.com/demo1/metadata.php</saml:Issuer>
  <samlp:NameIDPolicy Format="Urn: oasis: names: tc: SAML: 1.1: nameid - format: emailAddress." " AllowCreate="true"/>
  <samlp:RequestedAuthnContext Comparison="exact">
    <saml:AuthnContextClassRef>Urn: oasis: names: tc: SAML: 2.0: ac: classes: PasswordProtectedTransport</saml:AuthnContextClassRef>
  </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

Copy the code
  • ID: indicates the newly generated ID
  • IssueInstant: timestamp, indicating generation time
  • AssertionConsumerServiceURL: the service provider’s SAML URL interface, identity provider sends in this authentication token.
  • Issuer: EntityID of the service provider
  • InResponseTo: ID of the SAML request to which this response belongs
  • Recipient: The EntityID of the service provider

Of course the actual request is encrypted:

http:/ / 127.0.0.1 samlServer/idp/profile/SAML2 / Redirect/SSO?SAMLRequest=bM441nuRIzAjKeMM8RhegMFjZ4L4xPBHhAfHYqgnYDQnSxC++Qn5IocWuzuBGz7JQmT9C57nxjxgbFIatiqUCQN17aYrLn/mWE09C5mJMYlc V68ibEkbR/JKUQ+2u/N+mSD4/C/QvFvuB6BcJaXaz0h7NwGhHROUte6MoGJKMPE= &RelayState=http%3A%2F%2F127. 0. 01.%2FclientSaml%2Fcallback
Copy the code

3.4 SAML return format case

Reference @ www.samltool.com/generic_sso…

3.5 the Logout case

Note that the actual request process is encrypted, go to here can decrypt yourself to see –>www.samltool.com/attributes….

Logout Request: www.samltool.com/generic_slo…


<samlp:LogoutRequest xmlns:samlp="Urn: oasis: names: tc: SAML: 2.0: protocol" xmlns:saml="Urn: oasis: names: tc: SAML: 2.0: an assertion." " ID="ONELOGIN_21df91a89767879fc0f7df6a1490c6000c81644d" Version="2.0" IssueInstant="2014-07-18T01:13:06Z" Destination="http://idp.example.com/SingleLogoutService.php">
  <saml:Issuer>http://sp.example.com/demo1/metadata.php</saml:Issuer>
  <saml:NameID SPNameQualifier="http://sp.example.com/demo1/metadata.php" Format="Urn: oasis: names: tc: SAML: 2.0: nameid - format: transient">ONELOGIN_f92cc1834efc0f73e9c09f482fce80037a6251e7</saml:NameID>
</samlp:LogoutRequest>

Copy the code

Logout Response :

<samlp:LogoutResponse xmlns:samlp="Urn: oasis: names: tc: SAML: 2.0: protocol" xmlns:saml="Urn: oasis: names: tc: SAML: 2.0: an assertion." " ID="_6c3737282f007720e736f0f4028feed8cb9b40291c" Version="2.0" IssueInstant="2014-07-18T01:13:06Z" Destination="http://sp.example.com/demo1/index.php?acs" InResponseTo="ONELOGIN_21df91a89767879fc0f7df6a1490c6000c81644d">
  <saml:Issuer>http://idp.example.com/metadata.php</saml:Issuer>
  <samlp:Status>
    <samlp:StatusCode Value="Urn: oasis: names: tc: SAML: 2.0: status: Success"/>
  </samlp:Status>
</samlp:LogoutResponse>
Copy the code

4. Request Cases


//Step 1: Client → Server:

http:/ / 127.0.0.1 samlServer/idp/profile/SAML2 / Redirect/SSO? SAMLRequest=.... & RelayState = HTTP % % 2 f % 2 f127. 3 a 0.0.1 fcallback % 2 fclientsaml % 2

// Step 2 : Server doLogin

// Step 3: Server → callBack → Client
http:/ / 127.0.0.1/2 fclientsaml/callback? SAMLRequest=.... & RelayState = HTTP % % 2 f % 2 f127. 3 a 0.0.1 fcallback % 2 fclientsaml % 2

Copy the code

5. SAML FAQ

5.1 Differences between SAML and OAuth

  • SAML uses XML to pass messages, while OAuth uses JavaScript object notation
  • While OAuth provides a simpler mobile experience (OAuth makes extensive use of API calls), SAML is geared towards enterprise security
  • OAuth is more accessible than SAML. Access scope is a practice that allows only minimal access to resources/applications once authenticated.

As said before,SAML is often practiced by some large companies, and it is an enterprise-level single-point approach. The first impression of ordinary people is that it is complex, but heavyweight means more functions, more enterprise-level security, and each has its own characteristics

Appendix. Supplementary concepts

Assertion: Part of a SAML message (XML document) that provides facts about the Assertion topic (usually about an authenticated user). Assertions can contain information about authentication, associated properties, or authorization decisions

Artifact: An identifier that can be used to retrieve complete SAML messages from identified or bound service providers using background channels

Bnding: Mechanism for passing SAML messages. Bindings are divided into front-end channel bindings, which use the user’s Web browser for messaging (such as HTTP-POST or HTTP-redirect), and back-end channel bindings, which enable identity providers and service providers to communicate directly (such as using SOAP calls in an Artifact binding)

Dscovery: Used to determine which identity provider should be used to authenticate the user currently interacting with the service provider

Metadata: A document describing one or more identities and service providers. Metadata typically includes entity identifiers, public keys, endpoint urls, supported bindings and configuration files, and other capabilities or requirements. Metadata exchange between identities and service providers is usually the first step in establishing federation

Profile: A standardized combination of protocols, assertions, bindings, and processing instructions for implementing a particular use case, such as single sign-on, single sign-off, discovery, and artifact resolution

Protocol: Defines a format (pattern) for SAML messages to implement specific functions, such as requesting authentication from IDP, performing a single logout, or requesting attributes from IDP

Identity Provider (IDP) : An entity that knows how to authenticate users and use federated protocols to provide information about their Identity to service providers/relayers

Service Provider (SP) Service provider: Your application communicates with an identity provider to obtain information about the users it interacts with. User information such as authentication status and user attributes is provided in the form of security assertions

Single sign-on (SSO) : A process that allows access to multiple web sites without having to repeatedly provide the credentials required for authentication. Various federated protocols, such as SAML, WS-Federation, OpenID, or OAuth, can be used to implement SSO use cases. Information such as authentication methods, user attributes, authorization decisions, or security tokens are typically provided to service providers as part of single sign-on

Single Logout (SLO) : Terminating the authentication session is processed on all resources accessed using Single sign-on. Common techniques used include redirecting users to each SSO participant or sending logout SOAP messages

Reference and thanks

Speak reason, quite many, but remember the time did not write down the address again, not good to find, wish everyone health directly