Data store federazione persistente

Nelle operazioni SSO Federation gli utenti vengono identificati da un identificativo univoco nel messaggio SSO, che viene quindi mappato al profilo di un utente locale dal provider di servizi.

A volte l'identificativo univoco fa parte di un attributo del record utente LDAP esistente, ad esempio l'indirizzo e-mail o il nome utente, mentre altre volte l'identificativo esiste solo per l'operazione SSO Federation tra l'SP e IdP per un utente specifico. Nel caso successivo, l'identificativo e l'utente a cui è allegato devono essere memorizzati come informazioni di collegamento dell'account in un archivio dati federativo.

Questo articolo mostra come configurare OAM per l'utilizzo di un RDBMS come data store federazione.

Nota importante: un data store federazione persistente è necessario solo per i casi in cui vengono utilizzati gli identificativi utilizzati nelle risposte SSO (ad esempio, NameID persistente in SAML 2.0). È consigliabile non utilizzare un archivio dati federativo persistente quando non è necessario.

Identificativi in messaggio federazione

Ogni protocollo della federazione utilizza un identificativo per fare riferimento all'utente nel messaggio SSO, anche se esistono variazioni e differenze.

SAML 2.0

SAML 2.0 utilizza tre tipi di identificativi:

Nota: se OAM è IdP, è possibile utilizzare il formato NameID persistente e popolare il valore in base alle espressioni, nello stesso modo in cui vengono utilizzati altri formati NameID. Se il campo del valore NameID viene compilato per il formato persistente NameID nella schermata Partner SP, IdP utilizzerà tale espressione per impostare il valore NameID.

Un esempio di asserzione emessa da un IdP con indirizzo e-mail NameID è:

<samlp:Response ...>
    <saml:Issuer ...>https://idp.com/oam/fed</saml:Issuer>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ...>
        <saml:Issuer ...>https://idp.com/oam/fed</saml:Issuer>
        <dsig:Signature>
            ...
        </dsig:Signature>
        <saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameidformat:emailAddress">bob@oracle.com</saml:NameID>             <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <saml:SubjectConfirmationData .../>
            </saml:SubjectConfirmation>         </saml:Subject>
        <saml:Conditions ...>
            <saml:AudienceRestriction>
                <saml:Audience>https://acme.com/sp</saml:Audience>
            </saml:AudienceRestriction>
        </saml:Conditions>
        <saml:AuthnStatement AuthnInstant="2014-03-21T20:53:55Z" SessionIndex="id6i-Dm0yB-HekG6cejktwcKIFMzYE8Yrmqwfd0azz"
SessionNotOnOrAfter="2014-03-21T21:53:55Z">
            <saml:AuthnContext>
                <saml:AuthnContextClassRef>
                       urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
                </saml:AuthnContextClassRef>
            </saml:AuthnContext>
        </saml:AuthnStatement>     </saml:Assertion> </samlp:Response>

Un esempio di asserzione eseguita da un IdP con un NameID persistente è:

 <samlp:Response ...>
     <saml:Issuer ...>https://idp.com/oam/fed</saml:Issuer>
     <samlp:Status>
         <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
     </samlp:Status>
     <saml:Assertion ...>
         <saml:Issuer ...>https://idp.com/oam/fed</saml:Issuer>
         <dsig:Signature>
             ...
         </dsig:Signature>
         <saml:Subject>
 <saml:NameID NameQualifier="https://idp.com/oam/fed SPNameQualifier="https://acme.com/sp" Format="urn:oasis:names:tc:SAML:2.0:nameidformat:persistent">id-424129fa23490ded8eab00cc</saml:NameID>
             <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                 <saml:SubjectConfirmationData .../>
             </saml:SubjectConfirmation>
         </saml:Subject>
         <saml:Conditions ...>
             <saml:AudienceRestriction>
                 <saml:Audience>https://acme.com/sp</saml:Audience>
             </saml:AudienceRestriction>
         </saml:Conditions>

 <saml:AuthnStatement AuthnInstant="2014-03-21T20:53:55Z"
 SessionIndex="id-6i-Dm0yB-HekG6cejktwcKIFMzYE8Yrmqwfd0azz"
 SessionNotOnOrAfter="2014-03-21T21:53:55Z">
             <saml:AuthnContext>
                 <saml:AuthnContextClassRef>
                        urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
                 </saml:AuthnContextClassRef>
             </saml:AuthnContext>
         </saml:AuthnStatement>
     </saml:Assertion>
 </samlp:Response>

