Criteri SAMLAssertion

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. informazioni

Cosa

• Autenticazione e autorizzazione in entrata: convalida criterio di asserzione SAML
  Il tipo di criterio SAML consente ai proxy API di convalidare le asserzioni SAML collegate alle richieste SOAP in entrata. Il criterio SAML convalida i messaggi in arrivo che contengono un'asserzione SAML con firma digitale, li rifiuta se non sono validi e imposta variabili che consentono criteri aggiuntivi, o i servizi di backend stessi, per convalidare ulteriormente le informazioni nell'asserzione.
• Generazione di token in uscita: genera un criterio di asserzione SAML
  Il tipo di criterio SAML consente ai proxy API di collegare le asserzioni SAML alle richieste XML in uscita. Queste asserzioni sono quindi disponibili per abilitare i servizi di backend per applicare ulteriori elaborazioni di sicurezza per l'autenticazione e l'autorizzazione.

Samples

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

Riferimento elemento

Genera asserzione SAML

Convalida asserzione SAML

Note sull'utilizzo

La specifica SAML (Security Assertion Markup Language) definisce i formati e i protocolli che consentono alle applicazioni di scambiare informazioni in formato XML per l'autenticazione e l'autorizzazione.

Un'"asserzione di sicurezza" è un token attendibile che descrive un attributo di un'app, un utente dell'app o un altro partecipante a una transazione. Le dichiarazioni di sicurezza vengono gestite e utilizzate da due tipi di entità:

• Provider di identità: generano asserzioni di sicurezza per conto dei partecipanti
• Provider di servizi: convalida le dichiarazioni di sicurezza tramite relazioni di fiducia con i provider di identità

La piattaforma API può fungere da provider di identità e da provider di servizi. Agisce da provider di identità generando asserzioni e collegandole ai messaggi di richiesta, rendendole disponibili per l'elaborazione da parte dei servizi di backend. Agisce come fornitore di servizi convalidando le asserzioni sui messaggi di richiesta in entrata.

Il tipo di criterio SAML supporta le asserzioni SAML corrispondenti alla versione 2.0 della specifica SAML Core e alla versione 1.0 della specifica del profilo token SAML WS-Security.

Genera asserzione SAML

Elaborazione dei criteri:

1. Se il messaggio non è XML e IgnoraContentType non è impostato su true, segnala un errore.
2. Se "Modello" è impostato, elabora il modello come descritto per il criterio AssegnaMessage. Se mancano variabili e IgnoraUnresolvedVariables non è impostato, genera un errore.
3. Se "Template" (Modello) non è impostato, costruisci un'asserzione che includa i valori dei parametri Subject ed Issuer o i relativi riferimenti.
4. Firma l'asserzione utilizzando la chiave specificata.
5. Aggiungi l'asserzione al messaggio nell'XPath specificato.

Convalida asserzione SAML

Elaborazione dei criteri:

1. Il criterio controlla il messaggio in entrata per verificare che il tipo multimediale della richiesta sia XML, controllando se il tipo di contenuto corrisponde ai formati text/(.*+)?xml o application/(.*+)?xml. Se il tipo di supporto non è XML e il criterio <IgnoreContentType> non è impostato, il criterio causerà un errore.
2. Il criterio analizzerà il codice XML. Se l'analisi non va a buon fine, verrà generato un errore.
3. Il criterio estrarrà l'elemento firmato e l'asserzione, utilizzando i rispettivi XPath specificati (<SignedElementXPath> e <AssertionXPath>). Se uno di questi percorsi non restituisce un elemento, il criterio causerà un errore.
4. Il criterio verificherà che l'asserzione sia uguale all'elemento firmato o sia un elemento secondario dell'elemento firmato. Se non è vero, il criterio causerà un errore.
5. Se nell'asserzione è presente uno degli elementi <NotBefore> o <NotOnOrAfter>, il criterio controllerà il timestamp attuale con questi valori, come descritto nella sezione 2.5.1 di SAML Core.
6. Il criterio applicherà eventuali regole aggiuntive per l'elaborazione delle "Condizioni", come descritto nella sezione 2.5.1.1 di SAML Core.
7. Il criterio convaliderà la firma digitale XML utilizzando i valori <TrustStore> e <ValidateSigner> come descritto sopra. Se la convalida non va a buon fine, il criterio causerà un errore.

Una volta completato il criterio senza segnalare un errore, lo sviluppatore del proxy può garantire quanto segue:

• La firma digitale sull'asserzione è valida ed è stata firmata da una CA attendibile
• L'asserzione è valida per il periodo di tempo corrente
• L'oggetto e l'emittente dell'asserzione verranno estratti e impostati nelle variabili di flusso. È responsabilità di altri criteri utilizzare questi valori per un'autenticazione aggiuntiva, ad esempio verificare che il nome del soggetto sia valido o passarlo a un sistema di destinazione per la convalida.

Altri criteri, come ExtractVariables, possono essere utilizzati per analizzare il codice XML non elaborato dell'asserzione per una convalida più complessa.

Variabili di flusso

Esistono molte informazioni che possono essere specificate in un'asserzione SAML. L'asserzione SAML stessa è un codice XML che può essere analizzato utilizzando il criterio ExtractVariables e altri meccanismi per implementare convalide più complesse.

Messaggi di errore

Questa sezione descrive i codici e i messaggi di errore che vengono restituiti e le variabili di errore impostate da Edge quando il criterio attiva un errore. Queste informazioni sono importanti per sapere se stai sviluppando regole di errore per gestire gli errori. Per scoprire di più, consulta le informazioni relative agli errori dei criteri e la gestione degli errori.

Errori di deployment

Questi errori possono verificarsi quando esegui il deployment di un proxy contenente questo criterio.

Variabili di errore

Queste variabili vengono impostate quando si verifica un errore di runtime. Per maggiori informazioni, consulta la sezione Cosa devi sapere sugli errori delle norme.

Esempio di risposta all'errore

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

Regola di errore di esempio

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

Argomenti correlati

Estrazione delle variabili: Estrai criterio delle variabili