Introduction to the

Security Assertion Markup Language (SAML) is an xmL-based open standard developed by OASIS for exchanging authentication and authorization data between identity providers (IdP) and service providers (SP).

A very important application of SAML is web-based single sign-on (SSO).

Let’s take a look at how SAML works.

The composition of SAML

There are three roles defined in the SAML protocol, which are principal: Representing the principal usually representing the human user. Identity Provider (IdP) Indicates the identity provider and Service Provider (SP) indicates the service provider.

IdP performs identity authentication and transmits user authentication and authorization information to the service provider.

SP authenticates user authentication information and authorizes users to access specified resources.

The advantage of SAML

Why use SAML?

First, it improves the user experience. If the system uses SAML, it can access multiple different system services with a single login. This is actually one of SSO’s strengths, as users don’t need to remember multiple system usernames and passwords, just one.

Second, it can improve the security of the system. Using SAML, we only need to provide the user name and password to IdP.

Third user authentication information does not need to be stored on all resource servers, only need to store a copy in the IdP is enough.

How does SAML work

Next, let’s look at how SAML works through a flowchart for SSO authentication using SAML.

There are usually three ways to use SAML for SSO authentication, depending on the redirect and POST requests.

SP redirect request; IdP POST response

In the figure above, the User Agent is the Web browser. Let’s look at how SAML protocol handles when the User wants to request resources from the Service Provider.

  1. A User requests the Service Provider through the User Agent, for example:
http://sp.flydean.com/myresource
Copy the code

SP will perform a security check on the resource, and if a valid security context is found, SP will skip steps 2-7 and proceed to step 8.

  1. If SP does not find a valid security context in the first step, it generates a SAMLRequest and redirects the User Agent to IdP:
302 Redirect
Location: https://idp.flydean.com/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token
Copy the code

RelayState is a state information maintained by the SP to prevent CSRF attacks.

SAMLRequest is a Base64 encoded SAMLP :AuthnRequest. Here is an example of samLP :AuthnRequest:

  <samlp:AuthnRequest
    xmlns:samlp="Urn: oasis: names: tc: SAML: 2.0: protocol"
    xmlns:saml="Urn: oasis: names: tc: SAML: 2.0: an assertion." "
    ID="aaf23196-1773-2113-474a-fe114412ab72"
    Version="2.0"
    IssueInstant="2020-09-05T09:21:59Z"
    AssertionConsumerServiceIndex="0"
    AttributeConsumingServiceIndex="0">
    <saml:Issuer>https://sp.flydean.com/SAML2</saml:Issuer>
    <samlp:NameIDPolicy
      AllowCreate="true"
      Format="Urn: oasis: names: tc: SAML: 2.0: nameid - format: transient"/>
  </samlp:AuthnRequest>
Copy the code

For security, SAMLRequest can also be signed using the signature key provided by SP.

  1. The User Agent will send a GET request to the IdP SSO server:
GET /SAML2/SSO/Redirect? SAMLRequest = request&RelayState = token HTTP / 1.1 Host: idp.flydean.comCopy the code

After the IdP receives the AuthnRequest, it performs security verification, and if it is a valid AuthnRequest, it displays the login screen.

  1. You can enter the user name and password to log in. After successful login, IdP will return an XHTML form:
  <form method="post" action="https://sp.flydean.com/SAML2/SSO/POST" .>
    <input type="hidden" name="SAMLResponse" value="response" />
    <input type="hidden" name="RelayState" value="token" />.<input type="submit" value="Submit" />
  </form>
Copy the code

The form contains SAMLResponse information, which contains user-specific information.

Similarly, SAMLResponse is samLP :Response encoded in Base64.

