SAMLAssertion policy (Criteri di asserzione SAML)

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

Cosa

• Autenticazione e autorizzazione in entrata: convalida l'asserzione SAML norme
  Il tipo di criterio SAML consente ai proxy API di convalidare le asserzioni SAML collegate a richieste SOAP in entrata. Il criterio SAML convalida i messaggi in arrivo che contengono un asserzione SAML con firma digitale, le rifiuta se non sono valide e imposta variabili che consentire criteri aggiuntivi, o i servizi di backend stessi, per convalidare ulteriormente le informazioni nell'asserzione.
• Generazione di token in uscita: genera 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 consentire ai servizi di backend di applicare ulteriore sicurezza per l'autenticazione e l'autorizzazione.

Esempi

<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 consente alle applicazioni di scambiare informazioni in formato XML per l'autenticazione e autorizzazione.

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

• Provider di identità: generazione di asserzioni di sicurezza per conto dei partecipanti
• Provider di servizi: convalida le asserzioni di sicurezza attraverso relazioni di fiducia con identità provider

La piattaforma API può fungere da provider di identità e da fornitore di servizi. Funge da il provider di identità generando asserzioni e allegandole ai messaggi di richiesta, in modo che disponibili per l'elaborazione da parte dei servizi di backend. Funge da fornitore di servizi convalidare le asserzioni nei messaggi di richiesta in entrata.

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

Genera asserzione SAML

Elaborazione criteri:

1. Se il messaggio non è in formato XML e IgnoraContentType non è impostato su true, segnalare un errore.
2. Se "Modello" , quindi elabora il modello come descritto per il criterioAssignMessage. Se mancano delle variabili e IgnoraUnresolvedVariables non è impostata, genera un errore.
3. Se "Modello" se non è impostato, crea un'asserzione che includa i valori dei Parametri soggetto ed emittente o relativi riferimenti.
4. Firma l'asserzione utilizzando la chiave specificata.
5. Aggiungi l'asserzione al messaggio nell'XPath specificato.

Convalida asserzione SAML

Elaborazione 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 <IgnoreContentType> non è configurato, il criterio genererà un errore.
2. Il criterio analizzerà il file XML. Se l'analisi non riesce, genera un errore.
3. Il criterio estrarrà l'elemento firmato e l'asserzione, utilizzando i rispettivi XPath specificato (<SignedElementXPath> e <AssertionXPath>). Se uno di questi percorsi non restituisce un elemento, il criterio genera un errore.
4. Il criterio verificherà che l'asserzione corrisponda all'elemento firmato oppure è un elemento secondario dell'elemento firmato. In caso contrario, il criterio genererà un errore.
5. Se <NotBefore> o <NotOnOrAfter> sono presenti elementi nell'asserzione, il criterio controllerà il timestamp corrente 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 in SAML Core, sezione 2.5.1.1.
7. Il criterio convaliderà la firma digitale XML, utilizzando i valori di <TrustStore> e <ValidateSigner> come descritto sopra. Se la convalida non va a buon fine, il criterio genera un errore.

Quando il criterio viene completato senza segnalare un errore, lo sviluppatore del proxy può essere certo dei seguenti:

• La firma digitale sull'asserzione è valida ed è stata firmata da un'autorità di certificazione 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 relativi all'utilizzo di questi valori per un'autenticazione aggiuntiva, come controllare che il nome dell'oggetto sia valido o passarlo a un sistema di destinazione per la convalida.

Per analizzare il codice XML non elaborato dell'asserzione è possibile utilizzare altri criteri, come ExtractVariables per una convalida più complessa.

Variabili di flusso

In un'asserzione SAML è possibile specificare molte informazioni. Il protocollo SAML l'asserzione stessa è un file XML che può essere analizzato utilizzando il criterio ExtractVariables e altro in modo da 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. È importante sapere se stai sviluppando regole di errore per per gestire gli errori. Per saperne di più, consulta Cosa devi sapere sugli errori relativi ai criteri e sulla gestione di errore.

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 ulteriori informazioni, vedi Cosa devi sapere sugli errori relativi alle norme.

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 di variabili: Estrai variabili norme