SAML 1.1

SAML 1.1 utilizza solo attributi utente come NameIDs:

Non è necessario utilizzare un data store federazione persistente per SAML 1.1

Un esempio di asserzione emessa da un IdP con indirizzo e-mail NameID è:

<samlp:Response>
    <samlp:Status>
        <samlp:StatusCode Value="samlp:Success"/>
    </samlp:Status>
    <saml:Assertion Issuer="https://idp.com/oam/fed" ...>
        <saml:Conditions ...>
            <saml:AudienceRestriction>
                <saml:Audience>https://acme.com/sp/ssov11</saml:Audience>
            </saml:AudienceRestriction>
        </saml:Conditions>
        <saml:AuthnStatement AuthenticationInstant="2014-03-21T20:53:55Z"
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">
            <saml:Subject>
<saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameidformat:emailAddress">bob@oracle.com</saml:NameIdentifier>
                <saml:SubjectConfirmation>
                   <saml:ConfirmationMethod>
                       urn:oasis:names:tc:SAML:1.0:cm:bearer
                   </saml:ConfirmationMethod>
                </saml:SubjectConfirmation>
            </saml:Subject>
        </saml:AuthnStatement>
        <dsig:Signature>
            ...
        </dsig:Signature>     </saml:Assertion>
</samlp:Response>

OpenID 2.0

OpenID 2.0 utilizza solo identificatori persistenti casuali come NameIDs:

Un esempio di risposta SSO OpenID emessa da un IdP è:

https://acme.com/openid?reCd=id-9PKVXZmRxAeDYcgLqPm36ClzOMA-&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.mode=id_res&openid.op_endpoint=https%3A%2F%2Fidp.com%2Fopenid&openid.claimed_id=https%3A%2F%2Fidp.com%2Fopenid%3Fid%3Did-38iCmmlAVEXPsFjnFVKArfn5RIiF75D5doorhEgqqPM%3D&openid.identity=https%3A%2F%2Fidp.com%2Fopenid%3Fid%3Did-38iCmmlAVEXPsFjnFVKArfn5RIiF75D5doorhEgqqPM%3D&openid.return_to=https%3A%2F%2Facme.com%2Fopenid%3FreCd%3Did9PKVXZmRxAeDYcgLqPm36ClzOMA-&openid.response_nonce=2014-03-24T19%3A20%3A06ZidYPa2kTNNFftZkgBb460jxJGblk2g--iNwPpDI7M1&openid.assoc_handle=id6a5S6zhAKaRwQNUnjTKROREdAGSjWodG1el4xyz3&openid.ns.ax=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0&openid.ax.mode=fetch_response&openid.ax.type.attr0=http%3A%2F%2Fsession%2Fcount&openid.ax.value.attr0=1&openid.ax.type.attr1=http%3A%2F%2Fopenid.net%2Fschema%2FnamePerson%2Ffriendly&openid.ax.value.attr1=My+name+is+Bobby+Smith&openid.ax.type.attr2=http%3A%2F%2Fschemas.openid.net%2Fax%2Fapi%2Fuser_id&openid.ax.value.attr2=bob&openid.ax.type.attr3=http%3A%2F%2Faxschema.org%2Fcontact%2Femail&openid.ax.value.attr3=bob%40oracle.com&openid.ax.type.attr4=http%3A%2F%2Fsession%2Fipaddress&openid.ax.value.attr4=10.145.120.253&openid.ns.pape=http%3A%2F%2Fspecs.openid.net%2Fextensions%2Fpape%2F1.0&openid.pape.auth_time=2014-03-24T19%3A20%3A05Z&openid.pape.auth_policies=http%3A%2F%2Fschemas.openid.net%2Fpape%2Fpolicies%2F2007%2F06%2Fphishing-resistant&openid.signed=op_endpoint%2Cclaimed_id%2Cidentity%2Creturn_to%2Cresponse_nonce%2Cassoc_handle%2Cns.ax%2Cax.mode%2Cax.type.attr0%2Cax.value.attr0%2Cax.type.attr1%2Cax.value.attr1%2Cax.type.attr2%2Cax.value.attr2%openid.sig=mYMgbGYSs22l8e%2FDom9NRPw15u8%3D

