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

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

Что

• Входящая аутентификация и авторизация: проверка политики утверждений 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

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

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

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

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

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

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

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

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

1. Если сообщение не является XML-файлом и параметр IgnoreContentType не установлен в true , то следует вызвать ошибку.
2. Если параметр "Template" задан, обработайте шаблон, как описано для политики AssignMessage. Если какие-либо переменные отсутствуют и параметр IgnoreUnresolvedVariables не задан, вызовите ошибку.
3. Если параметр "Template" не задан, то сформируйте утверждение, включающее значения параметров Subject и Issuer или их ссылки.
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> ), описанное выше. Если проверка не удается, политика генерирует ошибку.

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

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

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

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

В утверждении 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>

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

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