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

Справочник по ошибкам

В этом разделе описаны коды ошибок и сообщения об ошибках, которые возвращаются, а также переменные ошибок, которые задаются 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>

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

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