Настройка поставщика saml 2.0 для порталов с ad fs

Причины для трассировки и ведения журнала

Этот простой прием является удивительно эффективным. Его можно использовать в ситуациях, с которыми не справляется отладчик.

Проблемы, возникающие в течение длительного периода, часто трудно устранять в традиционном отладчике. Журналы позволяют выполнять подробный анализ после проявления проблем, накопившихся за длительный период. В отладчиках, напротив, доступен лишь анализ в режиме реального времени.
Многопоточные приложения и распределенные приложения часто трудно отлаживать. Присоединение отладчика часто изменяет поведение приложения. Подробные журналы можно изучать по мере необходимости для анализа сложных систем.
Проблемы в распределенных приложениях могут возникать из-за сложностей взаимодействия между многими компонентами, а подключение отладчика к каждой части системы неоправданно усложняет процесс.
Многие службы нельзя останавливать. Присоединение отладчика часто приводит к превышению времени ожидания.
Проблемы не всегда удается прогнозировать. Ведение журнала и трассировка создают очень низкую нагрузку, поэтому программы будут сохранять данные даже при возникновении проблемы.

Authentication

Before looking at federated authentication, we need to understand what authentication really means. Authentication defines the way a user is identified and validated through some sort of credentials as part of a sign-in flow. Most applications present a sign-in page to an end user, allowing the user to specify a username and a password. In some cases, additional information may be required to locate the user, like a company ID or a client code. This information allows the application to narrow down the search of the username applicable to the provided info. This is often used to allow the same username to exist across multiple tenants belonging to different customers.

Most applications have a user store (DB or LDAP) that contains, among other things, user profile information and credentials. When a user signs in, the credentials are validated against this user store. The advantage of this simple approach is that everything is managed within the application, providing a single and consistent way to authenticate an end user. However, if a user needs to access multiple applications where each one requires a different set of credentials, it becomes a problem for the end user. First, the user needs to remember different passwords, in addition to any other corporate password (for example, their AD password) that may already exist. The user is now forced to maintain separate usernames and passwords, and must handle different password policies and expirations. In addition, this scenario also creates a headache for administrators and ISVs when application users continue to have access to applications that should have been revoked.

Request signing

Requests from the security plugin to the IdP can optionally be signed. Use the following settings to configure request signing.

Name	Description
	The private key used to sign the requests or to decode encrypted assertions. Optional. Cannot be used when is set.
	The password of the private key, if any.
	Path to the private key. The file must be placed under the Open Distro for Elasticsearch directory, and the path must be specified relative to that same directory.
	The algorithm used to sign the requests. See the next table for possible values.

The security plugin supports the following signature algorithms.

Algorithm	Value
DSA_SHA1	http://www.w3.org/2000/09/xmldsig#dsa-sha1;
RSA_SHA1	http://www.w3.org/2000/09/xmldsig#rsa-sha1;
RSA_SHA256	http://www.w3.org/2001/04/xmldsig-more#rsa-sha256;
RSA_SHA384	http://www.w3.org/2001/04/xmldsig-more#rsa-sha384;
RSA_SHA512	http://www.w3.org/2001/04/xmldsig-more#rsa-sha512;

Okta SAML Setup

First, as a prerequisite, we should .

3.1. Create New Application

Then, we’ll create a new Web application integration with SAML 2.0 support:

Next, we’ll fill in the general information like App name and App logo:

3.2. Edit SAML Integration

In this step, we’ll provide SAML settings like SSO URL and Audience URI:

Last, we can provide feedback about our integration:

3.3. View Setup Instructions

Once finished, we can view setup instructions for our Spring Boot App:

Note: we should copy the instructions like IdP Issuer URL and IdP metadata XML that will be required further in the Spring Security configurations:

Docker example

We provide a fully functional example that can help you understand how to use SAML with Kibana.

Download and unzip the example ZIP file.
At the command line, run .
Review the files:
- defines two ODFE nodes, a Kibana server, and a SAML server.
- add a few SAML settings to the default file.
- configures SAML for authentication.
Access Kibana at http://localhost:5601. Note that Kibana immediately redirects you to the SAML login page.
Log in as with a password of .
After logging in, note that your user in the upper-right is , as defined in of the SAML server.
If you want to examine the SAML server, run to find its container ID and then .

In particular, you might find it helpful to review the contents of the and directories.

Что Такое SAML?

Язык разметки утверждений безопасности (SAML) – это открытый стандарт, который позволяет IdP безопасно отправлять данные аутентификации и авторизации пользователя поставщику услуг (SP) . Он использует сообщения на основе XML для связи между IdP и SP.

