Ищете отзывы о первой реализации SAML

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

Я был бы очень признателен, если бы некоторые из вас посмотрели на мои запросы и ответные сообщения и сказали мне, имеют ли они смысл для моей цели, если они включают что-то, чтоне должны быть там, и если они чего-то не хватает, чтоделает должен быть там.

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

Взаимодействие должно работать следующим образом:

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

Вот что я думаю, запрос должен быть:

<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
ID="abc" 
IssueInstant="1970-01-01T00:00:00.000Z" 
Version="2.0"
AssertionConsumerServiceURL="http://www.IdentityProvider.com/loginPage">
   <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    http://www.serviceprovider.com
    </saml:Issuer>
    <saml:Subject>
        <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">3f7b3dcf-1674-4ecd-92c8-1544f346baf8</saml:NameID>
    </saml:Subject>

Вот что я думаю, что ответ должен быть:

<?xml version="1.0" encoding="UTF-8"?>
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination="http://www.serviceprovider.com/desitnationURL" ID="123" IssueInstant="2008-11-21T17:13:42.872Z" Version="2.0">
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0">
        <saml:Subject>
            <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">3f7b3dcf-1674-4ecd-92c8-1544f346baf8</saml:NameID>
            <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:profiles:SSO:browser">
                <saml:SubjectConfirmationData InResponseTo="abc"/>
            </saml:SubjectConfirmation>
        </saml:Subject>
        <saml:AuthnStatement AuthnInstant="2008-11-21T17:13:42.899Z">
            <saml:AuthnContext>
                <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
            </saml:AuthnContext>
        </saml:AuthnStatement>
    </saml:Assertion>
</samlp:Response>

Итак, опять же, мои вопросы:

Это действительное взаимодействие SAML?

Можно ли упростить XML-запрос или ответ?

Где в ответе я должен указать адрес электронной почты субъекта?

Я действительно ценю твою помощь. Спасибо!

-Morgan

 Nix04 авг. 2011 г., 14:31
Это принадлежитcodereview.stackexchange.com

Ответы на вопрос(2)

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

Он используется для установки после. В вашем случае у вас его нет, поэтому после состояния должно быть в порядке ...

Я бы порекомендовал вам создать аккаунт вhttp://www.ssocircle.comи с одним профилировщиком заголовков HTTP (то есть классическим и отличным LiveHttpHeaders) и отладчиком SAML2 (Отладчик Feide Rn SAML2спасибо, ребята!) взгляните на поток запросов / ответов ...

Надеюсь, поможет,

Луис

PS: если вы хотите взглянуть на полную реализацию SP / IdP:http://sourceforge.net/projects/spring-saml/files%2F0.1/

я думаю, что это может быть так просто:

<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  ID="abc" Version="2.0" IssueInstant="1970-01-01T00:00:00.000Z"
</samlp:AuthnRequest>

Пропуск всех необязательных элементов и атрибутов (Issuer, NameIDPolicy, AssertionConsumerServiceURL и т. Д.) Означает, что ваш поставщик удостоверений и поставщик услуг согласовали их заранее, поэтому их не нужно указывать в AuthnRequest. Если вы контролируете обе стороны и абсолютно уверены, что никогда не добавите другого провайдера в список, тогда это совершенно законный запрос SAML. Это означает «аутентифицировать пользователя, который представляет это через механизм, который мы согласовали».

Глядя на ответ, я думаю, что это минимальный случай:

<?xml version="1.0" encoding="UTF-8"?>
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  ID="123" InResponseTo="abc" IssueInstant="2008-11-21T17:13:42.872Z" 
  Version="2.0">
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0">
        <saml:Subject>
            <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
                [email protected]
            </saml:NameID>
        </saml:Subject>
        <saml:AuthnStatement AuthnInstant="2008-11-21T17:13:42.899Z">
            <saml:AuthnContext>
                <saml:AuthnContextClassRef>
                    urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
                </saml:AuthnContextClassRef>
            </saml:AuthnContext>
        </saml:AuthnStatement>
    </saml:Assertion>
