Almacén de Datos de Federación Persistente

En las operaciones de SSO de federación, los usuarios se identifican mediante un identificador único en el mensaje de SSO que el SP asigna a un perfil de usuario local.

A veces, el identificador único es una parte de atributo del registro de usuario de LDAP existente, como la dirección de correo electrónico o el nombre de usuario, mientras que otras veces, el identificador sólo existe para la operación SSO de federación entre el SP y IdP para un usuario específico. En el caso posterior, el identificador y el usuario al que está asociado se deben almacenar como información de enlace de cuenta en un almacén de datos de federación.

En este artículo se muestra cómo configurar OAM para utilizar RDBMS como almacén de datos de federación.

Nota importante: un almacén de datos de federación persistente solo es necesario para los casos en los que se utilizan los identificadores utilizados en las respuestas de SSO (por ejemplo, NameID persistente en SAML 2.0). Es mejor no utilizar un almacén de datos de federación persistente cuando no sea necesario.

Identificadores en Mensaje de Federación

Cada protocolo de federación utiliza un identificador para hacer referencia al usuario en el mensaje SSO, aunque existen variaciones y diferencias.

SAML 2.0

SAML 2.0 utiliza tres tipos de identificadores:

Atributos de usuario:
- Estos identificadores son atributos de usuario que normalmente conocen el SP y IdP y se almacenan en la cuenta de usuario LDAP.
- SAML 2.0 define los siguientes formatos, aunque en OAM puede utilizar cualquier formato:
- urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified (Fin de creación)
- urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress (Fin de creación)
- urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName (Fin de creación)
- urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualiCedName (Fin de creación)
- urn:oasis:names:tc:SAML:2.0:nameid-format:Kerberos (Fin de creación)
Normalmente, el uso de estos identificadores no necesita un almacén de federación persistente, ya que los valores se almacenan en la entrada de usuario LDAP.
Identificador único
- Se trata de un identificador específico definido en las especificaciones de SAML 2.0 donde IdP crea un identificador aleatorio y puntual al crear la afirmación. Esto significa que la próxima vez que el mismo usuario realice una operación de SSO de federación con el mismo SP
Se utilizará otro identificador aleatorio y de un solo uso. El nombre de ese identificador es temporal y está definido por urn:oasis:names:tc:SAML:2.0:nameid-format:transient. Puesto que se trata de un identificador de un solo uso, nunca se almacenará en un almacén de federación persistente.
Identificador persistente aleatorio
- Este identificador es una cadena aleatoria, única para el triplet IdP/SP/User
- Este identificador siempre será el mismo enviado por IdP en una afirmación de SAML 2.0 para ese SP y para ese usuario
- Se debe almacenar en un almacén de federación persistente en IdP, pero es opcional para el SP si el SP asigna la afirmación a un registro de usuario de LDAP mediante los atributos de SAML incluidos en la afirmación de SAML

Nota: con OAM como IdP, es posible utilizar el formato NameID persistente y rellenar el valor basado en expresiones, de la misma forma que se utilizan otros formatos NameID. Si el campo de valor NameID se rellena para el formato Persistente NameID en la pantalla Socio de SP, IdP utilizará esa expresión para definir el valor NameID.

Un ejemplo de afirmación emitida por IdP con una dirección de correo electrónico NameID es:

<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 ejemplo de una afirmación emitida por un IdP con un NameID persistente es:

 <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 solo utiliza atributos de usuario como NameIDs:

Estos identificadores son atributos de usuario que normalmente conocen el SP y IdP y se almacenan en la cuenta de usuario LDAP.
SAML 1.1 define los siguientes formatos, aunque en OAM puede utilizar cualquier formato:
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified (Fin de creación)
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress (Fin de creación)
urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName (Fin de creación)
urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualiCedName (Fin de creación)

No es necesario utilizar un almacén de datos de federación persistente para SAML 1.1

Un ejemplo de afirmación emitida por IdP con una dirección de correo electrónico NameID es:

<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 solo utiliza identificadores persistentes aleatorios como NameIDs:

Este identificador es una cadena aleatoria, única para el triplet IdP/SP/User
Este identificador siempre será el mismo enviado por IdP en una SSO OpenID 2.0
Respuesta para ese SP y para ese usuario
Se debe almacenar en un almacén de federación persistente en IdP, pero es opcional para el SP si el SP asigna la respuesta SSO a un registro de usuario LDAP mediante los atributos OpenID incluidos en la respuesta SSO OpenID