Другими словами, когда пользователь пытается получить доступ к службе, он должен войти в систему с помощью IdP. После входа в систему IdP отправляет атрибуты SAML с данными авторизации и аутентификации в формате XML в SP.

Помимо обеспечения защищенного механизма передачи аутентификации, SAML также поддерживает единый вход (SSO) , позволяя пользователям входить в систему один раз и повторно использовать те же учетные данные для входа в другие поставщики услуг.

Using the Toolkit

In the case of service-provider-initiated SAML, the service provider creates a SAML authentication request and sends it to the identity provider (IdP):

Default.aspx.cs

To know where to redirect the user with the authentication request, we need to establish the user’s identity provider. This depends on your application. If accounts have a dedicated subdomain name (e.g. ) or if SAML authentication for accounts is limited to certain IP ranges, you need to look up account information based on whatever information you already have about the user.

For the purposes of this example, these settings are provided by , which is meant as a stub for you to customize:

AccountSettings.CS

Next you’ll use this information to retrieve the identity provider information. After that, you can verify that the SAML assertion is actually from the identity provider configured on the account:

Conclusion

In this comprehensive guide to SAML Single Sign On for Jira Data Center, we have looked at the differences between authentication and provisioning, and the difference in coverage between Atlassian’s pre-installed Data Center app and resolution’s Jira SAML SSO for Data Center App so you can make the best decision moving forward.

We have also seen how to configure the app step by step, guiding you through the full extent of the wizard and the most important advanced configuration options. Throughout the guide, we have explained the meaning of each step and pointed at the most important decisions that you will have to make in this process, like how your users will be updated, or what IdP selection method will be in place.

To find out more about SAML Single Sign On for Jira, you can visit Resolution, browse the documentation for specific guidance, or schedule a screenshare session.

SAML Authentication with Auth0

When it comes to implementing SAML, Auth0 is extremely extensible and able to handle several scenarios:

Auth0 as the identity provider
Auth0 as the service provider
Auth0 as the identity and service provider

For this example, you’ll learn how to implement SAML authentication using Auth0 as the identity provider.

Prerequisites

An Auth0 account — If you don’t already have one, you can sign up for a free account here.
An account with a service provider that supports SAML — Generally, most service providers require you to have a business account or some paid plan to configure SAML. If you don’t have an account to test, you can also use SAMLTest to make sure your Auth0 IdP is properly configured.

Try out the most powerful authentication platform for free.Get started →

The following image shows a list of the service providers Auth0 supports out-of-the-box, but you also have the option of in the dashboard.

Configure the service provider

This tutorial will use Zendesk as the service provider, but you can follow along with any SP of your choosing.

To configure your chosen service provider, run through the following steps in your Auth0 dashboard:

Click on SSO Integrations in the sidebar
Click on the red button in the top right corner, Create SSO Integration
Select the service provider you’d like to configure
Enter the name and/or any identifying information required and press Save

5. Follow the instructions under Tutorial for your specific service provider

Here’s what that looks like for Zendesk.

First, go into the Admin Center in the Zendesk dashboard and click on Security. Next, click on SSO, and you’ll find the SAML configuration settings. This is where you’ll paste in those values from the Auth0 dashboard.

Once these values are copied over, the last step is to enable external authentication for the users that should be able to login with SAML. Zendesk allows you to enable this for end-users, staff users, or both.

Test it out

Now that everything is set up on both ends, it’s time to test it out! See the video below for a demonstration of what the final flow should look like.

As you can see, once you go to your Zendesk URL, you’re redirected back to Auth0, the identity provider, to sign in. Once authenticated, Auth0 sends this information back to Zendesk. Zendesk verifies the response, determines it valid, and grants you access to your Zendesk dashboard.

If you go back to your Auth0 dashboard, you’ll now see a record of the user that just signed in!

Enable SSO (optional)

Auth0 supports several social identity providers that you can enable with the click of a button.

In your dashboard, click on Connections > Social in the sidebar. Select the provider you’d like to use and fill in the details required for that provider.

Once you’ve selected the social connections you want to use, go back to the SP you configured under SSO Integrations. Select the SP, and under Connections, you should see the social connection you just created. Click on the switch to enable it, and now your users are ready to sign in with any of the connections listed!

Web Browser SSO Profile

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

first, it describes an authentication initialization vector — IdP-initiated or SP-initiated
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 message from an SP to an IdP, and by using POST Binding to pass the message from an IdP to an SP
SP-initiated SSO using POST Binding for the message and the Artifact Binding to transfer the message
IDP-initiated SSO using POST Binding to transfer the message from an IdP to an SP; 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 output:

