Políticas de SAMLAssertion

Estás consultando la documentación de Apigee Edge.
Consulta la documentación de Apigee X. Información

Qué

• Autenticación y autorización entrantes: Valida la política de aserciones de SAML
  El tipo de política de SAML permite que los proxies de API validen las aserciones de SAML adjuntas a las solicitudes de SOAP entrantes. La política de SAML valida los mensajes entrantes que contienen una aserción SAML con firma digital, los rechaza si no son válidos y configura variables que permiten políticas adicionales, o los servicios de backend, para validar aún más la información en la aserción.
• Generación de tokens de salida: Genera una política de aserciones de SAML
  El tipo de política de SAML permite que los proxies de API adjunten aserciones de SAML para solicitudes XML salientes. Esas aserciones están disponibles para permitir que los servicios de backend apliquen más procesos de seguridad para la autenticación y la autorización.

Ejemplos

<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>

Referencia del elemento

Genera una aserción de SAML

Valida la aserción de SAML

Notas de uso:

La especificación del Lenguaje de marcado para confirmaciones de seguridad (SAML) define formatos y protocolos que permiten a las aplicaciones intercambiar información con formato XML para la autenticación y la autorización.

Una “aserción de seguridad” es un token de confianza que describe el atributo de una app, un usuario de la app o algún otro participante en una transacción. Dos tipos de entidades administran y consumen las aserciones de seguridad:

• Proveedores de identidad: Generan aserciones de seguridad en nombre de los participantes
• Proveedores de servicios: Validan las aserciones de seguridad a través de relaciones de confianza con proveedores de identidad

La plataforma de API puede actuar como un proveedor de identidad y como proveedor de servicios. Actúa como un proveedor de identidad mediante la generación de aserciones y los adjunta para solicitar mensajes, lo que hace que estén disponibles para que los servicios de backend las procesen. Funciona como un proveedor de servicios mediante la validación de las aserciones en los mensajes de solicitudes entrantes.

El tipo de política de SAML admite aserciones de SAML que coinciden con la versión 2.0 de la Especificación principal de SAML y la versión 1.0 de la especificación del perfil de token de SAML de WS-Security.

Genera una aserción de SAML

Procesamiento de políticas:

1. Si el mensaje no es XML y IgnoreContentType no está configurado en true, se genera un error.
2. Si la opción "Plantilla" está configurada, procesa la plantilla como se describe para la política AssignMessage. Si falta alguna variable y no se configura IgnoreUnresolvedVariables se, genera un error.
3. Si la "Plantilla" no está configurada, crea una aserción que incluya los valores de los parámetros Asunto y Emisor o sus referencias.
4. Firma la aserción mediante la clave especificada.
5. Agrega la aserción al mensaje en la XPath especificada.

Valida la aserción de SAML

Procesamiento de políticas:

1. La política verifica el mensaje entrante para comprobar que el tipo de medio de la solicitud sea XML. Para ello, comprueba si el tipo de contenido coincide con los formatos text/(.*+)?xml o application/(.*+)?xml. Si el tipo de medio no es XML y no se establece <IgnoreContentType>, la política generará un error.
2. La política analizará el XML. Si no se realiza correctamente el análisis, se producirá un error.
3. La política extraerá el elemento firmado y la aserción mediante las XPaths respectivas especificadas (<SignedElementXPath> y <AssertionXPath>). Si alguna de estas rutas de acceso no muestra un elemento, la política generará un error.
4. La política verificará que la aserción sea la misma que el elemento firmado o que sea un elemento secundario de este. Si este no es el caso, la política generará una falla.
5. Si alguno de los elementos <NotBefore> o <NotOnOrAfter> está presente en la aserción, la política verificará la marca de tiempo actual con estos valores, como se describe en la sección 2.5.1 de SAML Core.
6. La política aplicará cualquier regla adicional para procesar las "Condiciones", como se describe en la sección 2.5.1.1 del núcleo de SAML.
7. La política validará la firma digital XML con los valores de <TrustStore> y <ValidateSigner>, como se describió anteriormente. Si la validación falla, la política generará una falla.

Una vez que se complete la política sin generar un error, el desarrollador del proxy puede estar seguro de lo siguiente:

• La firma digital de la aserción es válida y cuenta con la firma de una CA de confianza
• La aserción es válida para el período actual
• El sujeto y la entidad emisora de la aserción se extraerán y se configurarán en las variables de flujo. Es responsabilidad de otras políticas usar estos valores para la autenticación adicional, por ejemplo, verificar que el nombre del asunto sea válido o transferirlo a un sistema de destino para validarlo.

Otras políticas, como ExtractVariables, se pueden usar para analizar el XML sin procesar de la aserción para obtener una validación más compleja.

Variables de flujo

Existen muchos datos que pueden especificarse en una aserción de SAML. La aserción de SAML es XML y se puede analizar mediante la política ExtractVariables y otros mecanismos para implementar validaciones más complejas.

Referencia de errores

En esta sección, se describen los códigos y mensajes de error que se muestran, así como las variables de fallas que establece Edge cuando esta política activa un error. Esta información es importante para saber si estás desarrollando reglas de fallas con el propósito de manejar fallas. Para obtener más información, consulta Qué debes saber sobre los errores de políticas y Cómo solucionar fallas.

Errores en la implementación

Estos errores pueden generarse cuando implementas un proxy que contiene esta política.

Variables con fallas

Estas variables se configuran cuando se genera un error de entorno de ejecución. Para obtener más información, consulta Qué debes saber sobre los errores de la política.

Ejemplo de respuesta de error

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

Ejemplo de regla de falla

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

Temas relacionados

Extrae variables: política de extracción de variables