Q: OKTA - привязка к артефакту и незапрашиваемый доступ провайдера Идентификатор?

Question

Мы читали окта руководства, но есть два нерешенных вопроса:

1. делает OKTA поддержка Артефакт связывания https://en.wikipedia.org/wiki/SAML_2.0#HTTP_Artifact_Binding
2. делает связывание OKTA/SAML поддержка 2,0 незапрашиваемая идентификации (IDP) артефакт, или это обязательно должны быть перенаправлены от поставщика услуг (SP)?

Что касается первого вопроса

Мы сталкиваемся с ситуацией, когда большое количество данных, должны были бы быть переданы через агента пользователя, и мы также мотивировано безопасности передовой практики. Наше мнение заключается в том, что привязка артефактов является лучшей моделью безопасности для SAML 2.0; а также уменьшит нагрузку на пользовательский агент. Может ли OKTA поддерживать привязку артефакта? Мы не смогли найти ни положительное, ни отрицательное подтверждение в документации. Много извинений, если это контроль с нашей стороны.

Что касается второго вопроса

Задача, которую мы решаем, что мы интегрируем с организацией, у которых есть портал продуктов, которые они рекомендуют и для которых они организовали доступ через свой портал. Каждый из этих продуктов требует аутентификации, что делает хороший случай для Single Sign On (SSO). Обеим сторонам интеграции хотелось бы, чтобы пользователь мог: кликнуть по ссылке и войти в службу. Это отличается от большинства моделей для любых режимов работы SAML 2.0, поскольку рабочий процесс начинается с IdP, а не с SP. Возможно ли это в OKTA или вообще в SAML 2.0? Опять же, многие извинения, если мы пропустили это в документации.

Answer 1

1. Проверьте метаданные, сгенерированные Okta. Если он поддерживает привязку артефакта для сообщений, отправленных в SP, в метаданных будет указан ArtifactResolutionService.

2. Стандарт SAML2 поддерживает незапрошенную привязку артефакта. Однако я не знаю, есть ли Okta.

Answer 2

Не кажется, что Okta поддерживает это при проверке метаданных.

Wikipedia показывает, что элемент ArtifactResolutionService будет выглядеть в метаданных:

<md:IDPSSODescriptor 
    protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> 
    <md:KeyDescriptor use="signing"> 
     <ds:KeyInfo>...</ds:KeyInfo> 
    </md:KeyDescriptor> 
    <md:ArtifactResolutionService isDefault="true" index="0" 
     Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" 
     Location="https://idp.example.org/SAML2/ArtifactResolution"/> 
    <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat> 
    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat> 
    <md:SingleSignOnService 
     Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" 
     Location="https://idp.example.org/SAML2/SSO/Redirect"/> 
    <md:SingleSignOnService 
     Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
     Location="https://idp.example.org/SAML2/SSO/POST"/> 
    <md:SingleSignOnService 
     Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" 
     Location="https://idp.example.org/SAML2/Artifact"/> 
    <saml:Attribute 
     NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 
     Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1" 
     FriendlyName="eduPersonAffiliation"> 
     <saml:AttributeValue>member</saml:AttributeValue> 
     <saml:AttributeValue>student</saml:AttributeValue> 
     <saml:AttributeValue>faculty</saml:AttributeValue> 
     <saml:AttributeValue>employee</saml:AttributeValue> 
     <saml:AttributeValue>staff</saml:AttributeValue> 
    </saml:Attribute> 
    </md:IDPSSODescriptor> 

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