Data store federazione

Come già visto in precedenza, per i seguenti casi d'uso è necessario un data store della federazione:

Un data store federazione viene utilizzato per memorizzare le informazioni di collegamento dell'account che sono costituite da:

IdP

Come IdP, il data store federazione è necessario per inviare lo stesso identificativo opaco univoco generato in modo casuale la prima volta che l'utente ha eseguito un'operazione SSO Federation tra IdP e SP.

OAM è in grado di inviare un identificativo opaco univoco per il formato NameID persistente SAML 2.0 e OpenID 2.0 che sarà l'hash SHA-256 di:

Questa funzione consente l'uso del formato NameID persistente SAML 2.0 e OpenID 2.0 senza dover abilitare un data store federativo (vedere più avanti come configurare OAM).

SPESA

In qualità di provider di servizi, il data store federazione è obbligatorio se la risposta SSO in entrata non è mappata tramite gli attributi Risposta SSO/utente. In questo caso, le informazioni sul collegamento dell'account devono essere presenti nel data store federazione per consentire al provider di servizi di completare l'operazione. Se le informazioni di collegamento dell'account non esistono, il provider di servizi deve sottoporre a verifica e autenticare localmente l'utente per determinarne l'identità e creare le informazioni di collegamento dell'account nel data store federativo (utente + identificativo opaco + IdP ProviderID).

Il flusso all'SP sarebbe quindi:

Configurazione di OAM per l'utilizzo di un data store federazione

OAM non è configurato per utilizzare un data store federazione persistente. Viene quindi generato un errore se

Nota: come indicato in precedenza, è possibile configurare IdP per popolare OpenID 2.0 e SAML 2.0 Persistent NameID con un valore opaco basato sull'hash SHA-256 di userID e SP ProviderID, pertanto non richiede un data store Federation. Ulteriori informazioni in questa sezione.

RDBM

L'unico data store federazione supportato è un RDBMS in cui esiste lo schema OAM e l'RDBMS deve essere definito come origine dati JDBC nel server WLS in cui

OAM è in esecuzione

La tabella di database ORAFEDPROVIDERFED contiene le voci di informazioni sul collegamento dell'account:

Nota: nel data store federativo devono essere memorizzati solo i valori OpenID 2.0 e SAML 2.0 persistenti NameID

Configurazione

Per configurare OAM per l'utilizzo di un data store federazione, effettuare le operazioni riportate di seguito.

  1. Immettere l'ambiente WLST eseguendo: $IAM_ORACLE_HOME/common/bin/wlst.s

  2. Connetti al server di amministrazione WLS: connect()

  3. Passare alla diramazione Runtime dominio: domainRuntime()

  4. Eseguire il comando WLST setFederationStore: setFederationStore(enable, jndiname="jdbc/oamds")

  5. Per abilitare il data store federazione, effettuare le operazioni riportate di seguito.

    1. Impostare Abilita su true

    2. Impostare il parametro facoltativo jndiname che fa riferimento all'origine dati JDBC da utilizzare. Se mancante, viene utilizzata l'origine dati JDBC OAM.

    6. Esempio: setFederationStore("true")

  6. Per disabilitare il data store federazione:

    1. Impostare Abilita su true

      Esempio: setFederationStore("false")

  7. Uscire dall'ambiente WLST: exit()

