Политики утверждений SAML

Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация

Что

• Входящая аутентификация и авторизация: проверка политики утверждений SAML
  Тип политики SAML позволяет прокси-серверам API проверять утверждения SAML, прикрепленные к входящим запросам SOAP. Политика SAML проверяет входящие сообщения, содержащие утверждение SAML с цифровой подписью, отклоняет их, если они недействительны, и устанавливает переменные, которые позволяют дополнительным политикам или самим серверным службам дополнительно проверять информацию в утверждении.
• Генерация исходящего токена: создание политики утверждений SAML
  Тип политики SAML позволяет прокси-серверам API присоединять утверждения SAML к исходящим запросам XML. Затем эти утверждения становятся доступными, чтобы позволить серверным службам применить дальнейшую обработку безопасности для аутентификации и авторизации.

Образцы

<GenerateSAMLAssertion name="SAML" ignoreContentType="false">
  <CanonicalizationAlgorithm />
  <Issuer ref="reference">Issuer name</Issuer>
  <KeyStore>
    <Name ref="reference">keystorename</Name>
    <Alias ref="reference">alias</Alias>
  </KeyStore>
  <OutputVariable>
    <FlowVariable>assertion.content</FlowVariable>
    <Message name="request">
      <Namespaces>
        <Namespace prefix="test">http://www.example.com/test</Namespace>
      </Namespaces>
      <XPath>/envelope/header</XPath>
    </Message>
  </OutputVariable>
  <SignatureAlgorithm />
  <Subject ref="reference">Subject name</Subject>
  <Template ignoreUnresolvedVariables="false">
    <!-- A lot of XML goes here, in CDATA, with {} around
         each variable -->
  </Template>
</GenerateSAMLAssertion>

<ValidateSAMLAssertion name="SAML" ignoreContentType="false">
  <Source name="request">
    <Namespaces>
      <Namespace prefix='soap'>http://schemas.xmlsoap.org/soap/envelope/</Namespace>
      <Namespace prefix='wsse'>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd</Namespace>
      <Namespace prefix='saml'>urn:oasis:names:tc:SAML:2.0:assertion</Namespace>
    </Namespaces>
    <AssertionXPath>/soap:Envelope/soap:Header/wsse:Security/saml:Assertion</AssertionXPath>
    <SignedElementXPath>/soap:Envelope/soap:Header/wsse:Security/saml:Assertion</SignedElementXPath>
  </Source>
  <TrustStore>TrustStoreName</TrustStore>
  <RemoveAssertion>false</RemoveAssertion>
</ValidateSAMLAssertion>

Ссылка на элемент

Создать утверждение SAML

Проверка утверждения SAML

Примечания по использованию

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

«Утверждение безопасности» — это доверенный токен, который описывает атрибут приложения, пользователя приложения или другого участника транзакции. Утверждения безопасности управляются и используются двумя типами объектов:

• Поставщики удостоверений: создание утверждений безопасности от имени участников.
• Поставщики услуг: проверка утверждений безопасности посредством доверительных отношений с поставщиками удостоверений.

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

Тип политики SAML поддерживает утверждения SAML, соответствующие версии 2.0 базовой спецификации SAML и версии 1.0 спецификации профиля токена SAML WS-Security.

Создать утверждение SAML

Обработка политики:

1. Если сообщение не является XML и для IgnoreContentType не установлено значение true , возникает ошибка.
2. Если установлен «Шаблон», обработайте шаблон, как описано для политики AssignMessage. Если какие-либо переменные отсутствуют и параметр IgnoreUnresolvedVariables не установлен, возникает ошибка.
3. Если «Шаблон» не установлен, создайте утверждение, включающее значения параметров «Субъект» и «Издатель» или их ссылки.
4. Подпишите утверждение, используя указанный ключ.
5. Добавьте утверждение в сообщение по указанному XPath.

Проверка утверждения SAML

Обработка политики:

1. Политика проверяет входящее сообщение, чтобы убедиться, что тип носителя запроса — XML, проверяя, соответствует ли тип контента форматам text/(.*+)?xml или application/(.*+)?xml . Если тип носителя не XML и <IgnoreContentType> не установлен, политика выдаст ошибку.
2. Политика будет анализировать XML. Если синтаксический анализ не удался, это вызовет ошибку.
3. Политика извлечет подписанный элемент и утверждение, используя соответствующие указанные XPath ( <SignedElementXPath> и <AssertionXPath> ). Если ни один из этих путей не возвращает элемент, политика выдаст ошибку.
4. Политика проверит, что утверждение совпадает с подписанным элементом или является дочерним элементом подписанного элемента. Если это не так, то политика вызовет ошибку.
5. Если в утверждении присутствует любой из элементов <NotBefore> или <NotOnOrAfter> , политика проверит текущую метку времени по этим значениям, как описано в разделе 2.5.1 ядра SAML.
6. Политика будет применять любые дополнительные правила для обработки «Условий», как описано в разделе 2.5.1.1 ядра SAML.
7. Политика проверит цифровую подпись XML, используя значения <TrustStore> и <ValidateSigner> , как описано выше. Если проверка не удалась, политика выдаст ошибку.

Как только политика завершится без возникновения ошибок, разработчик прокси-сервера может быть уверен в следующем:

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

Другие политики, такие как ExtractVariables, могут использоваться для анализа необработанного XML утверждения для более сложной проверки.

Переменные потока

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

Ссылка на ошибку

This section describes the fault codes and error messages that are returned and fault variables that are set by Edge when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.

Deployment errors

These errors can occur when you deploy a proxy containing this policy.

Fault variables

These variables are set when a runtime error occurs. For more information, see What you need to know about policy errors.

Example error response

{
  "fault": {
    "faultstring": "GenerateSAMLAssertion[GenSAMLAssert]: Invalid media type",
    "detail": {
      "errorcode": "steps.saml.generate.InvalidMediaTpe"
    }
  }
}

Example fault rule

<FaultRules>
    <FaultRule name="invalid_saml_rule">
        <Step>
            <Name>invalid-saml</Name>
        </Step>
        <Condition>(GenerateSAMLAssertion.failed = "true")</Condition>
    </FaultRule>
</FaultRules>

Связанные темы

Извлечение переменных: политика извлечения переменных