Configuración de la correlación de identidad de entrada
Para la correlación de identidad de entrada, escriba un módulo de inicio de sesión y configure WebSphere Application Server para ejecutar el módulo de inicio de sesión primero en las configuraciones de inicio de sesión del sistema. Tenga en cuenta los siguientes pasos cuando escriba el módulo de inicio de sesión personalizado.
Procedimiento
- Obtenga la identidad de usuario de entrada de los retornos de
llamada y correlacione la identidad, si es necesario. Este
paso ocurre en el método login del módulo de inicio de sesión. Una
autenticación válida tiene cualquiera de los siguientes retornos
de llamada presentes o ambos: NameCallback y WSCredTokenCallback. El siguiente
ejemplo de código muestra cómo determinar la identidad del usuario:
javax.security.auth.callback.Callback callbacks[] = new javax.security.auth.callback.Callback[3]; callbacks[0] = new javax.security.auth.callback.NameCallback(""); callbacks[1] = new javax.security.auth.callback.PasswordCallback ("Password: ", false); callbacks[2] = new com.ibm.websphere.security.auth.callback. WSCredTokenCallbackImpl(""); callbacks[3] = new com.ibm.wsspi.security.auth.callback. WSTokenHolderCallback(""); try { callbackHandler.handle(callbacks); } catch (Exception e) { // Maneja las excepciones throw new WSLoginFailedException (e.getMessage(), e); } // Muestra qué retornos de llamada contienen información boolean identitySwitched = false; String uid = ((NameCallback) callbacks[0]).getName(); char password[] = ((PasswordCallback) callbacks[1]).getPassword(); byte[] credToken = ((WSCredTokenCallbackImpl) callbacks[2]).getCredToken(); java.util.List authzTokenList = ((WSTokenHolderCallback) callbacks[3]).getTokenHolderList(); if (credToken != null) { try { String uniqueID = WSSecurityPropagationHelper.validateLTPAToken(credToken); String realm = WSSecurityPropagationHelper.getRealmFromUniqueID (uniqueID); // Establecer ahora la serie a UID para poder utilizar el resultado para // la correlación o el inicio de sesión. uid = WSSecurityPropagationHelper.getUserFromUniqueID (uniqueID); } catch (Exception e) { // Maneja la excepción } } else if (uid == null) { // Genera una excepción, si los datos de autenticación no son válidos. // Debe tener UID o CredToken throw new WSLoginFailedException("invalid authentication data."); } else if (uid != null && password != null) { // Es una autenticación típica. Puede elegir la correlación de este ID // con otro ID o puede evitarla y permitir que WebSphere Application Server // inicie la sesión automáticamente. Cuando las contraseñas estén presentes, tenga sumo // cuidado en no validar la contraseña porque ésta es la autenticación inicial. return true; } // Si lo desea, correlacione este uid con algo distinto y establezca el booleano // identitySwitched. Si se ha modificado la identidad, borre los atributos // propagados más abajo para que no se utilicen incorrectamente. uid = myCustomMappingRoutine (uid); // Borrar los atributos propagados porque ya no se aplican // a la nueva identidad if (identitySwitched) { ((WSTokenHolderCallback) callbacks[3]).setTokenHolderList(null); }
- Compruebe si la propagación de atributo se ha efectuado y si
los atributos para el usuario ya están presentes cuando la identidad permanece idéntica. Compruebe si los atributos de usuario del servidor emisor ya están
presente para evitar llamadas duplicadas a la búsqueda del registro de
usuario. Para comprobar los atributos de usuario, utilice un método en el retorno de llamada
WSTokenHolderCallback que analice la información presente en el retorno de llamada para determinar si ésta es
suficiente para que WebSphere Application Server cree un Subject.
El siguiente ejemplo de código
comprueba los atributos de usuario:
Si no hay suficientes atributos presentes para formatear los objetos WSCredential y WSPrincipal necesarios para realizar la autorización, el ejemplo de código anterior devuelve un valor true como resultado. Cuando el resultado es false, puede escoger la interrupción del proceso, ya que existe la información necesaria para crear el Subject sin necesidad de realizar llamadas al registro de usuario remoto adicionales.boolean requiresLogin = ((com.ibm.wsspi.security.auth.callback.WSTokenHolderCallback) callbacks[2]).getrequiresLogin();
- Opcional: Consulte los atributos necesarios en el registro de usuarios, coloque los
atributos en una hashtable y añada la hashtable al
estado compartido. Si se conmuta la identidad en este módulo de inicio de sesión, debe
realizar los pasos siguientes:
- Cree la hashtable de atributos, tal como se muestra en la tabla siguiente.
- Añada la hashtable al estado compartido.
if (requiresLogin || identitySwitched) { // Recupera InitialContext por omisión para este servidor. javax.naming.InitialContext ctx = new javax.naming.InitialContext(); // Recupera la implementación de UserRegistry local. com.ibm.websphere.security.UserRegistry reg = (com.ibm.websphere. security.UserRegistry) ctx.lookup("UserRegistry"); // Recupera el uniqueID de registro de usuario en el uid especificado // en NameCallback. String uniqueid = reg.getUniqueUserId(uid); uid = WSSecurityPropagationHelper.getUserFromUniqueID (uniqueid); // Recupera el nombre de visualización del registro de usuario basado en el uniqueID. String securityName = reg.getUserSecurityName(uid); // Recupera los grupos asociados con el uniqueID. java.util.List groupList = reg.getUniqueGroupIds(uid); // Crea java.util.Hashtable con la información que ha recopilado // de la implementación de UserRegistry. java.util.Hashtable hashtable = new java.util.Hashtable(); hashtable.put(com.ibm.wsspi.security.token.AttributeNameConstants. WSCREDENTIAL_UNIQUEID, uniqueid); hashtable.put(com.ibm.wsspi.security.token.AttributeNameConstants. WSCREDENTIAL_SECURITYNAME, securityName); hashtable.put(com.ibm.wsspi.security.token.AttributeNameConstants. WSCREDENTIAL_GROUPS, groupList); // Añade una clave de memoria caché que se utiliza como parte del mecanismo de búsqueda // para el asunto creado. La clave de memoria caché puede ser un objeto, pero debería // tener un método toString implementado. Asegúrese de que cacheKey contenga // información suficiente para abarque el ámbito del usuario y de cualquier atributo // adicional que esté utilizando. Si no especifica esta propiedad el Subject // tiene el ámbito en el WSCREDENTIAL_UNIQUEID que se devuelve, por omisión. hashtable.put(com.ibm.wsspi.security.token.AttributeNameConstants. WSCREDENTIAL_CACHE_KEY, "myCustomAttribute" + uniqueid); // Añade la tabla de totales de control a sharedState del sujeto. _sharedState.put(com.ibm.wsspi.security.token.AttributeNameConstants. WSCREDENTIAL_PROPERTIES_KEY,hashtable); }
Las reglas siguientes definen con más detalle cómo se realiza un inicio de sesión de hashtable. Debe utilizar un objeto java.util.Hashtable en el Subject (conjunto de credenciales públicas o privadas) o HashMap del estado compartido. La clase com.ibm.wsspi.security.token.AttributeNameConstants define las claves que contienen la información de usuario. Si el objeto hashtable se coloca en el estado compartido del contexto de inicio de sesión mediante un módulo de inicio de sesión personalizado que aparece listado antes que el módulo de inicio de sesión de LTPA (Lightweight Third Party Authentication), se busca el valor del objeto java.util.Hashtable mediante la siguiente clave dentro del hashMap de estado compartido:- Propiedad
- com.ibm.wsspi.security.cred.propertiesObject
- Referencia a la propiedad
- AttributeNameConstants.WSCREDENTIAL_PROPERTIES_KEY
- Explicación
- Esta clave busca el objeto de tabla hash que contenga las propiedades necesarias en el estado compartido del contexto de inicio de sesión:
- Resultado esperado
- Un objeto java.util.Hashtable.
Si un objeto java.util.Hashtable se encuentra en el Subject o en el área de estado compartido, verifique que las siguientes propiedades estén presentes en la tabla hash:
- Propiedad
- com.ibm.wsspi.security.cred.uniqueId
- Referencia a la propiedad
- AttributeNameConstants.WSCREDENTIAL_UNIQUEID
- Devoluciones
- java.util.String
- Explicación
- El valor de la propiedad debe ser una representación exclusiva del usuario. Para
la implementación predeterminada de
WebSphere Application Server, esta propiedad representa la información que está almacenada en la tabla de autorizaciones de aplicaciones. La información está ubicada en el descriptor
de despliegue de aplicaciones después de que se despliegue y se realice la
correlación de usuarios con roles. Consulte los ejemplos de formato
esperados, si la correlación de usuarios con roles se realiza mediante una
búsqueda en una implementación de registro de usuario de WebSphere Application Server.
Si un proveedor de autorizaciones de terceros sobrescribe la correlación de usuarios con roles, el proveedor de autorizaciones de terceros define el formato. Para garantizar la compatibilidad con la implementación de WebSphere Application Server predeterminada del valor de ID exclusivo, llame al método de UserRegistry public String getUniqueUserId(String userSecurityName) de WebSphere Application Server.
- Formatos de ejemplo esperados
Tabla 1. Formatos de ejemplo. En esta tabla se proporcionan algunos ejemplos de formato al configurar la correlación de identidad de entrada.
Reino Formato (uniqueUserId) Protocolo LDAP (Lightweight Directory Access Protocol) ldaphost.austin.ibm.com:389/cn=user,o=ibm,c=us Windows MYWINHOST/S-1-5-21-963918322-163748893-4247568029-500 UNIX MYUNIXHOST/32
La propiedad com.ibm.wsspi.security.cred.uniqueId es necesaria.
- Propiedad
- com.ibm.wsspi.security.cred.securityName
- Referencia a la propiedad
- AttributeNameConstants. WSCREDENTIAL_ SECURITYNAME
- Devoluciones
- java.util.String
- Explicación
- Esta propiedad busca el securityName del usuario de autenticación. Este nombre generalmente recibe el nombre de nombre de visualización o nombre abreviado. WebSphere Application Server utiliza el atributo securityName para las API (interfaces de programación de aplicaciones) getRemoteUser, getUserPrincipal y getCallerPrincipal. Para garantizar la compatibilidad con la implementación de WebSphere Application Server predeterminada del valor securityName, llame al método de UserRegistry public String getUserSecurityName(String uniqueUserId) de WebSphere Application Server.
- Formatos de ejemplo esperados
Tabla 2. Formatos de ejemplo. En esta tabla se proporcionan ejemplos de formato esperados. Reino Formato (uniqueUserId) LDAP usuario (UID LDAP) Windows user (Windows username) UNIX user (UNIX username)
La propiedad com.ibm.wsspi.security.cred.securityName es necesaria.
- Propiedad
- com.ibm.wsspi.security.cred.groups
- Referencia a la propiedad
- AttributeNameConstants. WSCREDENTIAL_GROUPS
- Devoluciones
- java.util.ArrayList
- Explicación
- Esta clave busca la lista de matrices de los grupos a los que pertenece el usuario. Los grupos están especificados en el formato nombre_reino/nombre_usuario. El formato de estos grupos es importante, ya que el motor de autorización de WebSphere Application Server utiliza los grupos para las correlaciones de grupos con roles en el descriptor de despliegue. El formato proporcionado debe coincidir con el formato esperado por la implementación predeterminada de WebSphere Application Server. Cuando utilice un proveedor de autorizaciones de terceros, debe utilizar el formato esperado por el proveedor de terceros. Para garantizar la compatibilidad con la implementación de WebSphere Application Server predeterminada del valor de los ID de grupo exclusivos, llame al método de UserRegistry public List getUniqueGroupIds(String uniqueUserId) de WebSphere Application Server.
- Formatos de ejemplo esperados para cada grupo de la lista de matrices
Tabla 3. Formatos de ejemplo. En esta tabla se proporcionan ejemplos de formato esperados para cada grupo de la lista de matrices. Reino Formato LDAP ldap1.austin.ibm.com:389/cn=group1,o=ibm,c=us Windows MYWINREALM/S-1-5-32-544 UNIX MY/S-1-5-32-544
La propiedad com.ibm.wsspi.security.cred.groups no es necesaria. No se requiere ningún usuario para tener grupos asociados.
- Propiedad
- com.ibm.wsspi.security.cred.cacheKey
- Referencia a la propiedad
- AttributeNameConstants. WSCREDENTIAL_CACHE_KEY
- Devoluciones
- java.lang.Object
- Explicación
- Esta propiedad de claves puede especificar un objeto que represente las propiedades exclusivas del inicio de sesión, incluidos la información específica de usuario y los atributos dinámicos de usuario que puedan afectar a la exclusividad. Por ejemplo, cuando el usuario se conecte desde la ubicación A, que podría afectar al control de acceso, es necesario que la clave de memoria caché incluya la ubicación A para que el Subject recibido sea el Subject correcto para la ubicación actual.
Esta propiedad com.ibm.wsspi.security.cred.cacheKey no es necesaria. Cuando no se especifica esta propiedad, la búsqueda de memoria caché es el valor especificado para WSCREDENTIAL_UNIQUEID. Cuando esta información se encuentra en el objeto java.util.Hashtable, WebSphere Application Server crea un sujeto similar al sujeto que sigue el proceso normal de inicio de sesión al menos para LTPA. El nuevo Subject contiene un objeto WSCredential, y un objeto WSPrincipal que contiene la información encontrada en el objeto hashtable.
- Añada el módulo de inicio de sesión personalizado a las
configuraciones de inicio de sesión del sistema RMI_INBOUND, WEB_INBOUND
y DEFAULT de JAAS
(Java™
Authentication and Authorization Service). Configure la configuración de inicio de sesión RMI_INBOUND para que WebSphere Application Server
primero cargue el nuevo módulo de inicio de sesión personalizado.
- Pulse Seguridad > Seguridad global > Java Authentication and Authorization Service > Inicios de sesión del sistema > RMI_INBOUND
- En Propiedades adicionales, pulse Módulos de inicio de sesión JAAS > Nuevo para añadir el módulo de inicio de sesión a la configuración de RMI_INBOUND.
- Vuelva al panel de módulos de inicio de sesión JAAS para RMI_INBOUND.
- Pulse Establecer orden para cambiar el orden en que se cargan los módulos de inicio de sesión para que WebSphere Application Server cargue primero el módulo de inicio de sesión personalizado. Utilice los botones Arriba o Abajo para organizar el orden de los módulos de inicio de sesión.
- Repita los tres pasos anteriores para las configuraciones de inicio de sesión WEB_INBOUND y DEFAULT.
Resultados
Subtopics
Ejemplo: Módulo de conexión personalizado para la correlación de entrada
Este ejemplo muestra un módulo de conexión personalizado que crea una tabla de totales de control java.util.Hashtable basada en el retorno de llamada NameCallback especificado. La tabla de totales de control java.util.Hashtable se añade a la correlación java.util.Map de sharedState para que los módulos de inicio de sesión de WebSphere Application Server puedan ubicar la información en la tabla de totales de control.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsec_configinbidentmap
File name: tsec_configinbidentmap.html