Shulou(Shulou.com)06/03 Report--

This article introduces the knowledge of "how to understand Security Declaration markup language SAML2.0". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Brief introduction

SAML, whose full name is Security Assertion Markup Language, is an open standard based on XML format developed by OASIS, which is used to exchange 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).

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

The composition of SAML

Three roles are defined in the SAML protocol, namely principal: the principal usually represents the human user. Identity provider (IdP) identity provider and service provider (SP) service provider.

The function of IdP is to authenticate and transmit 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?

The first can improve the user experience, if the system uses SAML, then you can log in once and access multiple different system services. This is actually the advantage of SSO, users do not need to remember the usernames and passwords of multiple systems, just one is enough.

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

The authentication information of the third user does not need to be saved on all resource servers, only one copy needs to be stored in IdP.

How does SAML work?

Next, let's 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 one by one.

SP redirect request; IdP POST response

In the image above, User Agent is the web browser. Let's take a look at what the SAML protocol does if a user wants to request resources from Service Provider.

Users request Service Provider via User Agent, such as:

Http://sp.flydean.com/myresource

SP will conduct a security check on the resource accordingly, and if it is found that there is already a valid security context, SP will skip steps 2-7 and proceed directly to step 8.

If SP does not find a valid security context in the first step, it generates the corresponding SAMLRequest and redirects the User Agent to IdP:

302 RedirectLocation: https://idp.flydean.com/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token

RelayState is a state information maintained by SP and is mainly used to prevent CSRF attacks.

Where this SAMLRequest is a samlp:AuthnRequest encoded in Base64. Here is an example of samlp:AuthnRequest:

Https://sp.flydean.com/SAML2

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

User agent will send a get request to IdP's SSO server:

GET / SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token HTTP/1.1Host: idp.flydean.com

After receiving the AuthnRequest request, IdP will perform security authentication, and if it is a legitimate AuthnRequest, the login interface will be displayed.

The user can enter a user name and password to log in. After a successful login, IdP will return a XHTML form:

...

This form contains SAMLResponse information, and SAMLResponse contains user-related information.

The same SAMLResponse is also a samlp:Response that has been encoded using Base64.

Https://idp.flydean.com/SAML2 https://idp.flydean.com/SAML2... 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 https://sp.flydean.com/SAML2 Urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

We can see that the samlp:Response contains saml:Assertion information.

When user agent receives the XHTML form, it will submit the form to SP.

The assertion consumer service in SP will process the request, create the relevant security context, and redirect the user agent to the resource page to be accessed.

User agent requests SP resources again.

Because the security context has been created, SP can directly return the corresponding resources without having to authenticate to IdP again.

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

The advantage of this way that the information is exchanged entirely by the front end is that the protocol flow is very simple, and all messages are simple GET or POST requests.

You can also use reference messages if you want to improve security. In other words, IdP does not return 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, thus improving security.

SP POST Request; IdP POST Response

We were just talking about SP redirect Request. Here's how SP POST request does it:

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

Step 2: instead of redirect, SP returns a XHTML form to User agent:

...

Step 3: after getting the XHTML form of step 2, User agent will form post the form post to IdP SSO server.

It is 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.

We said earlier that SAML message can be passed either by value or by reference.

And this way of passing by reference is artifact.

The receiver that receives the artifact sends a samlp:ArtifactResolve to the issuer to get the real message.

Here is an example of requesting a message from IdP:

Https://idp.flydean.com/SAML2... AAQAAMh58/1oXIM+sDo7Dh3qMp1HM4IF5DaRNmDj6RdUmllwn9jJHyEgIi8=

The corresponding server returns a samlp:ArtifactResponse containing samlp:AuthnRequest:

... Https://sp.flydean.com/SAML2

Take a look at the flow chart of the third way:

You can see that the difference between this approach and the previous two approaches is that there is one more step to request a real message.

Take the third, fourth and fifth steps as an example:

Step 3: user agent requests the SSO server of IdP:

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

Notice that the requested parameter here becomes SAMLart.

Step four, IdP needs to send a samlp:ArtifactResolve to SP to request the real samlp:AuthnRequest.

Step five, SP returns a samlp:ArtifactResponse containing samlp:AuthnRequest.

That's all for "how to understand Security Declaration markup language SAML2.0". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.