Criteri SAMLAssertion

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

Cosa

• Autenticazione e autorizzazione in entrata: convalida il 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 asserzioni di sicurezza vengono gestite e utilizzate da due tipi di entità:

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

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

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

Genera asserzione SAML

Elaborazione dei criteri:

1. Se il messaggio non è in formato XML e l'API IgnoraContentType non è impostata su true, segnala un errore.
2. Se è impostata l'opzione "Template" (Modello), elabora il modello come descritto per il criterio AssegnaMessage. Se mancano delle variabili e IgnoraUnresolvedVariables non è impostato, genera un errore.
3. Se "Template" non è impostato, crea un'asserzione che includa i valori dei parametri Subject ed Issuer o dei 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 contenuti corrisponde ai formati text/(.*+)?xml o application/(.*+)?xml. Se il tipo multimediale non è XML e il criterio <IgnoreContentType> non è impostato, il criterio genererà un errore.
2. Il criterio analizzerà il codice XML. Se l'analisi non va a buon fine, verrà segnalato 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 alcun elemento, il criterio causerà un errore.
4. Il criterio verificherà che l'asserzione corrisponda all'elemento firmato o è un elemento secondario dell'elemento firmato. Se non è vero, il criterio genererà 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 SAML Core 2.5.1.
6. Il criterio applicherà eventuali regole aggiuntive per l'elaborazione delle "Condizioni" come descritto nella sezione SAML Core 2.5.1.1.
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 genererà un errore.

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

• La firma digitale sull'asserzione è valida ed è stata firmata da un'autorità di certificazione attendibile
• L'asserzione è valida per il periodo di tempo corrente
• Il soggetto 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

È possibile specificare molte informazioni in un'asserzione SAML. L'asserzione SAML stessa è un file XML che può essere analizzato utilizzando il criterio ExtractVariables e altri meccanismi al fine di implementare convalide più complesse.

Messaggi di errore

Questa sezione descrive i codici e i messaggi di errore restituiti e le variabili di errore impostate da Edge quando questo criterio attiva un errore. Queste informazioni sono importanti per sapere se si stanno sviluppando regole di errore per gestire gli errori. Per scoprire di più, consulta gli articoli Cosa devi sapere sugli errori relativi alle norme e 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 relativi ai criteri.

Esempio di risposta di errore

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

Esempio di regola di errore

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

Argomenti correlati

Estrazione delle variabili: criterio di estrazione delle variabili