Schematically this process can be displayed as the next:

And step by step SSO authentification here:

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
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 will pass an request body

The browser then will handle the received redirect and will issue HTTP to an IdP URL, passing the in there
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 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
the user is authenticated on the IdP where a security context is created for him
the IdP Single Sign-On Service generates a SAML which includes an assert with this user security context. The SAML is placed into the HTTP with the name:

The body is transferred in the base64 encoding in the element:

The HTML generated is passed to the user’s browser as an HTTP-response.
the browser will issue a -request to the SP (Jenkins) passing the The SP will check the < content and will create a new local security context for this user
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

Well, that’s all in general.

Как убедиться, что система единого входа работает с вашим приложением

Вы можете проверить систему единого входа, инициируемую поставщиком идентификационной информации (IdP), если ваше приложение её поддерживает, или инициируемую поставщиком сервиса (SP).

Система, инициируемая поставщиком идентификационной информации

Войдите в консоль администратора Google.

Используйте аккаунт администратора (он не заканчивается на @gmail.com).
На главной странице консоли администратора нажмите ПриложенияМобильные и веб-приложения.
Выберите SAML-приложение.
В левом верхнем углу экрана нажмите Проверить вход через SAML.
Приложение должно открыться в новой вкладке. Если этого не произойдет, измените настройки IdP и SP на основе информации в сообщениях об ошибках SAML, а затем проверьте вход через SAML ещё раз.

Система, инициируемая поставщиком сервиса

Откройте URL системы единого входа для вашего нового SAML-приложения. Вы будете автоматически перенаправлены на страницу входа в аккаунт Google.
Введите имя пользователя и пароль.
После проверки учетных данных вы будете автоматически перенаправлены в SAML-приложение.

Версии

Начиная с версии 1.0 SAML претерпел одну незначительную и одну основную редакцию.

SAML 1.0 был принят в качестве стандарта OASIS в ноябре 2002 г.
SAML 1.1 был ратифицирован в качестве стандарта OASIS в сентябре 2003 г.
SAML 2.0 стал стандартом OASIS в марте 2005 г.

Liberty Alliance внесла свою Identity Federation Framework (ID-FF) в OASIS SSTC в сентябре 2003 года:

ID-FF 1.1 был выпущен в апреле 2003 года.
ID-FF 1.2 был доработан в ноябре 2003 г.

Версии 1.0 и 1.1 SAML похожи, хотя и существуют небольшие различия. Однако различия между SAML 2.0 и SAML 1.1 существенны. Хотя эти два стандарта относятся к одному и тому же варианту использования, SAML 2.0 несовместим со своим предшественником.

Хотя ID-FF 1.2 был внесен в OASIS в качестве основы SAML 2.0, между SAML 2.0 и ID-FF 1.2 есть некоторые важные различия. В частности, две спецификации, несмотря на их общие корни, несовместимы.

How does SAML Authentication Work?

Now that you’ve seen the high-level overview of how SAML authentication works, let’s look at some of the technical details to see how everything is accomplished.

SAML single sign-on authentication typically involves a service provider and an identity provider. The process flow usually involves the trust establishment and authentication flow stages.

Consider this example:

Our identity provider is Auth0
Our service provider is a fictional service, Zagadat

Now, a user is trying to gain access to Zagadat using SAML authentication.

This is the process flow:

The user tries to log in to Zagadat from a browser.
Zagadat responds by generating a SAML request.

The browser redirects the user to an SSO URL, Auth0
Auth0 parses the SAML request and authenticates the user. This could be with username and password or even social login. If the user is already authenticated on Auth0, this step will be skipped. Once the user is authenticated, Auth0 generates a SAML response.

Auth0 returns the encoded SAML response to the browser.
The browser sends the SAML response to Zagadat for verification.
If the verification is successful, the user will be logged in to Zagadat and granted access to the resources that they are authorized to view/modify.

SAML Process Flow diagram

Note the attributes that are highlighted in the SAML request and response. Here’s a glossary of these parameters:

ID: Newly generated number for identification
IssueInstant: Timestamp to indicate the time it was generated
AssertionConsumerServiceURL: The SAML URL interface of the service provider, where the Identity provider sends the authentication token.
Issuer: The EntityID (unique identifier) of the service provider
InResponseTo: The ID of the SAML request that this response belongs to
Recipient: The EntityID (unique identifier) of the service provider

API-интерфейсы для .NET Core

API стиля печати

Классы System.Console, System.Diagnostics.Trace и System.Diagnostics.Debug предоставляют похожие API стиля печати, удобные для ведения журнала.

Вы можете выбрать любой из этих API стиля печати. Основные отличия указаны далее.