Un ejemplo de una respuesta SSO OpenID emitida por IdP es:

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

Almacén de Datos de Federación

Como se ha visto anteriormente, se necesita un almacén de datos de federación para los siguientes casos de uso:

IdP (Fin de creación)
SAML 2.0 al utilizar el formato NameID persistente
OpenID 2.0
SERVICIO
SAML 2.0 al utilizar el formato NameID persistente y no asignar el usuario mediante
Atributos de SAML
OpenID 2.0 y sin asignar el usuario mediante los atributos SSO de OpenID

Un almacén de datos de federación se utiliza para almacenar información de enlace de cuenta, que se compone de:

ID de usuario
Identificador opaco utilizado
ProviderID del partner remoto para el que se ha creado el identificador opaco

IdP (Fin de creación)

Como IdP, el almacén de datos de federación es necesario para enviar el mismo identificador opaco único que se ha generado aleatoriamente la primera vez que el usuario ha realizado una operación de SSO de federación entre IdP y el SP.

OAM puede enviar un identificador opaco único para el formato NameID persistente de SAML 2.0 y OpenID 2.0, que será el hash SHA-256 de:

ID de usuario canónico (OAM ID Store Name + User's DN + UserID)
ESP ProviderID

Esta función permite el uso del formato NameID persistente de SAML 2.0 y OpenID 2.0 sin tener que activar un almacén de datos de federación (consulte más adelante cómo configurar OAM)

SERVICIO

Como SP, el almacén de datos de federación es necesario si la respuesta de SSO entrante no se asigna mediante atributos de respuesta/usuario de SSO. En este caso, la información de enlace de cuenta debe estar presente en el almacén de datos de federación para que el SP pueda completar correctamente la operación. Si la información de enlace de cuenta no existe, el SP debe desafiar y autenticar localmente al usuario para determinar su identidad y crear una información de enlace de cuenta en el almacén de datos de federación (usuario + identificador opaco + IdP ProviderID).

El flujo en el SP sería:

IdP redirige al usuario al SP con respuesta SSO e identificador opaco
El SP intenta localizar la entrada de información de enlace de cuenta en el almacén de datos de federación realizando una consulta basada en el identificador opaco y en ProviderID del IdP
Si la consulta devuelve una entrada de información de enlace de cuenta, el SP extrae el ID de usuario de la entrada y crea una sesión para ese usuario.
Si la consulta no devuelve una entrada de información de enlace de cuenta
El SP inicia una operación de inicio de sesión local para autenticar al usuario.
Una vez que el usuario se autentica localmente, el SP crea una entrada de información de enlace de cuenta con
- Identificador de Usuario
- Identificador Opaco
- ProviderID de IdP

Configuración de OAM para Utilizar un Almacén de Datos de Federación

Inicialmente, OAM no está configurado para utilizar un almacén de datos de federación persistente. Por lo tanto, se devuelve un error si

Se utiliza OpenID 2.0 SSO
Se utiliza el formato NameID persistente de SAML 2.0 no basado en expresiones (es decir, el campo de valor NameID de la pantalla Socio de SP está vacío)

Nota: Como se ha mencionado anteriormente, IdP se puede configurar para rellenar OpenID 2.0 y NameID persistente de SAML 2.0 con un valor opaco basado en el hash SHA-256 de userID y ProviderID del SP, por lo que no es necesario un almacén de datos de federación. Más información al respecto en la sección siguiente.

BDMS

El único almacén de datos de federación soportado es un RDBMS, donde existe el esquema de OAM, y el RDBMS se debe definir como un origen de datos JDBC en el servidor WLS donde

OAM se está ejecutando

Utilice el origen de datos JDBC jdbc/oamds creado durante la instalación y haga referencia a la base de datos de OAM utilizada para almacenar datos de política y sesión
O
Instale una nueva base de datos y cree el esquema de OAM mediante RCU
Definir un nuevo origen de datos JDBC en WLS para los servidores gestionados de WLS en los que se está ejecutando OAM

La tabla de base de datos ORAFEDPROVIDERFED contiene las entradas de información de enlace de cuenta:

idpProvidedNameIDValue es el valor de identificador
providerID es el ProviderID del partner remoto
userID es el ID de usuario canónico (Nombre del almacén de ID de OAM + DN del usuario + UserID)
federationType es el tipo de federación
1: OAM actúa como IdP y el partner remoto es un SP
3: OAM actúa como SP y el partner remoto es IdP
idpProvidedNameIDVersionString es la versión de protocolo (SAML2.0 o OpenID2.0)
userDescription es el userID
fedID es un identificador único para esta entrada de información de enlace de cuenta

Nota: Solo se deben almacenar los valores OpenID 2.0 y NameID persistente de SAML 2.0 en el almacén de datos de federación

Configuración

Para configurar OAM para que utilice un almacén de datos de federación, realice los siguientes pasos:

Introduzca el entorno WLST ejecutando: $IAM_ORACLE_HOME/common/bin/wlst.s
Conéctese al servidor de administración de WLS: connect()
Navegue a la rama Domain Runtime: domainRuntime()
Ejecute el comando WLST setFederationStore: setFederationStore(enable, jndiname="jdbc/oamds")
Para activar el almacén de datos de federación:
1. Activar en verdadero
2. Defina el parámetro opcional jndiname que hace referencia al origen de datos JDBC que se va a utilizar. Si falta, se utiliza el origen de datos JDBC de OAM.

Un ejemplo es: setFederationStore("true")

Para desactivar el almacén de datos de federación:
1. Activar en verdadero
  
  Un ejemplo es: setFederationStore("false")
Salga del entorno WLST: exit()

Prueba con OAM como IdP

En esta prueba, OAM actúa como IdP con un partner de SP de SAML 2.0.

Para configurar IdP para generar identificadores persistentes aleatorios que se deben almacenar en el almacén de datos de federación en lugar de utilizar atributos de usuario LDAP para rellenar el valor NameID, realice los siguientes pasos:

Introduzca el entorno WLST ejecutando: $IAM_ORACLE_HOME/common/bin/wlst.sh
Conéctese al servidor de administración de WLS: connect()
Navegue a la rama Domain Runtime: domainRuntime()
Ejecute el comando WLST setSPSAMLPartnerNameID: setSPSAMLPartnerNameID(partnerName, nameIDFormat, nameIDValue="", customFormat="", nameIDValueComputed="false")
1. partnerName será el nombre del socio del SP
2. nameIDFormat se definirá en orafed-persistent
3. nameIDValue se dejará vacío. Si no está vacío, IdP utiliza la expresión para rellenar el valor NameID en lugar de generar un identificador persistente aleatorio

Un ejemplo es: setSPSAMLPartnerNameID("acmeSP", "orafed-persistent")

Salga del entorno WLST: exit()

La ejecución de la siguiente consulta SQL en una tabla ORAFEDPROVIDERFED vacía no devolvería ningún dato:

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

IDPPROVIDE PROVIDERID USERID FEDERATIONTYPE IDPPROVID USERDESC FEDID (Fin de creación)

Después de realizar SSO de federación con el SP de partner remoto, al volver a ejecutar la consulta se muestra la nueva entrada:

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

ID DE PROVEEDOR DE IDPPROVIDE	USERID	TIPO DE FEDERACIÓN	IDPROVID	ID DE USUARIO FEDERAL
ID: s-l3991	http://acme.c oud-e2e:USUARIO:	1 SAML2.0	Alicia	id-KKqR2Cl (Fin de creación)
Ut7JEyggvf (Fin de creación)	om/sp	cn=alice,ou=u	GnUAGhRLA (Fin de creación)
IoPavO7Huj (Fin de creación)		sers, dc=us, dc	MzXZMx3UGj (Fin de creación)
6H0UvFvEec (Fin de creación)	=oracle,dc=co		cMSQge9Nhh (Fin de creación)
Wwq	m:alicia	Nme

Prueba con OAM como SP

En esta prueba, OAM actúa como un SP con un partner IdP de SAML 2.0.

Para configurar OAM/SP para que utilice el almacén de datos de federación al asignar la respuesta SSO de SAML 2.0/OpenID 2.0 entrante, realice los siguientes pasos:

Introduzca el entorno WLST ejecutando: $IAM_ORACLE_HOME/common/bin/wlst.sh
Conéctese al servidor de administración de WLS: connect()
Navegue a la rama Domain Runtime: domainRuntime()
Ejecute el comando WLST setPartnerIDStoreAndBaseDN: setPartnerIDStoreAndBaseDN(partnerName, partnerType, storeName="", searchBaseDN="", delete="false")
1. partnerName será el nombre de socio IdP
2. partnerType se definirá en idp
3. storeName se definirá en FederationStore
4. searchBaseDN y delete no se definirán
  
  Un ejemplo es:

setPartnerIDStoreAndBaseDN("acmeIdP", "idp", "FederationStore")

Salga del entorno WLST: exit()

Importante: Cuando OAM/SP realiza una SSO de federación con un partner IdP mediante NameID persistente de SAML 2.0 o OpenID 2.0 con el almacén de datos de federación, si la información de enlace de cuenta para el usuario y que IdP aún no existe, OAM/SP deberá desafiar y autenticar localmente al usuario para poder crear esa entrada de información de enlace de cuenta. Las siguientes veces, el usuario ya no será desafiado, ya que la entrada de información de enlace de cuenta ya existirá.

La ejecución de la siguiente consulta SQL en una tabla ORAFEDPROVIDERFED vacía no devolvería ningún dato:

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

IDPPROVIDE PROVIDERID USERID FEDERATIONTYPE IDPPROVID USERDESC FEDID (Fin de creación)

Después de realizar SSO de federación con el partner remoto IdP y después de que el usuario se autentique localmente para poder crear la entrada de información de enlace de cuenta, al ejecutar la consulta de nuevo se muestra la nueva entrada:

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

PROPORCIONAR ID	IDENTIFICADOR DE PROVEEDOR	USERID	TIPO DE FEDERACIÓN	IDPROVID	DESCRIPCIÓN DE USUARIO
id-2eCUlO4 (Fin de creación)	http://acme.c (Fin de creación)	oud-e2e:USUARIO:	3 SAML2.0	Alicia	id-VVSIks6 (Fin de creación)
gekO2rgZfe (Fin de creación)	om/IDp	cn=alice,ou=u		hzG2szNPyI (Fin de creación)
YoZkof8YUM (Fin de creación)		sers, dc=us, dc		T5ccRf8dzy (Fin de creación)
	=oracle,dc=co		NL0DZjDbGg (Fin de creación)
	m:alicia		c-0 (Fin de creación)

Configuración de IdP para utilizar un hash como nombre

En caso de que OAM actúe como IdP con SAML 2.0 Persistent NameID y/o OpenID 2.0 según identificadores opacos y no atributos de usuario LDAP, el servidor se puede configurar para rellenar NameID según el hash SHA-256 de los siguientes datos:

ID de usuario canónico (nombre del almacén de ID de OAM + DN del usuario + UserID)
ESP ProviderID
Versión de protocolo utilizada

Para configurar IdP para que utilice el hash SHA-256 de los datos anteriores para rellenar NameID, realice los siguientes pasos:

Introduzca el entorno WLST ejecutando: $IAM_ORACLE_HOME/common/bin/wlst.sh
Conéctese al servidor de administración de WLS: connect()
Navegue a la rama Domain Runtime: domainRuntime()
Ejecute el comando WLST setSPSAMLPartnerNameID: setSPSAMLPartnerNameID(partnerName, nameIDFormat, nameIDValue="", customFormat="", nameIDValueComputed="false")
1. partnerName será el nombre del socio del SP
2. nameIDFormat se definirá en orafed-persistent
3. nameIDValue se dejará vacío. Si no está vacío, IdP utilizará la expresión para rellenar el valor NameID en lugar de generar un identificador persistente aleatorio
4. nameIDValueComputed se definirá en true
  
  Un ejemplo es: setSPSAMLPartnerNameID("acmeSP", "orafed-persistent", nameIDValueComputed="true")
Salga del entorno WLST: exit()

De esta forma, no es necesario configurar IdP para utilizar un almacén de datos de federación (no es necesario ejecutar setFederationStore("true") para activar la base de datos como almacén de datos de federación), para realizar SSO de federación con:

SAML 2.0 con persistencia opaca NameID
OpenID 2.0

Más recursos de aprendizaje

Explore otros laboratorios en docs.oracle.com/learn o acceda a más contenido de aprendizaje gratuito en el canal YouTube de Oracle Learning. Además, visite education.oracle.com/learning-explorer para convertirse en un explorador de Oracle Learning.

Para obtener documentación sobre el producto, visite Oracle Help Center.

Título e Información de Copyright

Persistent Federation Data Store

F61375-01

September 2022