<samlp:Response
    xmlns:samlp="Urn: oasis: names: tc: SAML: 2.0: protocol"
    xmlns:saml="Urn: oasis: names: tc: SAML: 2.0: an assertion." "
    ID="identifier_2"
    InResponseTo="identifier_1"
    Version="2.0"
    IssueInstant="2020-09-05T09:22:05Z"
    Destination="https://sp.flydean.com/SAML2/SSO/POST">
    <saml:Issuer>https://idp.flydean.com/SAML2</saml:Issuer>
    <samlp:Status>
      <samlp:StatusCode
        Value="Urn: oasis: names: tc: SAML: 2.0: status: Success"/>
    </samlp:Status>
    <saml:Assertion
      xmlns:saml="Urn: oasis: names: tc: SAML: 2.0: an assertion." "
      ID="identifier_3"
      Version="2.0"
      IssueInstant="2020-09-05T09:22:05Z">
      <saml:Issuer>https://idp.flydean.com/SAML2</saml:Issuer>
      <! -- a POSTed assertion MUST be signed -->
      <ds:Signature
        xmlns:ds="http://www.w3.org/2000/09/xmldsig#">.</ds:Signature>
      <saml:Subject>
        <saml:NameID
          Format="Urn: oasis: names: tc: SAML: 2.0: nameid - format: transient">
          3f7b3dcf-1674-4ecd-92c8-1544f346baf8
        </saml:NameID>
        <saml:SubjectConfirmation
          Method="Urn: oasis: names: tc: SAML: : 2.0 cm: bearer">
          <saml:SubjectConfirmationData
            InResponseTo="identifier_1"
            Recipient="https://sp.flydean.com/SAML2/SSO/POST"
            NotOnOrAfter="2020-09-05T09:27:05Z"/>
        </saml:SubjectConfirmation>
      </saml:Subject>
      <saml:Conditions
        NotBefore="2020-09-05T09:17:05Z"
        NotOnOrAfter="2020-09-05T09:27:05Z">
        <saml:AudienceRestriction>
          <saml:Audience>https://sp.flydean.com/SAML2</saml:Audience>
        </saml:AudienceRestriction>
      </saml:Conditions>
      <saml:AuthnStatement
        AuthnInstant="2020-09-05T09:22:00Z"
        SessionIndex="identifier_3">
        <saml:AuthnContext>
          <saml:AuthnContextClassRef>Urn: oasis: names: tc: SAML: 2.0: ac: classes: PasswordProtectedTransport</saml:AuthnContextClassRef>
        </saml:AuthnContext>
      </saml:AuthnStatement>
    </saml:Assertion>
  </samlp:Response>
Copy the code

You can see that samLP :Response contains SAML :Assertion information.

  1. The User Agent will submit the XHTML form to SP after receiving it.

  2. Assertion Consumer Service in SP will handle the request, create the associated security context, and redirect the User Agent to the resource page.

  3. The user Agent requests SP resources again.

  4. Since the security context has been created, SP can directly return the corresponding resources without going to the IdP again for authentication.

We can see that all the above information exchange is done by the front-end browser, there is no direct communication between SP and IdP.

The advantage of this all-front-end exchange is that the protocol flow is very simple and all messages are simple GET or POST requests.

If you want to improve security, you can also use reference messages. That is, IdP does not return a direct SAML assertion, but a reference to a SAML assertion. Once the SP receives this reference, it can query the real SAML Assertion from behind the scenes for increased security.

SP POST Request; IdP POST Response

Redirect Request (SP POST Request) : Redirect Request (SP POST Request) :

The difference with the first method lies in the second and third steps.

Step 2: SP no longer redirect, but returns an XHTML form to the User Agent:

  <form method="post" action="https://idp.flydean.com/SAML2/SSO/POST" .>
    <input type="hidden" name="SAMLRequest" value="request" />
    <input type="hidden" name="RelayState" value="token" />.<input type="submit" value="Submit" />
  </form>
Copy the code

Step 3: After receiving the XHTML form from step 2, the User Agent posts the form to the IdP SSO Server.

It’s the same as the first way from the fourth step.

SP redirect artifact; IdP redirect artifact