System.Console
- Всегда включен и всегда записывает данные в консоль.
- Полезно для сведений, которые могут потребоваться клиенту для просмотра в выпуске.
- Это самый простой подход. Он часто используется для краткосрочных и непредвиденных действий по отладке. Такой код отладки часто даже не попадает в систему управления версиями.
System.Diagnostics.Trace
- Включается только в том случае, если определяется путем добавления в источник или указания параметра при компиляции.
- Записывает данные в присоединенные прослушиватели (, по умолчанию это DefaultTraceListener).
- Используйте этот API при создании журналов, которые будут включены в большинстве сборок.
System.Diagnostics.Debug
- Включается только в том случае, если определяется путем добавления в источник или указания параметра при компиляции.
- Передает данные в присоединенный отладчик.
- В системах ведет запись в stderr, если задать или .
- Используйте этот API при создании журналов, которые будут включены только в сборках отладки.

События ведения журнала

Следующие API-интерфейсы больше ориентированы на события. Они сохраняют в журнал не простые строки текста, а целые объекты событий.

- EventSource является основным корневым API для трассировки в .NET Core.
- Доступен во всех стандартных версиях .NET Standard.
- Поддерживает трассировку только сериализуемых объектов.
- Можно использовать в процессе через любые экземпляры EventListener, настроенные для использования EventSource.
- Можно использовать вне процесса через:
  - EventPipe из .NET Core на всех платформах.
  - Трассировка событий Windows (ETW).
  - Платформа трассировки LTTng для Linux.
    Пошаговое руководство. Сбор трассировки LTTng с помощью PerfCollect.
- Предоставляется в составе .NET Core и в отдельном пакете NuGet для .NET Framework.
- Позволяет выполнять внутрипроцессную трассировку для несериализуемых объектов.
- Содержит мост, который поддерживает сохранение выбранных полей регистрируемых объектов в EventSource.
- Только для Windows.
- Сохраняет сообщения в журнал событий Windows.
- Системные администраторы ожидают, что сообщения об ошибках, приводящих к сбоям приложений, будут отображаться в журнале событий Windows.

HomeController

Now that our Spring Security SAML configurations are ready along with the Okta developer account setup, we can set up a simple controller to provide a landing page and home page.

6.1. Index and Auth Mapping

First, let’s add mappings to the default target URI (/) and /auth URI:

Then, we’ll add a simple index.html that allows the user to redirect Okta SAML authentication using the login link:

Now, we’re ready to run our Spring Boot App and access it at http://localhost:8080/:

An Okta Sign-In page should open when clicking on the Login link:

6.2. Home Page

Next, let’s add the mapping to the /home URI to redirect the user when successfully authenticated:

Also, we’ll add the home.html to show the logged-in user and a logout link:

Once logged in successfully, we should see the home page:

What is SAML Single Sign On for Jira?

With SAML SSO for Jira Data Center:

Users can enjoy a seamless experience of Jira every day without managing a local password
IT teams can centrally manage their users from their Identity Provider, automating the creation of new users in Jira and minimizing the amount of work required to make changes when employees leave the company, change department or get a promotion.

Basic SAML Terminology

The app name is a standard phrase in the security industry that combines two acronyms:

SSO, which stands for Single Sign On, is the process by which users can use a single password to access all their applications.

SAML, which stands for Security Assertion Markup Language, is one of the most common standards used to implement SSO with web applications – including Jira, of course.

In the context of this guide, Jira is a Service Provider (SP), while the source of user identities for authentication is the Identity Provider (IdP). Some of the most common IdPs include Microsoft’s AD FS, Azure AD, Okta, OneLogin, or Google.

For clarity, in this guide we will make a distinction:

The acronym SAML SSO, will only refer to Resolution’s app.
Single sign-on, SAML single sign-on, or even SSO will be used to refer to the technology in general.

The SAML SSO Flow

This infographic shows the 9 steps in a SAML authentication flow. The flow happens every time a user logs in to Jira Data Center using SAML SSO. To learn more, see the full description here.

At the highest level, two things can happen when a user enters the Jira login page in an SSO flow:

If the user is not logged into the Identity Provider yet, they will be redirected to the login page of the IdP to enter their credentials; then they will be authenticated and redirected into Jira.

Diagram of the user experience of a SAML SSO authentication with no active session on the IdP

If the user is already logged into the Identity Provider, they won’t have to do anything else. The IdP and Jira will exchange information and the user will automatically land inside Jira.

Diagram of the user experience of a SAML SSO authentication with an active session on the IdP

Note: During this process, the user’s password is kept secret by the IdP and remains unknown to Jira.

