Solución de problemas de errores deimplementación de la política de confirmación de SAML

Estás viendo la documentación de Apigee Edge.
Ve a la documentación de Apigee X. info

SourceNotConfigured

Mensaje de error

Si la implementación del proxy de API a través de la IU de Edge o la API de administración de Edge falla, se mostrará este mensaje de error:

Error Deploying Revision revision_number to environment
ValidateSAMLAssertion[policy_name]: Source is not correctly configured.

Ejemplo de mensaje de error

Error Deploying Revision 2 to test
ValidateSAMLAssertion[Validate-SAML-Assertion-1]: Source is not correctly configured.

Captura de pantalla de error de ejemplo

Causa

La implementación del proxy de API falla con este error si uno o más de los siguientes elementos de la política de confirmación de SAML validada no están definidos o vacíos: <Source>, <XPath>, <Namespaces>, <Namespace>.

Por ejemplo, la implementación del proxy de API fallará si pierdes el elemento <XPath> o dejas el elemento <Source> o sus entidades vacías.

Diagnóstico

1. Identifica el nombre de la política de confirmación de SAML fallidas enel mensaje de error. Por ejemplo, en el siguiente error, el nombre de la política de solicitud de confirmación de SAML es Validate-SAML-Assertion-1.

   ValidateSAMLAssertion[Validate-SAML-Assertion-1]: Source is not correctly configured.
   

2. Examina el archivo XML de la política de aserción de SAML con errores. Verifica si falta uno o más de los siguientes elementos de la política: <Source>, <XPath>, <Namespaces>, <Namespace>. De ser así, esa podría ser la causa del error.

   Por ejemplo, la siguiente política tiene un elemento <Namespaces> vacío en el elemento <Source>:

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <ValidateSAMLAssertion name="SAML" ignoreContentType="false">
     <Source name="request">
       <Namespaces></Namespaces>
      </Source>
      <Description/>
    <TrustStore>ref://TrustStoreName</Truststore>
    <RemoveAssertion>false</RemoveAssertion>
   </ValidateSAMLAssertion>
   

3. En el ejemplo anterior, el elemento <Namespaces> está vacío, por lo que recibes el siguiente error:

   ValidateSAMLAssertion[Validate-SAML-Assertion-1]: Source is not correctly configured.
   

Solución

Asegúrate de que los valores del elemento <Source> estén configurados de forma correcta con el elemento <Namespaces> y su elemento secundario <Namespace>. También debes asegurarte de que el elemento <XPath> esté definido y no esté vacío.

Para corregir el ejemplo de la Política de confirmación de SAML que se muestra arriba, puedes agregar los elementos <Namespace> y <XPath>:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<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>
    <XPath>/soap:Envelope/soap:Header/wsse:Security/saml:Assertion</XPath>
  </Source>
   <Description/>
<TrustStore>ref://TrustStoreName</Truststore>
<RemoveAssertion>false</RemoveAssertion>
</ValidateSAMLAssertion>

TrustStoreNotConfigured

Mensaje de error

Si la implementación del proxy de API a través de la IU de Edge o la API de administración de Edge falla, se mostrará este mensaje de error:

