Обычно в SAML
пользователь отстаивает свое право «войти» в сервис. В «старомодном» сервисе они утверждали бы это право, переходя на страницу входа в сервис, вводя свое имя пользователя и пароль, и, если они проходят аутентификацию, сервис делает «что-то», чтобы впустить их. Это «что-то» можетбудь что угодно. Настройка сессии cookie или что-то еще. Это «что-то» не имеет ничего общего с SAML
. SAML
только передает свое утверждение.
В SAML
вместо ввода имени пользователя / пароля они приходят на службу с SAML
Response
, который содержит подробности того, как они аутентифицировались на своихсобственный Identity Provider (IdP) и любые атрибуты о них.
В вашем SAML
Response
они имеют единственный атрибут:
<saml2:Attribute Name="memberOf" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">test group</saml2:AttributeValue>
</saml2:Attribute>
, который говорит, что они являются memberOf
Сущность test group
.
Если служба разрешает доступ членам тестовой группы, они могут «войти в систему», т. е. они успешно отстаивают свое право говорить службе делать то «что-то», что она делает для неSAML
пользователей.
Не имеет значения, есть ли у них старомодный ключ, карточка, отпечаток пальца или распознавание лица. Как только эта часть процесса будет проверена, служба может использовать любой механизм, который она использует, чтобы открыть дверь.
Когда я использую SAML-системы, я сначала посмотрю код аутентификации и авторизации длясервис, чтобы увидеть, каков был следующий шаг («что-то»). Затем добавьте новую конечную точку (ACS) и вставьте ее в существующее «что-то».