Authentication framework что это за программа Samsung

Содержание

Важное место в приложении занимает аутентификация и авторизация. Аутентификация представляет процесс определения пользователя. Авторизация представляет процесс определения, имеет ли пользователь право доступа к некоторому ресурсу. То есть, если аутентификация отвечает на вопрос «Кем является пользователь?», то авторизация отвечает на вопрос «Какие права пользователь имеет в системе?» ASP.NET Core имеет встроенную поддержку аутентификации и авторизации.

Аутентификация

Для выполнения аутентификации в конвейере обработки запроса отвечает специальный компонент middleware — AuthenticationMiddleware . Для встраивания этого middleware в конвейер применяется метод расширения UseAuthentication()

public static IApplicationBuilder UseAuthentication (this IApplicationBuilder app);

Следует отметить, что метод UseAuthentication() должен встраиваться в конвейер до любых компонентов middleware, которые используют аутентификацию пользователей.

Для выполнения аутентификации этот компонент использует сервисы аутентификации, в частности, сервис IAuthenticationService , которые регистрируются в приложении с помощью метода AddAuthentication() :

public static AuthenticationBuilder AddAuthentication(this IServiceCollection services) public static AuthenticationBuilder AddAuthentication(this IServiceCollection services, string defaultScheme) public static AuthenticationBuilder AddAuthentication(this IServiceCollection services, Action configureOptions)

В качестве параметра вторая версия метода AddAuthentication() принимает схему аутентификации в виде строки. Третья версия метода AddAuthentication принимает делегат, который устанавливает опции аутентификации — объект AuthenticationOptions.

Какую бы мы версию метода не использовали, для аутентификации необходима установить схему аутентификации. Две наиболее расcпространенные схемы аутентификации:

«Cookies» : аутентификация на основе куки. Хранится в константе CookieAuthenticationDefaults.AuthenticationScheme
«Bearer» : аутентификация на основе jwt-токенов. Хранится в константе JwtBearerDefaults.AuthenticationScheme

Схема аутентификации позволяет выбирать определенный обработчик аутентификации. Обработчик аутентификации собственно и выполняет непосредственную аутентификацию пользователей на основе данных запросов и исходя из схемы аутентификации.

Например, для аутентификации с помощью куки передается схема «Cookies». Соответственно для аутентификации пользователя будет выбираться встроенный обработчик аутентификации — класс Microsoft.AspNetCore.Authentication.Cookies.CookieAuthenticationHandler , который на основе полученных в запросе cookie выполняет аутентификацию.

А если используется схема «Bearer», то это значит, что для аутентификации будет использоваться jwt-токен, а в качестве обработчика аутентификации будет применяться класс Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler. Стоит отметить, что для аутентификации с помощью jwt-токенов необходимо добавить в проект через Nuget пакет Microsoft.AspNetCore.Authentication.JwtBearer

При чем в ASP.NET Core мы не ограничены встроенными схемами аутентификации и можем создавать свои кастомные схемы и под них своих обработчиков аутентификации.

Кроме применения схемы аутентификации необходимо подключить аутентификацию определенного типа. Для этого можно использовать следуюшие методы:

AddCookie() : подключает и конфигурирует аутентификацию с помощью куки.
AddJwtBearer() : подключает и конфигурирует аутентификацию с помощью jwt-токенов (для этого метода необходим Nuget-пакет Microsoft.AspNetCore.Authentication.JwtBearer )

Оба метода реализованы как методы расширения для типа AuthenticationBuilder, который возвращается методом AddAuthentication() :

var builder = WebApplication.CreateBuilder(); // добавление сервисов аутентификации builder.Services.AddAuthentication(«Bearer») // схема аутентификации — с помощью jwt-токенов .AddJwtBearer(); // подключение аутентификации с помощью jwt-токенов var app = builder.Build(); app.UseAuthentication(); // добавление middleware аутентификации

Авторизация

Авторизация представляет процесс определения прав пользователя в системе, к каким ресурсам приложения он имеет право доступа и при каких условиях.