Error Deploying Revision revision_number to environment
ValidateSAMLAssertion[[Ljava.lang.Object;@object]: Trust store is not correctly configured.

Ejemplo de mensaje de error

Error Deploying Revision 2 to test
ValidateSAMLAssertion[[Ljava.lang.Object;@39537262]: Trust store is not correctly configured.

Captura de pantalla de error de ejemplo

Causa

Si el elemento <TrustStore> está vacío o no se especifica en la política ValidateSAMLAssertion, falla la implementación del proxy de API. Se requiere un almacenamiento de confianza válido.

Diagnóstico

1. Examina todas las políticas de confirmación de SAML en el proxy de API específico en el que se produjo el error. Si hay una política de confirmación de SAML en la que el elemento <TrustStore> está vacío o no se especifica, esa es la causa del error.

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <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>
       <XPath>/soap:Envelope/soap:Header/wsse:Security/saml:Assertion</XPath>
     </Source>
       <Description/>
       <TrustStore/>
     <RemoveAssertion>false</RemoveAssertion>
   </ValidateSAMLAssertion>
   

Solución

Asegúrate de que el elemento <TrustStore> siempre esté especificado y no esté vacío en la política de confirmación de SAML. El nombre <TrustStore> debe coincidir con el nombre de un almacén de confianza válido que exista en todos los entornos en los que intentas implementar un proxy.

Para corregir el ejemplo anterior, puedes especificar el elemento <TrustStore> con un valor válido.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<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>
    <XPath>/soap:Envelope/soap:Header/wsse:Security/saml:Assertion</XPath>
  </Source>
  <TrustStore>TrustStoreName</TrustStore>
  <RemoveAssertion>false</RemoveAssertion>
</ValidateSAMLAssertion>

Consulta Truststores y almacenes de claves para obtener más información sobre cómo usar Truststore.

NullKeyStore

Mensaje de error

La implementación del proxy de API a través de la IU de Edge o de la API de Edge Management falla y muestra el siguiente mensaje de error:

Error Deploying Revision revision_number to environment
Assertion KeyStore name cannot be null.

Ejemplo de mensaje de error

Error Deploying Revision 4 to test
Assertion KeyStore name cannot be null.

Captura de pantalla de error de ejemplo

Causa

La implementación del proxy de la API fallará si el elemento secundario <Name> está vacío o no se especifica en el elemento <Keystore> de la política GenerateSAMLAssertion. Se requiere el nombre de almacén de claves válido.

Diagnóstico

1. Examina todas las políticas de confirmación de SAML en el proxy de API específico en el que se produjo el error. Si hay una política de confirmación de SAML en la que el elemento secundario <Name> esté vacío o no se haya especificado en el elemento <Keystore>, esa es la causa del error.

   La siguiente política de Generación de confirmaciónde SAML tiene un elemento secundario <Name> vacío en el elemento <Keystore>:

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <GenerateSAMLAssertion name="SAML" ignoreContentType="false">`
     <CanonicalizationAlgorithm />
     <Issuer ref="reference">Issuer name</Issuer>
     <KeyStore>
       <Name></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>
   

Solución

Asegúrate de que el elemento secundario <Name> siempre esté especificado y no esté vacío dentro del elemento <Keystore> de la política Generar política deconfirmación de SAML.

A fin de corregir el ejemplo anterior, puedes especificar el elemento <Name> de forma correcta y asegurarte de que se especifique un valor válido para el elemento <Alias>.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<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>

Consulta los ejemplos de Muestras de código del artículo de referencia de la política SAMLAssertion.

NullKeyStoreAlias

Mensaje de error

Si la implementación del proxy de API a través de la IU de Edge o la API de administración de Edge falla, se mostrará este mensaje de error:

Error Deploying Revision revision_number to environment
Assertion KeyStore alias cannot be null.

Ejemplo de mensaje de error

Error Deploying Revision 4 to test
Assertion KeyStore alias cannot be null.

Captura de pantalla de error de ejemplo

Causa

La implementación del proxy de API fallará si el elemento secundario <Alias> está vacío o no se especifica en el elemento <Keystore> de la política de Generación de confirmación de SAML. Se requiere un alias del almacén de claves válido.

Diagnóstico

1. Examina todas las políticas Generar confirmación de SAML en el proxy de API específico en el que se produjo el error. Si hay una política de confirmación de SAML en la que el elemento secundario <Alias> esté vacío o no se haya especificado en el elemento <Keystore>, esa es la causa del error.

   La siguiente política de Generación de confirmaciónde SAML tiene un elemento secundario <Alias> vacío en el elemento <Keystore>:

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <GenerateSAMLAssertion name="SAML" ignoreContentType="false">`
     <CanonicalizationAlgorithm />
     <Issuer ref="reference">Issuer name</Issuer>
     <KeyStore>
       <Name ref="reference">keystorename</Name>
       <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>
   

Solución

Asegúrate de que el elemento secundario <Name> siempre esté especificado y que no esté vacío dentro del elemento <Keystore> de la política de generación de aserción de SAML.

A fin de corregir el ejemplo anterior, puedes especificar el elemento <Alias> de forma correcta y asegurarte de que se especifique un valor válido para el elemento <Name>.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<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>

Consulta los ejemplos de Muestras de código del artículo de referencia de la política SAMLAssertion.

NullIssuer

Mensaje de error

Si la implementación del proxy de API a través de la IU de Edge o la API de administración de Edge falla, se mostrará este mensaje de error:

Error Deploying Revision revision_number to environment
Assertion Issuer cannot be null.

Ejemplo de mensaje de error

Error Deploying Revision 4 to test
Assertion Issuer cannot be null.

Captura de pantalla de error de ejemplo

Causa

Si el elemento <Issuer> está vacío o no se especifica en la política de generación de confirmación de SAML, la implementación del proxy de API falla. Se requiere un valor válido de <Issuer>.

Diagnóstico

1. Examina todas las políticas de confirmación de SAML en el proxy de API específico en el que se produjo el error. Si hay una política de confirmación de SAMLen la que el elemento <Issuer> esté vacío o no se especifique, esa es la causa del error.

   La siguiente política de Generación de confirmaciónde SAML tiene un elemento <Issuer> vacío:

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <GenerateSAMLAssertion name="SAML" ignoreContentType="false">`
     <CanonicalizationAlgorithm />
     <Issuer></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>
   

Solución

Asegúrate de que el elemento <Issuer> siempre esté especificado y no esté vacío en la política de Generación de confirmación deSAML.

Para corregir el ejemplo anterior, especifica el elemento <Issuer> de forma correcta:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<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>

Consulta los ejemplos de Muestras de código del artículo de referencia de la política SAMLAssertion.