Security statement markup language saml2 0 preliminary study

brief introduction

SAML, whose full name is Security Assertion Markup Language, is a set of open standards based on XML format developed by OASIS, which is used to exchange authentication and authorization data between identity providers (IDPs) and service providers (SPS).

Web based SSO is a very important application.

Next, let's take a look at how SAML works.

Composition of SAML

Three roles are defined in SAML protocol, which are principal: representative subject usually represents human user. identity provider (IdP) identity provider and service provider (SP) service provider.

The role of IdP is to carry out identity authentication and transfer the user's authentication information and authorization information to the service provider.

The function of SP is to verify the user authentication information and authorize the user to access the specified resource information.

Advantages of SAML

Why use SAML?

First, it can improve the user experience. If the system uses SAML, you can access multiple different system services when you log in once. This is actually the advantage of SSO. Users do not need to remember the user names and passwords of multiple systems respectively. Only one is enough.

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

Third, the authentication information of users does not need to be saved on all resource servers, but only one copy needs to be stored in IdP.

How does SAML work

Next, we analyze how SAML works through a flowchart of SSO authentication with SAML.

According to the difference between redirect and post, there are usually three ways to use SAML for SSO authentication. Let's do it together.

SP redirect request; IdP POST response

In the figure above, the User Agent is a web browser. Let's see how the SAML protocol handles when users want to request the resources of the Service Provider.

  1. The user requests the Service Provider through the User Agent, for example:
http://sp.flydean.com/myresource

SP will perform corresponding security check on the resource. If it is found that there is a valid security context, SP will skip steps 2-7 and go directly to step 8.

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

RelayState is a state information maintained by the SP, which is mainly used to prevent CSRF attacks.

SAMLRequest is Base64 encoded < samlp:AuthnRequest >, and the following 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: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>

For security reasons, SAMLRequest can also use the signature key provided by SP to sign.

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

IdP will conduct security verification after receiving the AuthnRequest request. If it is a legal AuthnRequest, the login interface will be displayed.

  1. Users can enter 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>

This form contains SAMLResponse information, which contains user related information.

Similarly, SAMLResponse is also encoded with Base64 < samlp: response >.

<samlp:Response
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0: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: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>

We can see that saml:Assertion information is contained in samlp:Response.

  1. After receiving the XHTML form, the user agent will submit the form to SP.
  2. The assertion consumer service in the SP will process the request, create the relevant security context, and redirect the user agent to the resource page to be accessed.
  3. user agent requests SP resources again.
  4. Because the security context has been created, the SP can directly return the corresponding resources without having to authenticate with the IdP again.

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

The advantage of this method 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. In other words, IdP returns not a direct SAML assertion, but a reference to SAML assertion. After SP receives this reference, it can query the real SAML assertion from the background, so as to improve the security.

SP POST Request; IdP POST Response

We just talked about SP redirect Request. Here, let's take a look at how SP POST request is done:

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

Step 2: instead of conducting redirect, SP returns an XHTML form to 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>

Step 3: after getting the XHTML form in step 2, the User agent posts the form to the IdP SSO server.

The fourth step is the same as the first one.

SP redirect artifact; IdP redirect artifact

In the third way, both SP and IdP use redirect, but the content of redirect is artifact.

As we mentioned earlier, SAML message s can be passed by value or by reference.

This way of passing by reference is artifact.

The receiver receiving the artifact will send a < samlp: artifactresolve > to the issuer to get the real message.

The following is an example of requesting message from IdP:

  <samlp:ArtifactResolve
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0: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>

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: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-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>

Look at the flow chart of the third method:

You can see that the difference between this method and the previous two methods is that there is an additional step to request a real message.

Take steps 3, 4 and 5 as an example:

Step 3: user agent requests SSO server of IdP:

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

Note that the requested parameter here becomes sampart.

Step 4: IdP needs to send a < samlp: artifactresolve > to SP to request the real samlp:AuthnRequest.

Step 5: SP returns a < samlp: artifactresponse > containing samlp:AuthnRequest.

summary

SAML protocol and its basic usage are as follows. In the following article, we will give a specific example to explain how to apply SAML protocol.

Author: what about the flybean program

Link to this article: http://www.flydean.com/saml-startup/

Source of this article: flybean's blog

Welcome to my official account: the most popular interpretation, the most profound dry goods, the most concise tutorial, and many tips you don't know are waiting for you to discover!

Tags: architecture security saml

Posted by SlyOne on Mon, 02 May 2022 03:20:25 +0300