Third, both SP and IdP use redirect, but the content of redirect is artifact.

Earlier we said that SAML messages can be passed as values or references.

And this delivery by reference is an artifact.

The receiver receiving the artifact sends a SAMLP :ArtifactResolve to the issuer to get the actual message.

Here is an example of a message request to an IdP:

  <samlp:ArtifactResolve
    xmlns:samlp="Urn: oasis: names: tc: SAML: 2.0: protocol"
    xmlns:saml="Urn: oasis: names: tc: SAML: 2.0: an assertion." "
    ID="_cce4ee769ed970b501d680f697989d14"
    Version="2.0"
    IssueInstant="2020-09-05T09:21:58Z">
    <saml:Issuer>https://idp.flydean.com/SAML2</saml:Issuer>
    <! -- an ArtifactResolve message SHOULD be signed -->
    <ds:Signature
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#">.</ds:Signature>
    <samlp:Artifact>AAQAAMh48/1oXIM+sDo7Dh2qMp1HM4IF5DaRNmDj6RdUmllwn9jJHyEgIi8=</samlp:Artifact>
  </samlp:ArtifactResolve>
Copy the code

The corresponding server will return a samLP :ArtifactResponse containing samLP :AuthnRequest:

<samlp:ArtifactResponse
    xmlns:samlp="Urn: oasis: names: tc: SAML: 2.0: protocol"
    ID="_d84a49e5958803dedcff4c984c2b0d95"
    InResponseTo="_cce4ee769ed970b501d680f697989d14"
    Version="2.0"
    IssueInstant="2020-09-05T09:21:59Z">
    <! -- an ArtifactResponse message SHOULD be signed -->
    <ds:Signature
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#">.</ds:Signature>
    <samlp:Status>
      <samlp:StatusCode
        Value="Urn: oasis: names: tc: SAML: 2.0: status: Success"/>
    </samlp:Status>
    <samlp:AuthnRequest
      xmlns:samlp="Urn: oasis: names: tc: SAML: 2.0: protocol"
      xmlns:saml="Urn: oasis: names: tc: SAML: 2.0: an assertion." "
      ID="_306f8ec5b618f361c70b6ffb1480eade"
      Version="2.0"
      IssueInstant="2020-09-05T09:21:59Z"
      Destination="https://idp.flydean.com/SAML2/SSO/Artifact"
      ProtocolBinding="Urn: oasis: names: tc: SAML: 2.0: bindings: HTTP - an Artifact"
      AssertionConsumerServiceURL="https://sp.flydean.com/SAML2/SSO/Artifact">
      <saml:Issuer>https://sp.flydean.com/SAML2</saml:Issuer>
      <samlp:NameIDPolicy
        AllowCreate="false"
        Format="Urn: oasis: names: tc: SAML: 1.1: nameid - format: emailAddress." "/>
    </samlp:AuthnRequest>
  </samlp:ArtifactResponse>
Copy the code

Look at the flow chart of the third way:

As you can see, the difference between this approach and the previous two approaches is the additional step of requesting the real message.

Take steps 3, 4, and 5:

Step 3 User Agent requests THE SSO server of IdP:

 https://idp.example.org/SAML2/SSO/Artifact?SAMLart=artifact_1&RelayState=token
Copy the code

Notice that the requested parameter is changed to SAMLart.

Step 4, the IdP needs to send a SAMLP :ArtifactResolve to SP to request the real SAMLP :AuthnRequest.

Fifth, SP returns a SAMLP :ArtifactResponse containing samLP :AuthnRequest.

conclusion

This is the SAML protocol and its basic usage. In the following articles, we will take a concrete example of how to apply the SAML protocol.

Author: Flydean program stuff

Link to this article: www.flydean.com/saml-startu…

Source: Flydean’s blog

Welcome to pay attention to my public number: “procedures those things” the most popular interpretation, the most profound dry goods, the most concise tutorial, many you do not know the small skills you find!