Criteri SAMLAssertion

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

Cosa

• Autenticazione e autorizzazione in entrata: policy Validate SAML Assertion
  Il tipo di policy SAML consente ai proxy API di convalidare le asserzioni SAML allegate alle richieste SOAP in entrata. La policy SAML convalida i messaggi in entrata che contengono un' asserzione SAML firmata digitalmente, li rifiuta se non sono validi e imposta le variabili che consentono a policy aggiuntive o ai servizi di backend stessi di convalidare ulteriormente le informazioni nell'asserzione.
• Generazione di token in uscita: policy Generate SAML Assertion
  Il tipo di policy SAML consente ai proxy API di allegare asserzioni SAML alle richieste XML in uscita. Queste asserzioni sono quindi disponibili per consentire ai servizi di backend di applicare un'ulteriore elaborazione di 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

Generate SAML Assertion

Validate SAML Assertion

Note sull'utilizzo

La specifica SAML (Security Assertion Markup Language) definisce formati e 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, di un utente dell'app, o di un altro partecipante a una transazione. Le asserzioni di sicurezza vengono gestite e utilizzate da due tipi di entità:

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

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

Il tipo di policy SAML supporta le asserzioni SAML che corrispondono alla versione 2.0 della specifica SAML Core e alla versione 1.0 della specifica WS-Security SAML Token Profile.

Generate SAML Assertion

Elaborazione della policy:

1. Se il messaggio non è XML e IgnoreContentType non è impostato su true, allora genera un errore.
2. Se "Template" è impostato, elabora il modello come descritto per la policy AssignMessage. Se mancano delle variabili e IgnoreUnresolvedVariables non è impostato, genera un errore.
3. Se "Template" non è impostato, crea un'asserzione che includa i valori dei parametri Subject e Issuer o i relativi riferimenti.
4. Firma l'asserzione utilizzando la chiave specificata.
5. Aggiungi l'asserzione al messaggio nell'XPath specificato.

Validate SAML Assertion

Elaborazione della policy:

1. La policy controlla il messaggio in entrata per verificare che il tipo di supporto 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 <IgnoreContentType> non è impostato, la policy genererà un errore.
2. La policy analizzerà l'XML. Se l'analisi non riesce, genererà un errore.
3. La policy estrarrà l'elemento firmato e l'asserzione utilizzando i rispettivi XPath specificati (<SignedElementXPath> e <AssertionXPath>). Se uno di questi percorsi non restituisce un elemento, la policy genererà un errore.
4. La policy verificherà che l'asserzione sia uguale all'elemento firmato o sia un elemento secondario dell'elemento firmato. In caso contrario, la policy genererà un errore.
5. Se uno degli elementi <NotBefore> o <NotOnOrAfter> è presente nell'asserzione, la policy confronterà il timestamp corrente con questi valori, come descritto nella sezione 2.5.1 di SAML Core.
6. La policy applicherà eventuali regole aggiuntive per l'elaborazione delle "Conditions" come descritto in SAML Core sezione 2.5.1.1.
7. La policy convalida la firma digitale XML utilizzando il valore dell'archivio di attendibilità (<TrustStore>) descritto sopra. Se la convalida non riesce, la policy genera un errore.

Una volta completata la policy senza generare errori, lo sviluppatore del proxy può essere certo di quanto segue:

• La firma digitale sull'asserzione è valida ed è stata firmata da una CA 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 altre policy utilizzare questi valori per un'ulteriore autenticazione, ad esempio verificare che il nome del soggetto sia valido o passarlo a un sistema di destinazione per la convalida.

Per una convalida più complessa, è possibile utilizzare altre policy, come ExtractVariables, per analizzare l'XML non elaborato dell'asserzione

Variabili di flusso

In un'asserzione SAML possono essere specificate molte informazioni. L'asserzione SAML stessa è XML che può essere analizzata utilizzando la policy ExtractVariables e altri meccanismi per 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 delle variabili: Extract Variables policy