Правила SAMLAssertion

Вы просматриваете документацию по 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 Core и версии 1.0 спецификации профиля токена WS-Security SAML.

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

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

1. Если сообщение не является XML-файлом и для параметра IgnoreContentType не задано значение true, то возникает ошибка.
2. Если задано значение "Шаблон", обработайте шаблон, как описано в правиле AssignMessage. Если какие-либо переменные отсутствуют и параметр IgnoreUnresolvedVariables не задан, то возникает ошибка.
3. Если шаблон не задан, создайте утверждение, включающее значения параметров 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 Core.
6. Правило будет применять любые дополнительные правила обработки элемента "Условия", как описано в разделе 2.5.1.1 спецификации SAML Core.
7. Правило проверяет цифровую подпись XML, используя значение хранилища доверенных сертификатов (<TrustStore>), описанное выше. Если проверка не пройдена, правило вызывает ошибку.

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

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

Для более сложной проверки можно использовать другие правила, например 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>

Статьи по теме

Извлечение переменных: правило Extract Variables