Test con OAM come IdP

In questo test, OAM funge da IdP con un partner SP SAML 2.0.

Per configurare IdP in modo da generare identificativi persistenti casuali che devono essere memorizzati nel data store federazione anziché utilizzare gli attributi utente LDAP per popolare il valore NameID, effettuare le operazioni riportate di seguito.

  1. Immettere l'ambiente WLST eseguendo: $IAM_ORACLE_HOME/common/bin/wlst.sh

  2. Connetti al server di amministrazione WLS: connect()

  3. Passare alla diramazione Runtime dominio: domainRuntime()

  4. Eseguire il comando WLST setSPSAMLPartnerNameID: setSPSAMLPartnerNameID(partnerName, nameIDFormat, nameIDValue="", customFormat="", nameIDValueComputed="false")

    1. partnerName sarà il nome del partner SP

    2. nameIDFormat verrà impostato su orafed-persistent

    3. nameIDValue verrà lasciato vuoto. Se il campo non è vuoto, IdP utilizza l'espressione per popolare il valore NameID anziché generare un identificativo persistente casuale

    5. Esempio: setSPSAMLPartnerNameID("acmeSP", "orafed-persistent")

  5. Uscire dall'ambiente WLST: exit()

L'esecuzione della query SQL seguente in una tabella ORAFEDPROVIDERFED vuota non restituisce alcun dato:

SQL> select idpProvidedNameIDValue, providerID, userID, federationType, idpProvidedNameIDVersionString, userDescription, fedID from ORAFEDPROVIDERFED

IDPPROVIDE PROVIDERID USERID FEDERATIONTYPE IDPPROVID USERDESC FEDID

Dopo aver eseguito SSO Federation con l'SP del partner remoto, l'esecuzione della query mostra nuovamente la nuova voce:

SQL> select idpProvidedNameIDValue, providerID, userID, federationType, idpProvidedNameIDVersionString, userDescription, fedID from ORAFEDPROVIDERFED
ID PROVIDER APPROVAZIONE USERID TIPO DI FEDERAZIONE IDPPROVID FEDID USERDESC
ID: s-l3991 http://acme.c oud-e2e:USER: 1 SAML2.0 alice id-KKqR2Cl
Ut7JEyggvf om/sp cn=alice,ou=u GnUAGhRLA  
IoPavO7Huj   sers,dc=us,dc MzXZMx3UGj  
6H0UvFvEec =oracle,dc=co   cMSQge9Nhh  
Wwq (disambigua) m:alice NME    

Test con OAM come SP

In questo test, OAM funge da SP con un partner SAML 2.0 IdP.

Per configurare OAM/SP in modo che utilizzi il data store federazione durante il mapping della risposta SSO SAML 2.0/OpenID 2.0 in entrata, effettuare le operazioni riportate di seguito.

  1. Immettere l'ambiente WLST eseguendo: $IAM_ORACLE_HOME/common/bin/wlst.sh

  2. Connetti al server di amministrazione WLS: connect()

  3. Passare alla diramazione Runtime dominio: domainRuntime()

  4. Eseguire il comando WLST setPartnerIDStoreAndBaseDN: setPartnerIDStoreAndBaseDN(partnerName, partnerType, storeName="", searchBaseDN="", delete="false")

    1. partnerName sarà il nome partner IdP

    2. partnerType verrà impostato su idp

    3. storeName verrà impostato su FederationStore

    4. searchBaseDN e l'eliminazione non verranno impostati

      Ad esempio:

    5. setPartnerIDStoreAndBaseDN("acmeIdP", "idp", "FederationStore")
  5. Uscire dall'ambiente WLST: exit()