Single Sign-on = Authentication & Provisioning

In this flow, SAML Single Sign On can take care of two actions:

It can log the user into the application. This action is called user authentication.
It can also create the user into the application’s directory if it doesn’t exist yet. This is called user provisioning, and it can also be used to update information about existing users.

While authentication is entirely standardized with SAML, there are different options for provisioning users:

SAML can be used to create them during the login. This is called Just-in-time provisioning.
There’s also the possibility to synchronize Jira’s directory with the IdP using API calls. This approach is becoming much more frequent as cloud IdPs increase their market share, and very interesting because it makes user creation and updates independent from the login process.

Which method you choose to provision users with will have a great impact on how you manage permissions and group memberships in Jira. We will cover these alternatives in step 5 of the wizard.

But before we look at all the configuration options in SAML SSO for Jira Data Center, let’s answer the question that might still be at the top of your mind.

Изменение настроек безопасности

Некоторые параметры настроек безопасности созданного Replying Party Trust необходимо изменить. Для перехода к этим настройкам выберите имя Replying Party Trust, которое вы ввели на этапе создания проверяющей стороны, затем выберите Actions в Properties.

Вкладка Advanced — в поле «Secure hash algorithm» выберите SHA-256. Не следует выбирать SHA1, так как он больше не поддерживается современными браузерами и считается небезопасным;
Endpoints — добавьте SAML как конечную точку и выберите SAML Logout; Choose Post for the Binding;
Trusted URL — создайте URL, используя веб-адрес вашего ADFS сервера и конечную точку ADFS SAML, добавленную ранее, а также строку ‘?wa=wsignout1.0’. URL должен выглядеть примерно так: https://sso.yourdomain.tld/adfs/ls/?wa=wsignout1.0.

Сохраните изменения, в результате будет создана работающая проверяющая сторона для UseResponse.

Настройка проверяющей стороны в ADFS

Сперва необходимо настроить соединение ADFS с UseResponse. Запустите Add Replying Party Trust Wizard из Панели управления ADFS и следуйте инструкциям ниже:

Data Source — выберите «Enter Data About the Party Manually»;
Укажите Display Name — добавьте любое имя как идентификатор проверяющей стороны. Например, UseResponse Connection;
Выберите профиль — выберите профиль AD FS;
Configure Certificate — оставьте выбранные параметры по умолчанию;
Configure URL — поставьте флажок напротив параметра «Enable Support for the SAML 2.0 WebSSO protocol». В поле введите URL по типу https://subdomain.useresponse.com/saml/metadata, заменив subdomain на ваш UseResponse субдомен или целиком на ваш домен;
Configure Identifiers — добавьте useresponse.com. Это единственно возможное значение, которое можно здесь ввести;
Multi-Factor Authentication — не настраивайте его или если у вас есть конкретные инструкции, примените их здесь;
Authorization Rules — выберите параметр «Permit all users to access this replying party»;
Finish — на конечном шаге завершите настройки для перехода к созданию правил утверждения.

The Assertion, Subject, and Statement Structure

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

<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">[email protected]</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:

at first line with the prefix a SAML assert is declared () and its generation time ()
next, SAML version used —
a unique identificator of an IdP which created this assert —
then, in the block, information about an authenticated subject is added — and his identificator in an email view —
in the conditions are specified to consider this assert to be valid, for example, time range ( и )
and finally in the an authentication type used to authenticate this user — ()

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 mailboxIdentity 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 hasService Providers also known as Relying Parties, as they rely on information from an assert received from an Identity Provider (Asserting Party).

Установка пружинной загрузки

Помимо обычных зависимостей Maven, таких как spring-boot-starter-web и spring-boot-starter-security , нам потребуется spring-security-saml2-core зависимость:

org.springframework.bootspring-boot-starter-web2.4.2org.springframework.bootspring-boot-starter-security2.4.2org.springframework.security.extensionsspring-security-saml2-core1.0.10.RELEASE

Кроме того, не забудьте добавить Shibboleth репозиторий для загрузки последней версии opensaml jar , необходимой для spring-security-saml2-core зависимости:

ShibbolethShibbolethhttps://build.shibboleth.net/nexus/content/repositories/releases/

В качестве альтернативы мы можем настроить зависимости в проекте Gradle:

compile group: 'org.springframework.boot', name: 'spring-boot-starter-web', version: "2.4.2" 
compile group: 'org.springframework.boot', name: 'spring-boot-starter-security', version: "2.4.2"
compile group: 'org.springframework.security.extensions', name: 'spring-security-saml2-core', version: "1.0.10.RELEASE"