Хотя авторизация представляет отдельный независимый процесс, тем не менее для нее также необходимо, чтобы приложение также применяло аутентификацию.

Для подключения авторизации необходимо встроить компонент Microsoft.AspNetCore.Authorization.AuthorizationMiddleware . Для этого применяется встроенный метод расширения UseAuthorization()

public static IApplicationBuilder UseAuthorization(this IApplicationBuilder app)

Кроме того, для применения авторизации необходимо зарегистрировать сервисы авторизации с помощью метода AddAuthorization() :

public static IServiceCollection AddAuthorization(this IServiceCollection services) public static IServiceCollection AddAuthorization(this IServiceCollection services, Action configure)

Вторая версия метода принимает делегат, который с помощью параметра AuthorizationOptions позволяет сконфигурировать авторизацию.

Ключевым элементом механизма авторизации в ASP.NET Core является атрибут AuthorizeAttribute из пространства имен Microsoft.AspNetCore.Authorization, который позволяет ограничить доступ к ресурсам приложения. Например:

using Microsoft.AspNetCore.Authorization; var builder = WebApplication.CreateBuilder(); builder.Services.AddAuthentication(«Bearer») // добавление сервисов аутентификации .AddJwtBearer(); // подключение аутентификации с помощью jwt-токенов builder.Services.AddAuthorization(); // добавление сервисов авторизации var app = builder.Build(); app.UseAuthentication(); // добавление middleware аутентификации app.UseAuthorization(); // добавление middleware авторизации app.Map(«/hello», [Authorize]() => «Hello World!»); app.Map(«/», () => «Home Page»); app.Run();

Здесь в приложении определены две конечных точки: «/» и «/hello». При этом конечная точка «/hello» применяет атрибут Authorize . Атрибут указывается перед обработчиком конечной точки.

Применение данного атрибута означает, что к конечной точке «/hello» имеют доступ только аутентифицированные пользователи.

Если мы обратимся к конечной точке «/», то у нас не возникнет никаких проблем:

Аутентификация и авторизация в ASP.NET Core в C#

Однако если мы обратимся к ресурсу «/hello», то мы получим ошибку 401, которая говорит о том, что пользователь не авторизован для доступа к этому ресурсу:

Источник: metanit.com

Django Rest Framework — Урок 001. Добавление аутентификации по токену

На данный момент я активно работаю над приложение, которое будет работат с REST API сайта на Django. И одним из первых шагов была настройка аутентификации пользователя по токену, но для того, чтобы это заработало, нужно сначала получить токен авторизации. Давайте рассмотрим, как это можно сделать.

Установка Django Rest Framework

Поскольку это самая первая статья по применению DRF, то опишу более подробный процесс установки и настройки DRF. В Дальнейшем я уже не буду приводить эти инструкции. Устанавливаем DRF и остальный необходимые пакеты

pip install djangorestframework pip install markdown # Markdown support for the browsable API. pip install django-filter

Далее добавляем приложение ‘rest_frameword’ в INSTALLED_APPS в файле конфигурации сайта settings.py

INSTALLED_APPS = [ . ‘rest_framework’, ]

Далее официальная документация предлагает подключить в urls.py файле login и logout View из rest_framework, чтобы можно было удобне пользоваться API в браузере. Если честно, то я не использую это API, поскольку мне удобнее пользоваться документацией, сгенерированной через swagger, о чём я тоже скажу далее, но я всё равно подключаю данные View, чтобы потом не решать случайные проблемы.

Установка Swagger

Вы будете в дальнейшем использовать swagger
Вам пондобится иногда кастомизировать вывод информации в описании API, а именно для токена у меня была самое специфичное изменение для swagger.

Для этого руководствуясь документацией выполним следующую команду

pip install -U drf-yasg

После чего модифицируем файл settings.py

