What is: SAML – an overview, its structure, and requests tracing between a Jenkins and Okta SSO
Tags: jenkins, security
Published: 2019-11-17 13:15:52

---
title: What is: SAML – an overview, its structure, and requests tracing between a Jenkins and Okta SSO
published: true
date: 2019-11-17 12:52:06 UTC
tags: Jenkins,Security,explainlikeimfive
canonical_url: https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/
---

![](https://rtfm.co.ua/wp-content/uploads/2016/01/What-is-it-e1452250201867.jpg)During the SAML SSO configuration for our Jenkins, I faced an issue, when some attributes weren’t passed from Okta to the Jenkins instance.

So in this post will try to figure out what is SAML in general, will take a short overview of its architecture and main components, and will make some SAML-requests tracing/sniffing to see which data exactly is passed during authentication process using SAML SSO.

As there is a lot of technical information about SAML – we will take a closer look only at components that are used during Jenkins <=> Okta communication.

See the following posts about our Jenkins-Okta integration:

- [Jenkins: SAML Authentication with Okta SSO and users groups](https://rtfm.co.ua/en/jenkins-saml-authentication-via-okta-and-users-groups/)
- [Jenkins: SAML, Okta, user groups, and Role-Based Security plugin](https://rtfm.co.ua/en/jenkins-saml-okta-users-groups-and-role-based-security-plugin/)

During this post writing mainly used the [Security Assertion Markup Language (SAML) V2.0 Technical Overview](http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html) from 25 March 2008, so here can be some inaccuracies but in general it looks correct (I hope so).

Other useful materials about SAML are:

- [SAML 2.0](https://en.wikipedia.org/wiki/SAML_2.0)
- [SAML Response (IdP -> SP)](https://www.samltool.com/generic_sso_res.php)
- [What is SAML and How Does it Work?](https://www.varonis.com/blog/what-is-saml/)
- [How SAML Authentication Works](https://auth0.com/blog/how-saml-authentication-works/#L4--Add-your-Service-Provider-metadata-to-the-Identity-Provider)
- and all the SAML XML-specifications can be found here: [http://docs.oasis-open.org/security/saml/v2.0/](http://docs.oasis-open.org/security/saml/v2.0/)

_As here is a lot of text and it was initially written in this blog [in Russian](https://rtfm.co.ua/what-is-saml-obzor-struktura-i-trassirovka-zaprosov-na-primere-jenkins-i-okta-saml-sso/) – my apologies for the errors/misprints here. Please, fill free to comment about them as well as any mistakes in the processes described below._

Contents:

- [SAML: an overview](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#SAML_an_overview)
- [SAML roles](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#SAML_roles)
- [SAML Use Cases](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#SAML_Use_Cases)
- [SAML Participants](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#SAML_Participants)
- [Web Single Sign-On Use Case](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#Web_Single_Sign-On_Use_Case)
- [IdP-initiated Web SSO](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#IdP-initiated_Web_SSO)
- [SP-initiated Web SSO](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#SP-initiated_Web_SSO)
- [SAML Architecture](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#SAML_Architecture)
- [SAML statement](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#SAML_statement)
- [SAML asserts](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#SAML_asserts)
- [SAML protocols](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#SAML_protocols)
- [SAML bindings](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#SAML_bindings)
- [SAML profiles](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#SAML_profiles)
- [SAML Metadata](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#SAML_Metadata)
- [Authentication context](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#Authentication_context)
- [SAML XML Constructs and Examples](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#SAML_XML_Constructs_and_Examples)
- [Relationship of SAML Components](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#Relationship_of_SAML_Components)
- [saml-chrome-panel](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#saml-chrome-panel)
- [The Assertion, Subject, and Statement Structure](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#The_Assertion_Subject_and_Statement_Structure)
- [Attribute Statement Structure](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#Attribute_Statement_Structure)
- [SAML Profiles](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#SAML_Profiles)
- [Web Browser SSO Profile](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#Web_Browser_SSO_Profile)
- [Jenkins and Okta – SP-Initiated SSO: Redirect/POST Binding](https://rtfm.co.ua/en/what-is-saml-an-overview-its-structure-and-requests-tracing-between-a-jenkins-and-okta-sso/#Jenkins_and_Okta_SP-Initiated_SSO_RedirectPOST_Binding)

### SAML: an overview

The SAML SSO authentication includes at least two main parties – a _Service Provider (SP)_, and an _Identity Provider (IdP)_, and the process itself consists of the _Trust Establishment_ process and actually an authentication process.

For example, in our case, the Jenkins instance will play the _Service Provider_ role and Okta will be the _Identity Provider_.

Shortly, an authentication process has the next flow:

1. a user opens Jenkins URL in a browser
2. Jenkins redirects this user to an SSO URL, Okta
3. Okta authenticates the user and sends this information back to the Jenkins
4. Jenkins performs an authorization check, for example via the Role-Based Security plugin and configured roles

To pass data about a user SAML uses an _Assertion_ object which includes all necessary information – a user username, its authentication status, groups, etc, depending on an _Assert_ type.

Which _Asserts_ are necessary in a particular case – SAML defines in its _SAML protocols_ (will be discussed in the _[SAML protocols](https://rtfm.co.ua/en/?p=22524#SAML_protocols "SAML protocols")_ part of this post), and SAML protocols are passed with the HTTP or SOAP, and this is defined in the SAML _Bindings_ (see the _[SAML bindings](https://rtfm.co.ua/en/?p=22524#SAML_bindings "SAML bindings") part_).

In its turn _SAML protocols_, _Bindings_ and used _Asserts_ are incorporated into _Profiles (_see the _[SAML profiles](https://rtfm.co.ua/?p=22481#SAML_profiles "SAML profiles"))_, for example – _Web Browser SSO Profile (_see the _[Web Browser SSO Profile](https://rtfm.co.ua/en/?p=22524#Web_Browser_SSO_Profile "Web Browser SSO Profile"))_, or an LDAP-profile, which defines which attributes and Identifier and passed in an _Assert_.

#### SAML roles

- **Identity Provider** (_IdP_): a system, which generates an _assert_ (an object or document with an authentication data) about a subject. For example, it can be a user for which an IdP generates an assert which states that John Smith was successfully authenticated and he has attributes like a Group and a mailbox  
_Identity Provider_ is also known as _SAML Authorities_ и _Asserting Party_.
- **Service Provider** (_SP_): a system, which uses information from the IdP. During that, a _Service Provider_ relies on the _assert_ with the authentication data but still can apply additional local policies to determine which permissions inside of this SP the user has  
_Service Providers_ also known as _Relying Parties_, as they _rely on_ information from an assert received from an _Identity Provider_ (_Asserting Party_).

### SAML Use Cases

Before going deeper let’s take a short overview of SAML use cases.

#### SAML Participants

During the SAML authentication information exchange at least two sides included – a _SAML asserting party_ and a _SAML relying party_.

_SAML asserting party_ – a system which creates a _SAML asserts_, and accordingly a _SAML relying party_ – a side, which uses those asserts.

When a _SAML asserting party_ or _SAML relying party_ performs a request – it becomes a _SAML requester_ side, and the second side – a _SAML responder_ side.

During the SAML authentication participants in the process operates by the SAML roles which describe SAML services, SAML protocols and asserts types to be used.

For example, for the SSO – SAML defines SAML roles _Identity Provider (IdP)_ and _Service Provider (SP)_, reviewed above.

Another example can be the _Attribute Authority_ role when one side generates an assert in the response of attributes request from another side – an _Attribute Requester_.

In most of the SAML _asserts_ there is a _subject_ that needs to be authenticated. Such a subject can be a user or, for example, a dedicated server.

Usually, an _Assert_ contains information like “_This is John Smith, he has a mailbox “john.smith@google.com” and he was authenticated with the Password Authentication mechanism_“.

In its turn a Service Provider will decide itself which of this information it needs and depending on its own local access policies will grant or deny access to John.

#### Web Single Sign-On Use Case

##### IdP-initiated Web SSO

**Multi-domain Web Single Sign-on** – one of the most used SAM Web SSO use cases.

In this case, a user has a login session (e.g. a security context) on some website, for example, _airline.example.com_. At some point in time directly or indirectly for a user he is redirected to a partner’s website, let’s say _cars.example.co.uk_, which is playing the Service provider role in this example. An IdP website (the _airline.example.com_ in this case) creates an assert for this SP (_cars.example.co.uk)_, affirming that this user is known, authenticated, and has a set of attributes.

Because the SP _cars.example.co.uk_ trusts to its IdP _airline.example.com_ – it creates a local authentication session for this user:

[![](https://rtfm.co.ua/wp-content/uploads/2019/10/Screenshot_20191030_172502.png "What is: SAML - обзор, структура и трассировка запросов на примере Jenkins и Okta SAML SSO")](https://rtfm.co.ua/wp-content/uploads/2019/10/Screenshot_20191030_172502.png)

With this approach, a user is authenticated on the IdP first and after this can access a protected resource on an SP.

This way is known as an _ **IdP-initiated Web SSO** _.

##### SP-initiated Web SSO

A more widely use case is viсe versa – when a user first accessing a Service Provider resource which redirects this user to an IdP service to authenticate him.

After the user performs authentification steps on an IdP – this IdP will create an assert that will be used by the SP to check the user’s permissions on this SP.

This approach is called **_SP-initiated Web SSO_**.

### SAML Architecture

The SAML “consists” from a bunch of building blocks which fitted together allows building various ways to work with SAML.

Those components are describing mechanisms to be used to pass an identity data, authentication information, and a user’s attributes.

#### SAML statement

As already discussed, during SAML authentication _asserts_ are used which includes a set of _statements_, and those statements contain information about a user. For example, an asset can contain a statement with information about user’s _Name_ “_John Smith_“, and another statement with its email “_john.smith@google.com_“, and his _Group_ is _DevOps_.

SAML describes three main statement types:

- _Authentication statements_: those are created by the side which successfully authenticated a user (for example – by Okta in the IdP role)
- _Attribute statements_: a set of attributes, for example, a user’s mailbox
- _Authorization decision statements_: a set of authorization rules, for example, actions which are allowed for this user

#### SAML asserts

The SAML _assert_ contains data (the _statements_ discussed above) about an authenticated object. An assert contains a subject of the assert (e.g. a user), conditions for this assert to be valid, and a set of statements.

The SAML assert structure and fields are described in the [SAML assertion XML schema](https://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion-2.0.xsd).

#### SAML protocols

Usually, asserts are created on an IdP side which received a request from an SP. To pass those requests SAML protocols are used which describes their structure and content for those messages in the [SAML-defined protocol XML schema](https://docs.oasis-open.org/security/saml/v2.0/saml-schema-protocol-2.0.xsd).

Some of those protocols are _Authentication Request Protocol_, _Single Logout Protocol_, _Assertion Query, and Request Protocol,_ etc.

#### SAML bindings

Ways to deliver those messages via low-level network protocols such as HTTP or SOAP are set in the _SAML bindings_.

Those bindings are _HTTP Redirect Binding_, _HTTP POST Binding_, _HTTP Artifact Binding,_ etc.

Below we will take an overview of _HTTP Redirect Binding_, which is used during Jenkins <=> Okta authentication (see the [SP-Initiated SSO: Redirect/POST Bindings](https://rtfm.co.ua/?p=22481#SP-Initiated_SSO_RedirectPOST_Bindings "SP-Initiated SSO: Redirect/POST Bindings") part of this post).

#### SAML profiles

And the last is the SAML profiles which are defines SAML use cases, for example, the [_Web Browser SSO profile_](https://rtfm.co.ua/?p=22481&Web_Browser_SSO_Profile).

A Profile describes the content of SAML asserts, protocols, and bindings to be used together to solve specific business needs.

There are also _Attribute Profiles_, which not relates to messages protocols or bindings, but describes how to exchange information about attributes by using _asserts_.

#### SAML Metadata

Metadata defines ways to distribute information about the configuration used between IdP and Sp. For example, about SAML bindings used, participant’s roles (IdP, SP), supported attributes, encryption details, etc in its own [SAML Metadata XML schema](https://docs.oasis-open.org/security/saml/v2.0/saml-schema-metadata-2.0.xsd).

#### Authentication context

In some cases, a Service Provider may require more detailed information about the authentification type used on an IdP side.

In this case, a _SAML Authentication Context_ is used which is added to the _authentication statement_ of an _assert_ passed between them.

Besides that, during a SAML request generation, an SP may specify an authentication context in its request to an IdP side with a requirement to authenticate a user with specified certain mechanisms to be used, for example, to authenticate a user with two-factor authentication.

All together can be displayed with the next scheme:

[![](https://rtfm.co.ua/wp-content/uploads/2019/10/Screenshot_20191030_175428.png "What is: SAML - обзор, структура и трассировка запросов на примере Jenkins и Okta SAML SSO")](https://rtfm.co.ua/wp-content/uploads/2019/10/Screenshot_20191030_175428.png)

### 

### SAML XML Constructs and Examples

#### Relationship of SAML Components

SAML asserts includes one or more _statements_, and are passed via a network with HTTP, SOAP or other data transfer protocols:

[![](https://rtfm.co.ua/wp-content/uploads/2019/11/sstc-saml-tech-overview-2.0-cd-02_html_m172277a5.gif "What is: SAML - обзор, структура и трассировка запросов на примере Jenkins и Okta SAML SSO")](https://rtfm.co.ua/wp-content/uploads/2019/11/sstc-saml-tech-overview-2.0-cd-02_html_m172277a5.gif)

##### saml-chrome-panel

To make a SAML-request tracing and parsing let’s use a Chrome’s [`saml-chrome-panel`](https://github.com/milton-lai/saml-chrome-panel) extension.

Install it, open Chrome Developer Tools, open Jenkins tab, log in and let’s investigate what data is transferred between our Jenkins and Okta.

#### The Assertion, Subject, and Statement Structure

Let’s take a closer look at an Assert, Subject and its statements:

[![](https://rtfm.co.ua/wp-content/uploads/2019/11/Screenshot_20191102_144603-1.png "What is: SAML - обзор, структура и трассировка запросов на примере Jenkins и Okta SAML SSO")](https://rtfm.co.ua/wp-content/uploads/2019/11/Screenshot_20191102_144603-1.png)

```
    <saml2:Assertion ID="id5145226399860569827675102" IssueInstant="2019-11-02T12:37:19.440Z" Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://www.okta.com/exk1pgr3yktuVLp5a357</saml2:Issuer>... <saml2:Subject xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"> <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">arseniy@example.com</saml2:NameID> <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml2:SubjectConfirmationData InResponseTo="\_oyzxonwjrhnetdqqctfwbbfwmvgtrfa9jy1xu2o" NotOnOrAfter="2019-11-02T12:42:19.440Z" Recipient="https://ci.example.com/securityRealm/finishLogin"/></saml2:SubjectConfirmation> </saml2:Subject> <saml2:Conditions NotBefore="2019-11-02T12:32:19.440Z" NotOnOrAfter="2019-11-02T12:42:19.440Z" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"> <saml2:AudienceRestriction> <saml2:Audience>https://ci.example.com/securityRealm/finishLogin</saml2:Audience> </saml2:AudienceRestriction> </saml2:Conditions> <saml2:AuthnStatement AuthnInstant="2019-11-02T12:37:16.992Z" SessionIndex="\_oyzxonwjrhnetdqqctfwbbfwmvgtrfa9jy1xu2o" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"> <saml2:AuthnContext> <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef> </saml2:AuthnContext> </saml2:AuthnStatement>...
```

In this XML fragment we can see an _assert_ example with one _authentication statement_:

1. at first line with the `saml:`prefix a SAML _assert_ is declared (`<saml2:Assertion>`) and its generation time (`<IssueInstant>`)
2. next, SAML version used – `Version`
3. a unique identificator of an IdP which created this assert – `<saml2:Issuer>`
4. then, in the `<saml2:Subject>` block, information about an authenticated subject is added – `<saml2:NameID>arseniy@example.com</saml2:NameID>` and his identificator in an email view  – `Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"`
5. in the `<saml2:Conditions>` conditions are specified to consider this assert to be valid, for example, time range (`NotBefore` и `NotOnOrAfter`)
6. and finally in the `<saml2:AuthnStatement>` an authentication type used to authenticate this user – (`<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>`)

#### Attribute Statement Structure

The next part is the `<AttributeStatement>`:

[![](https://rtfm.co.ua/wp-content/uploads/2019/11/Screenshot_20191102_151805.png "What is: SAML - обзор, структура и трассировка запросов на примере Jenkins и Okta SAML SSO")](https://rtfm.co.ua/wp-content/uploads/2019/11/Screenshot_20191102_151805.png)

```
... <saml2:AttributeStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"> <saml2:Attribute Name="Group" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Everyone</saml2:AttributeValue> <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">DevOps</saml2:AttributeValue> </saml2:Attribute> </saml2:AttributeStatement>...
```

In addition to the information about authentication discussed above, an IdP can pass attributes about an authenticated object.

- here is the `<saml2:Attribute Name="Group">`, an attribute is passed with two values – a group `<saml2:AttributeValue>Everyone</saml2:AttributeValue>`, and a second group `<saml2:AttributeValue>DevOps</saml2:AttributeValue>`, using the _SAML_ _Basic attribute profile_ (`NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"`)

### SAML Profiles

As already mentioned SAML defines a bunch of different profiles for different use cases.

In our case with Jenkins and Okta the _Web Browser SSO Profile_ is used which is the most widely used SAML authentification type used.

#### Web Browser SSO Profile

**Web Browser SSO Profile** defines a procedure to exchange SAML messages to realize Web SSO, in particular:

1. first, it describes an authentication initialization vector  – _IdP-initiated_ or _SP-initiated_
2. the second, which SAML bindings have to be used to pass those messages over the network

We already discussed IdP-initiated and SP-initiated roles above, and in our case, it will be the SP-initialized (a user opens Jenkins URL, which requests this user authentication from an IdP).

The back-way authentication initialization will work too, when a user first opens its Okta account, then clicks on a Jenkins icon in there – then Okta will play an initializator role and will generate an assert which will be passed to the Jenkins instance.

The second thing defined by the profile are _bindings_ used to pass data between an IdP and an SP.

For example, an _Authentication Request_ may be transferred from the SP to the IdP using _HTTP Redirect Binding_, _HTTP POST Binding_ or _HTTP Artifact Binding_, and a _Response message_ may be transferred from an IdP to an SP using _HTTP POST Binding_ or _HTTP Artifact Binding_.

In doing so, in the same authentication session, an _Authentication Request_ can be sent by using one binding type, and a _Response message_ by using another one, which is described by an IdP and SP configuration.

Respectively, there are various authentication process types:

- **_SP-initiated SSO using Redirect Binding_** to pass the `<AuthnRequest>`  message from an SP to an IdP, and by using _POST Binding_ to pass the `<Response>` message from an IdP to an SP
- **_SP-initiated SSO using POST Binding_** for the `<AuthnRequest>` message and the _Artifact Binding_ to transfer the `<Response>` message
- **_IDP-initiated SSO using POST Binding_** to transfer the `<Response>` message from an IdP to an SP; `<AuthnRequest>` is not used at all

##### Jenkins and Okta – SP-Initiated SSO: Redirect/POST Binding

And finally, let’s speak in details about the whole SSO authentification process between the Jenkins and Okta by using the **SP-Initiated SSO: Redirect/POST Bindings** , which can be easy to identify by the HTTP methods from the `saml-chrome-panel` output:

[![](https://rtfm.co.ua/wp-content/uploads/2019/11/Screenshot_20191102_155829-1.png "What is: SAML - обзор, структура и трассировка запросов на примере Jenkins и Okta SAML SSO")](https://rtfm.co.ua/wp-content/uploads/2019/11/Screenshot_20191102_155829-1.png)

Schematically this process can be displayed as the next:

[![](https://rtfm.co.ua/wp-content/uploads/2019/11/sstc-saml-tech-overview-2.0-cd-02_html_25426336.gif "What is: SAML - обзор, структура и трассировка запросов на примере Jenkins и Okta SAML SSO")](https://rtfm.co.ua/wp-content/uploads/2019/11/sstc-saml-tech-overview-2.0-cd-02_html_25426336.gif)

And step by step SSO authentification here:

1. a user opens a _sp.example.com_ page (the Jenkins URL in this case), and he has no active login-session (e.g. _security __context_). SP will save the URL requested by the user
2. the SP returns a request to the user’s browser with 302 or 303 redirect code and in the HTTP _Location_ header will specify an SSO service URL, and in the URL-variable `SAMLRequest` will pass an `<AuthnRequest>` request body  
[![](https://rtfm.co.ua/wp-content/uploads/2019/11/Screenshot_20191102_160521.png "What is: SAML - обзор, структура и трассировка запросов на примере Jenkins и Okta SAML SSO")](https://rtfm.co.ua/wp-content/uploads/2019/11/Screenshot_20191102_160521.png)  
The browser then will handle the received redirect and will issue HTTP `GET` to an IdP URL, passing the `SAMLRequest` in there
3. the SSO service checks if the user already has an active login-session which has to comply with the authentication type requested as it is passed in the  `AuthnRequest`from the SP (Jenkins). If such a session is not found – then the user has to authenticate first on the IdP first with his login and password
4. the user is authenticated on the IdP where a _security context_ is created for him
5. the IdP Single Sign-On Service generates a SAML `<Response>` which includes an assert with this user security context. The SAML `<Response>` is placed into the HTTP `FORM` with the `SAMLResponse` name:  
[![](https://rtfm.co.ua/wp-content/uploads/2019/11/Screenshot_20191102_161630.png "What is: SAML - обзор, структура и трассировка запросов на примере Jenkins и Okta SAML SSO")](https://rtfm.co.ua/wp-content/uploads/2019/11/Screenshot_20191102_161630.png)  
The `SAMLResponse` body is transferred in the base64 encoding in the `<saml2p:Response>` element:  
[![](https://rtfm.co.ua/wp-content/uploads/2019/11/Screenshot_20191102_162002.png "What is: SAML - обзор, структура и трассировка запросов на примере Jenkins и Okta SAML SSO")](https://rtfm.co.ua/wp-content/uploads/2019/11/Screenshot_20191102_162002.png)The HTML generated is passed to the user’s browser as an HTTP-response.
6. the browser will issue a `POST`-request to the SP (Jenkins) passing the `SAMLResponse`  
The SP will check the <`Response>` content and will create a new local security context for this user
7. as the last step, the SP can perform an additional user’s _authorization_ to check which permissions this user has in this system. For example, Jenkins can authorize the user by using the [Role-Based Security plugin](https://rtfm.co.ua/en/jenkins-saml-okta-users-groups-and-role-based-security-plugin/)

Well, that’s all in general.

### Similar posts

  
- <small>10/15/2019</small> [Jenkins: SAML, Okta, user groups and Role-Based Security plugin](https://rtfm.co.ua/en/jenkins-saml-okta-users-groups-and-role-based-security-plugin/) 
- <small>10/11/2019</small> [Jenkins: SAML Authentication with Okta SSO and users groups](https://rtfm.co.ua/en/jenkins-saml-authentication-via-okta-and-users-groups/)