Политики утверждений 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 и других механизмов для реализации более сложных проверок.

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

В этом разделе описаны коды ошибок и сообщения об ошибках, которые возвращаются, а также переменные ошибок, которые устанавливаются Edge, когда эта политика вызывает ошибку. Эту информацию важно знать, если вы разрабатываете правила обработки ошибок. Дополнительные сведения см. в разделах Что нужно знать об ошибках политики и Обработка ошибок .

Ошибки развертывания

Эти ошибки могут возникнуть при развертывании прокси-сервера, содержащего эту политику.

Переменные неисправности

Эти переменные устанавливаются при возникновении ошибки во время выполнения. Дополнительные сведения см. в разделе Что нужно знать об ошибках политики .

Пример ответа об ошибке

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

Пример правила неисправности

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

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

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