Importante: quando OAM/SP esegue un SSO Federation con un partner IdP utilizzando il file NameID persistente SAML 2.0 o il file OpenID 2.0 con Federation Data Store, se le informazioni di collegamento dell'account per l'utente e il file IdP non esistono ancora, OAM/SP dovrà eseguire una richiesta di verifica e autenticare in locale l'utente per poter creare tale voce di informazioni di collegamento dell'account. Gli orari successivi non verranno più richiesti all'utente in quanto l'immissione delle informazioni di collegamento all'account esisterà già.

L'esecuzione della query SQL seguente in una tabella ORAFEDPROVIDERFED vuota non restituirà alcun dato:

SQL> select idpProvidedNameIDValue, providerID, userID, federationType, idpProvidedNameIDVersionString, userDescription, fedID from ORAFEDPROVIDERFED

IDPPROVIDE PROVIDERID USERID FEDERATIONTYPE IDPPROVID USERDESC FEDID

Dopo aver eseguito SSO Federation con il partner remoto IdP e dopo che l'utente ha eseguito l'autenticazione locale per poter creare l'immissione delle informazioni di collegamento all'account, l'esecuzione della query mostra di nuovo la nuova voce:

SQL> select idpProvidedNameIDValue, providerID, userID, federationType, idpProvidedNameIDVersionString, userDescription, fedID from ORAFEDPROVIDERFED
APPROVA ID FORNITORE USERID TIPO DI FEDERAZIONE IDPPROVID DESCRIZIONE UTENTE FEDID (DISAMBIGUA)
id-2eCUlO4 http://acme.c oud-e2e:Utente: 3 SAML2.0 alice id-VVSIks6  
gekO2rgZfe om/idp cn=alice,ou=u   hzG2szNPyI    
YoZkof8YUM   sers,dc=us,dc   T5ccRf8dzy    
  =oracle,dc=co   NL0DZjDbGg      
  m:alice   c-0      

Configurazione di IdP per l'uso di un hash come nome

Se OAM funge da IdP utilizzando SAML 2.0 Persistent NameID e/o OpenID 2.0 in base a identificativi opachi e non agli attributi utente LDAP, il server può essere configurato per popolare NameID in base all'hash SHA-256 dei dati seguenti:

Per configurare IdP in modo che utilizzi l'hash SHA-256 dei dati precedenti per popolare NameID, effettuare le operazioni riportate di seguito.

  1. Immettere l'ambiente WLST eseguendo: $IAM_ORACLE_HOME/common/bin/wlst.sh

  2. Connetti al server di amministrazione WLS: connect()

  3. Passare alla diramazione Runtime dominio: domainRuntime()

  4. Eseguire il comando WLST setSPSAMLPartnerNameID: setSPSAMLPartnerNameID(partnerName, nameIDFormat, nameIDValue="", customFormat="", nameIDValueComputed="false")

    1. partnerName sarà il nome del partner SP

    2. nameIDFormat verrà impostato su orafed-persistent

    3. nameIDValue verrà lasciato vuoto. Se il campo non è vuoto, IdP utilizzerà l'espressione per popolare il valore NameID anziché generare un identificativo persistente casuale

    4. nameIDValueComputed verrà impostato su true

      Esempio: setSPSAMLPartnerNameID("acmeSP", "orafed-persistent", nameIDValueComputed="true")

  5. Uscire dall'ambiente WLST: exit()

In questo modo, non è necessario configurare IdP per utilizzare un data store federazione (non è necessario eseguire setFederationStore("true") per abilitare DB come data store federazione) per eseguire SSO federazione con:

Altre risorse di apprendimento

Esplora altri laboratori su docs.oracle.com/learn o visita altri contenuti di formazione gratuiti sul canale Oracle Learning YouTube. Inoltre, visitare education.oracle.com/learning-explorer per diventare un Oracle Learning Explorer.

Per la documentazione sul prodotto, visitare Oracle Help Center.