</samlp:Response>

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

Итак, в этом ответе говорится: «Это [email protected]; он вошел в систему с паролем через защищенный транспорт (SSL / TLS) в 17:13:42 21.11.2008».

Вы должны взглянуть на спецификацию профилей SAML 2.0 для точного механизма их передачи туда и обратно. AuthnRequest обычно сжимается, кодируется и передается в качестве параметра URL-адреса в GET, тогда как самый простой способ вернуть ответ - через привязку POST - вернуть HTML-страницу с формой, целью которой является поставщик услуг, и которая отправляется в время загрузки страницы через некоторый JavaScript.

 Ashwin12 апр. 2012 г., 07:20
@metadaddy: почему в ответе возникает проблема и мгновенная проверка подлинности. Вы сказали, что мгновение аутентификации - это время, когда пользователь прошел аутентификацию в IDP. И еще одно сомнение, которое у меня есть, заключается в том, что перед идентификатором в ответе не должно быть тега <InResponseTo>.
 Ashwin13 апр. 2012 г., 04:09
@ Metadaddy: пожалуйста! Почему в спецификации SAML указан AuthInstant, а также Issueinstant? Не достаточно ли одного?
 Ashwin13 апр. 2012 г., 17:09
@ Metadaddy: спасибо .. это объясняет :)
 suraj12 апр. 2012 г., 07:18
: Какая польза от немедленной выдачи в сообщении запроса. Используется ли он где-нибудь в IdProvider?
 Sanjeev Kumar Dangi24 дек. 2012 г., 08:10
@ Metadaddy Я новичок в saml2. AuthRequest не указывает, какого пользователя мы аутентифицируем. Как Idp возвращает NameID - [email protected] в ответ?
 metadaddy13 апр. 2012 г., 17:05
@ Эшвин, я могу войти в систему у провайдера идентификации в 9 утра и получить 2-часовой сеанс. В 10 утра я посещаю поставщика услуг. У меня уже есть сеанс у провайдера идентификации, поэтому он просто выдает ответ без запроса повторной аутентификации. Этот ответ даст 9 утра как AuthnInstant и 10 утра как IssueInstant. Это зависит от поставщика услуг, что он делает с этой информацией.
 metadaddy24 дек. 2012 г., 17:23
@SanjeevKumarDangi AuthRequest запрашивает, чтобы IdP аутентифицировал пользователя. Обычно IdP делает это, запрашивая у пользователя учетные данные (например, имя пользователя / пароль). Таким образом, IdP знает, кто пользователь, и возвращает NameID в ответе.
 Sanjeev Kumar Dangi26 дек. 2012 г., 20:16
@ metadaddy спасибо. Но у меня есть другой вариант использования. Я не могу понять, как работает единый вход. Предположим, есть буксирные SP-A и B и один Idp -I. Пользователь отправляет запрос авторизации от A и проходит аутентификацию и получает билет от IdP. Теперь пользователь нажимает на ссылку и переходит к B. Откуда B знает, кто этот пользователь? Отправляет ли http-запрос на исходящую ссылку B запрос в заголовке запроса и на стороне сервера, приложения запрашивают подтверждение с помощью этого билета, и IdP сообщает, что этот билет активен, и сервер также может извлекать атрибуты, например имя пользователя, связанное с этим билетом. Пожалуйста, объясни
 metadaddy13 апр. 2012 г., 00:33
@Ashwin, IssueInstant - когда был создан ответ SAML; AuthnInstant - это когда пользователь аутентифицируется - это может быть за некоторое время до IssueInstant. Вы правы в InResponseTo - это необязательно в спецификации SAML, но вы должны предоставить его, если сообщение является ответом на запрос - я отредактирую свой ответ, чтобы он был правильным - спасибо!
 metadaddy13 апр. 2012 г., 00:29
@suraj, IssueInstant сообщает провайдеру идентификации, когда был создан запрос. Поставщик удостоверений может использовать это для реализации некоторой политики - например, отклонить запросы, полученные более 5 минут после их создания.

Ваш ответ на вопрос