INSTALLED_APPS = [ . ‘django.contrib.staticfiles’, # required for serving swagger ui’s css/js files ‘drf_yasg’, . ]

А теперь зарегистрируем swagger в urls сайта

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

permission_classes=(permissions.IsAdminUser,),

Дополнительно можно добавить информацию в вывод документации о том, какие типы аутентификации используются для API. Это выполняется в файле settings.py.

SWAGGER_SETTINGS = < ‘SECURITY_DEFINITIONS’: < ‘Basic’: < ‘type’: ‘basic’ >, ‘Bearer’: < ‘type’: ‘apiKey’, ‘name’: ‘Authorization’, ‘in’: ‘header’ >> >

Вот теперь можно приступить к реализации точку доступа для получения токена.

Приложение api

Создадим приложение api, в котором будет добавлена конечная точка для получения токена.

python manage.py startapp api

serializers.py

Далее создадим файл с сериализаторами, в котором будет создан специальный сериализатор, который будет описывать ответ сайта в swagger.

# -*- coding: utf-8 -*- from rest_framework import serializers class Response201AuthTokenSerializer(serializers.Serializer): token = serializers.CharField(required=True, allow_blank=False) user_id = serializers.IntegerField(required=True)

Этот сериализатор будет корректно генерировать информацию об ответе в документации, и я его использую для создания JSON ответа с токеном.

views.py

После чего модифицирем файл views.py, чтобы получить конечную точку.

Как видите в коде имеется кастомизированная схема swagger для ответа 201, контент создан. Из сериализатора Response201AuthTokenSerializer будет сформирована корректная документация.
Помимо прочего я использую Response201AuthTokenSerializer, чтобы сфомировать ответ с токеном, а также пользовательским id. В дальнейшем я использую id пользователя для манипуляции с данными в мобильном приложении.
Отличительным нюансом данного view является то, что в качестве аутентификации используется только BasicAuthenttication, то есть пользователь получает доступ к данном view только через username и password. В дальнейшем разработка API ведётся для использования токена.

urls.py

А теперь подключить view для получения токена в файлах urls

# -*- coding: utf-8 -*- from django.urls import path from api import views app_name = ‘api’ urlpatterns = [ path(‘api-token-auth/’, views.CustomAuthToken.as_view()), ]

В данном файле определяем имя приложения, которое используется для формирования маршрутов, то есть api. А также подключаем view токена к маршрутизации.

И в конце подключаем urls.py приложения api в основном файле urls.py всего проекта.

urlpatterns = [ . path(‘api/’, include(‘api.urls’)), . ]

Теперь, чтобы получить токен, необходимо направить POST запрос по url http://127.0.0.1/api/api-token-auth/ , в том случае, чтобы тестировать функционал на локальном сервере. В случае боевого сервера нужно отправлять запрос по адресу с доменом вашего сайта.

Для аутентификации нужно использовать Basic аутентификацию.

Пример запроса токена в Felgo QML

Вот пример кода для запроса токена в приложении написанном на QML Felgo

function login(username, password, success, error) < HttpRequest .post(«http://127.0.0.1/api/api-token-auth/», ) .timeout(5000) .set(‘Content-Type’, ‘application/json’) .then(function(res) < success(res) >) .catch(function(err) < error(err) >); >

Рекомендуем хостинг TIMEWEB

Стабильный хостинг, на котором располагается социальная сеть EVILEG. Для проектов на Django рекомендуем VDS хостинг.

Рекомендуемые статьи по этой тематике

По статье задано0 вопрос(ов)

Подписка на обсуждение 1
Подписка на раздел 171

Вам это нравится? Поделитесь в социальных сетях!

Источник: evileg.com

Разбираемся в технологиях безопасной аутентификации

Статьи

Автор Martyshkin На чтение 11 мин Опубликовано 02.02.2023

Технологии безопасной аутентификации

Существует несколько технологий, позволяющих повысить безопасность в части аутентификации пользователей. К ним относятся, например single sign-on (SSO) и различные службы аутентификации.

Single sign-on (SSO) или Технология единого входа

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

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

Несколько крупных интернет-провайдеров используют SSO, но только для своего собственного набора услуг и приложений. Например, пользователь Google может получить доступ ко всем функциям Google, таким как Gmail, Google Документы и электронные таблицы, Календарь и Фотографии, введя используя единое имя пользователя и пароль от учетной записи Google. Microsoft предлагает аналогичную услугу через Microsoft Account. Преимуществом использования единого имени пользователя и пароля является то, что настройки, сделанные на одном устройстве, автоматически синхронизируются со всеми другими устройствами. Однако эти SSO являются собственными и ограничены приложениями Google или Microsoft и не являются “объединенными” с другими организациями.

Службы аутентификации

Пользователь, имеющий доступ к компьютерной системе, должен предъявить удостоверение подлинности или идентификационные данные при входе в систему. Для обеспечения аутентификации могут использоваться различные службы. К ним относятся RADIUS, Kerberos, Terminal Access Control Access Control Systems (TACACS), службы каталогов, язык Security Assertion Markup Language и фреймворковые протоколы аутентификации.

RADIUS

RADIUS, или Remote Authentication Dial-In User Service, был разработан в 1992 году и быстро стал промышленным стандартом широко поддерживаемый почти всеми производителями сетевого оборудования. Изначально RADIUS был разработан для удаленного доступа к корпоративной сети. Однако сейчас слово “удаленный” в названии RADIUS является практически ошибочным термином, поскольку аутентификация RADIUS используется не только для подключения к удаленным сетям. С развитием системы безопасности портов IEEE 802.1x для проводных и беспроводных локальных сетей, RADIUS стал использоваться еще шире.

Клиент RADIUS – это не устройство, запрашивающее аутентификацию, как например, стационарный компьютер или ноутбук с беспроводной связью. Напротив, клиент RADIUS обычно является устройством, таким как беспроводная точка доступа (AP) или сервер сетевого доступа, который отвечает за отправку учетных данных пользователя и параметров соединения в форме сообщения RADIUS на сервер RADIUS. Сервер RADIUS проверяет подлинность и авторизует запрос клиента RADIUS и отправляет ответ в виде сообщения RADIUS.

Преимущество RADIUS заключается в том, что сообщения никогда не отправляются напрямую между беспроводным устройством и сервером RADIUS. Это не позволяет злоумышленнику проникнуть на сервер RADIUS и создать угрозу безопасности.

Подробные шаги для аутентификации RADIUS с помощью беспроводного устройства в сети IEEE 802.1x, которые показаны на рисунке ниже.

Беспроводное устройство, называемое запрашивающим устройством (оно формирует “запрос” на доступ), посылает запрос в точку доступа (access point – AP), запрашивая разрешение на присоединение к беспроводной сети.
Точка доступа (AP), выступающая в качестве аутентификатора, который принимает или отклоняет беспроводное устройство, создает из этой информации пакет данных, называемый запросом аутентификации. Этот пакет включает такую информацию, как идентификация конкретной точки доступа, которая отправляет запрос аутентификации, а также имя пользователя и пароль. Для защиты от подслушивания точка доступа (действующая как клиент RADIUS) шифрует пароль перед отправкой на сервер RADIUS. Запрос на аутентификацию отправляется по сети от точки доступа к серверу RADIUS. Эта коммуникация может осуществляться как по локальной, так и по глобальной сети. Это делает возможность RADIUS-клиентам быть удалёнными от RADIUS-сервера. Если сервер RADIUS недоступен, точка доступа может перенаправить запрос в локальную сеть на альтернативный сервер.
При получении запроса на аутентификацию сервер RADIUS сначала проверяет, что запрос исходит от согласованной точки доступа, а затем расшифровывает пакет данных для доступа к информации об имени пользователя и пароле. Эта информация передается в соответствующую базу данных пользователей. Это может быть текстовый файл, файл паролей UNIX, проприетарная система безопасности или пользовательская база данных.
Если имя пользователя и пароль указаны правильно, сервер RADIUS отправляет подтверждение аутентификации которое включает в себя информацию о сетевой системе пользователя и условиях подключения. Например, сервер RADIUS может сообщить точке доступа, что пользователю необходим TCP/IP. Подтверждение может даже содержать в себе информацию о настройках фильтрации для ограничения доступа пользователя к определенным ресурсам в сети.
Если имя пользователя и пароль неверны, сервер RADIUS отправляет на точку доступа сообщение об отказе в аутентификации, и пользователю отказывают в доступе к сети. Чтобы гарантировать, что на запросы не ответят неавторизованные лица или устройства в сети, сервер RADIUS отправляет ключ аутентификации, или подпись, идентифицирующую себя клиенту RADIUS.
Если сервером RADIUS поддерживается accounting (управление учетных записей) – то в базу данных заноситься запись.
Как только информация сервера получена и проверена точкой доступа, она предоставляет доступ в беспроводной сети пользователю в соответствующей конфигурации.

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

Kerberos

Kerberos – это система аутентификации, разработанная Массачусетским технологическим институтом (MIT) в 1980-х годах и используемая для проверки подлинности пользователей в сети. Протокол назван в честь трехголового пса из греческой мифологии, который охранял ворота Аида. Для обеспечения безопасности Kerberos использует шифрование и аутентификацию.Kerberos функционирует под различными ОС, такими как Windows, macOS и Linux.

Kerberos обычно используется, когда пользователь пытается получить доступ к сетевой службе, и эта служба требует аутентификации. Пользователю предоставляется билет, который выдается сервером аутентификации Kerberos. Этот билет содержит информацию, относящую его к пользователю. Пользователь предъявляет этот билет в сеть для получения услуги.

Затем служба проверяет билет, чтобы удостовериться в личности пользователя. Если личность пользователя подтверждена, то он принимается. Билеты Kerberos трудно скопировать (поскольку они зашифрованы), они содержат конкретную информацию о пользователе, ограничивают его действия, и срок их действия истекает через несколько часов или дней. Выдача и отправка билетов в системе Kerberos осуществляется внутри системы и является прозрачной для пользователя.

Terminal Access Control Access Control System+

Подобно RADIUS, Terminal Access Control Access Control System (TACACS) – это служба аутентификации, обычно используемая на устройствах UNIX, которая взаимодействует путем передачи информации об аутентификации пользователя на централизованный сервер. Централизованный сервер может быть либо базой данных TACACS, либо базой данных, такой как файл паролей Linux или UNIX с поддержкой протокола TACACS. Первая версия называлась просто TACACS, а более поздняя версия, представленная в 1990 году, была известна как Extended TACACS (XTACACS). Текущая версия – TACACS+.

Имеется несколько различий между TACACS+ и RADIUS. Они приведены в таблице ниже.

«>Особенность	«>RADIUS	«>TACACS+
«>Транспортный протокол	«>UDP	«>TCP
«>Аутентификация и авторизация	«>объединенная	«>разделенная
«>Коммуникация	«>Незашифрованная	«>Зашифрованная
«>Взаимодействие с Kerberos	«>нет	«>да
«>Может проверять подлинность сетевых устройств	«>нет	«>да

Служба каталогов

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

Служба каталогов также контролирует все ресурсы в сети и привилегии пользователя к этим ресурсам и предоставляет или запрещает доступ на основе данных службы каталогов. Службы каталогов значительно упрощают предоставление привилегий или разрешений пользователям сети и обеспечивают аутентификацию. Простым примером является Active Directory.

Security Assertion Markup Language (SAML)

Security Assertion Markup Language (SAML)- это стандарт XML, который позволяет веб-доменам защищено обмениваться данными аутентификации и авторизации пользователей. Этот подход позволяет хранить учетные данные пользователя у одного поставщика идентификационных данных пользователей вместо того, чтобы хранить их на сервере каждого поставщика веб-услуг.

SAML широко используется для онлайн-транзакций электронной коммерции между предприятиями бизнес ту бизнес (B2B) и между бизнесом и потребителями (B2C). Этапы транзакции SAML, показанные на рисунке ниже, следующие:

Пользователь пытается зайти на веб-сайт поставщика услуг, который требует ввода имени пользователя и пароля.
Поставщик услуг генерирует запрос SAML-аутентификации, который затем кодируется и встраивается в URL-адрес.
Поставщик услуг отправляет в браузер пользователя URL-адрес перенаправления, содержащий закодированный запрос SAML-аутентификации, который затем отправляется провайдеру идентификации.
Провайдер идентификации декодирует запрос SAML и извлекает встроенный URL-адрес. Затем поставщик идентификационных данных пытается аутентифицировать пользователя либо путем запроса учетных данных для входа в систему, либо путем проверки наличия действующих файлов cookie сессии.
Провайдер идентификации генерирует ответ SAML, содержащий имя пользователя, прошедшего аутентификацию, которое затем подписывается цифровой подписью.
Партнер по идентификации кодирует ответ SAML и возвращает эту информацию браузеру пользователя.
Внутри ответа SAML имеется механизм, позволяющий браузеру пользователя переслать эту информацию обратно поставщику услуг, либо отображая форму, требующую от пользователя нажатия кнопки Submit, либо путем автоматической отправки поставщику услуг.
Поставщик услуг проверяет ответ SAML с помощью открытого ключа поставщика идентификационных данных. Если ответ успешно проверен, пользователь входит в систем

SAML работает с различными протоколами, включая Hypertext Transfer Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), и протокол передачи файлов (FTP)

В концепции IEEE 802.1x обмен данными между клиентом, аутентификатором и сервером аутентификации долен быть безопасным. Фреймворк для передачи протоколов аутентификации известен как расширяемый протокол аутентификации (Extensible Authentication Protocol ) – EAP Протоколы структуры аутентификации В конфигурации IEEE 802.1x связь между доверенным лицом, аутентификатором и сервером аутентификации должна быть безопасной.

Фреймаворк для передачи протоколов аутентификации известна как расширяемый протокол аутентификации (EAP). EAP был создан как альтернатива менее защищенному протокола аутентификации Challenge-Handshake Authentication Protocol (CHAP), а также версия CHAP от Microsoft (MS-CHAP), и Password Authentication Protocol (PAP). Несмотря на свое название, EAP является фреймворком для транспортировки протоколов аутентификации, а не самим протоколом аутентификации. EAP в основном устанавливает формат сообщений и использует четыре типа пакетов: запрос, ответ, успех и отказ. Пакеты запроса формируются аутентификатором
и запрашивают пакет ответа у клиента. Возможно использование любого количества обменов запрос-ответ для завершения аутентификации. Если аутентификация прошла успешно, аутентификатору направляется пакет успеха; а если нет, отправляется пакет неудачи.

Пакет EAP содержит поле, указывающее на функцию пакета (например, ответ или запрос), и поле идентификатора, используемое для сопоставления запросов. поле, используемое для сопоставления запросов и ответов. Пакеты ответа и запроса также имеют поле, которое указывает на тип передаваемых данных (например, протокол аутентификации). данных (например, протокол аутентификации), а также сами данные.

Пожалуйста, не спамьте и никого не оскорбляйте. Это поле для комментариев, а не спамбокс. Рекламные ссылки не индексируются!

Источник: itsecforu.ru

«>Название	«>Описание	«>Объяснение
«>OAuth (Open Authorization)	«>Фреймворк федерации с открытым исходным кодом	«>OAuth 2.0 – это основа для поддержки разработки протоколов авторизации
«>Open ID	«>Открытый стандарт децентрализованного протокола аутентификации	«>Протокол аутентификации, который может быть использован в OAuth 2.0 в качестве стандартного средства для получения идентификационных данных пользователя
«>Shibboleth	«>Программное обеспечение с открытым исходным кодом для проектирования SSO	«>Использует стандарты федерации для обеспечения SSO и обмена атрибутами.