Процесс аутентификации SAML SSO для настраиваемого соединителя SAML в приложениях Jumpcloud - PullRequest
0 голосов
/ 26 октября 2019

мы пытаемся JumpCloud для IDaaS для одного из наших приложений и пытаемся настроить SSO для входа в него с помощью специального соединителя SAML 2.0.

Мы уже настроили конечную точку обслуживания потребителя утверждений, которая получает POST-ответ после успешной аутентификации пользователя. Теперь мы можем успешно получить SAMLResponse там, но я не могу выяснить следующие шаги здесь? передать этот подписанный / зашифрованный ответ веб-приложению как есть и использовать его для проверки запросов API, или мне нужно запросить jumpcloud для токена, связанного с этим ответом.

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

Кроме того, настройки длительности сеанса пользователя организации в jumpcloud установлены на 1 час, а время истечения в SAMLResponse, похоже, составляет всего 5 минут после создания токена, так что мне делать, если нам нужно расширить этодлительность токена, потому что я не хочу, чтобы пользователи заходили в систему через каждые 5 минут.

Может ли кто-нибудь с опытом / знакомством с JumpCloud, пожалуйста, помочь / указать мне правильное направление здесь?

Вот пример SAMLResponse, который я получаю от IDP -

<?xml version="1.0" encoding="UTF-8"?>
<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xs="http://www.w3.org/2001/XMLSchema" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" Destination="https://ixr6rl0xpk.execute-api.us-east-1.amazonaws.com/dev/saml" ID="MGAZWYVBHO9VMET0GNQAG1YILCCALLJL1QZUCTLN" IssueInstant="2019-10-24T14:38:11.414Z" Version="2.0">
    <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">jumpcloud</saml2:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
            <ds:Reference URI="#MGAZWYVBHO9VMET0GNQAG1YILCCALLJL1QZUCTLN">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                        <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="xs" />
                    </ds:Transform>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                <ds:DigestValue>qQY2SBgD...</ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>H8XemIw1nNCkq7nL...</ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>MIIFfTCCA2W...</ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <saml2p:Status>
        <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    </saml2p:Status>
    <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="JW4VMBUW3OD8KZJXG07QHLZOLEMNEDDW93H6WPIS" IssueInstant="2019-10-24T14:38:11.414Z" Version="2.0">
        <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">jumpcloud</saml2:Issuer>
        <saml2:Subject>
            <saml2:NameID Format="urn:oasis:names:tc:SAML:1.0:nameid-format:unspecified">email@example.com</saml2:NameID>
            <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <saml2:SubjectConfirmationData NotOnOrAfter="2019-10-24T14:43:11.414Z" Recipient="<ACS_URL>" />
            </saml2:SubjectConfirmation>
        </saml2:Subject>
        <saml2:Conditions NotBefore="2019-10-24T14:33:11.414Z" NotOnOrAfter="2019-10-24T14:43:11.414Z">
            <saml2:AudienceRestriction>
                <saml2:Audience>example.com</saml2:Audience>
            </saml2:AudienceRestriction>
        </saml2:Conditions>
        <saml2:AttributeStatement>
            <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>
        </saml2:AttributeStatement>
        <saml2:AuthnStatement AuthnInstant="2019-10-24T14:38:11.414Z" SessionIndex="330dafe4-e541-4b93-85b2-2c5d76d75996">
            <saml2:AuthnContext>
                <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>
            </saml2:AuthnContext>
        </saml2:AuthnStatement>
    </saml2:Assertion>
</saml2p:Response>

1 Ответ

0 голосов
/ 30 октября 2019

Обычно в 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) и вставьте ее в существующее «что-то».

...