junio 09, 2011

Oracle SOA Suite 11g y Active Directory

Conectar Oracle SOA Suite 11g a un directorio activo es bastante sencillo, los problemas surgen cuando se presentan los errores extraños y no documentados de Oracle al respecto. O quizá solo me salieron a mi, pero para la próxima tendré este post en el cual menciono algunos a los que me tuve que enfrentar para llevar a cabo esta configuración.



Primero tienes que configurar un Active Directory Authentication Provider, para ello entra en la consola de administración de Weblogic - Security Realms - myrealm - Providers, oprime el botón new y estarás en la pantalla de creación de un nuevo proveedor de autenticación.
Elige el nombre que quieras y por tipo elige ActiveDirectory Authenticator . Finaliza haciendo clic en el botón  OK.



Una vez creado el nuevo proveedor haz clic en él y vayamos a la pestaña de Provider Specific. En la primer sección debes configurar tu servidor: dirección, puerto, contraseñas, etc. Es importante que en el atributo Principal que corresponde al usuario que utilizará Weblogic para conectarse al Active Directory elijas un usuario con permisos de lectura sobre todo el árbol, el formato debe de ser nombre_usuario@dominio, en mi ejemplo es administrador@miserver.com



En la siguiente sección debes configurar la manera en que se accesará a tu LDAP en busca de usuarios, en el atributo Group Base DN se proporciona la base de donde comenzará a buscarse los usuarios, de manera predeterminada un Active Directory los guarda en cn=Users,dc=nombre_dominio, en mi ejemplo se encuentran en: cn=Users,dc=miserver,dc=com.
Adicionalmente y muy importante, un Active Directory guarda los nombres de usuarios en el atributo sAMAccountName por lo que es importante que los campos User From Name Filter y User Name Attribute sean modificados de la siguiente manera:


User From Name Filter = (&(sAMAccountName=%u)(objectclass=user))
User Name AttributesAMAccountName


Los demás campos de esta sección pueden permanecer con el valor predeterminado.




La siguiente sección corresponde a la configuración de como se buscarán los grupos en el LDAP.
Tienes que modificar el campo Group Base DN con el lugar donde se encuentran tus grupos.
Aquí pueden surgir varios errores una vez que se está tratando de acceder a la información del LDAP desde el menú de administración del BPM Workspace.
Esta base debe de contener todos los grupos que pueda llegar a portar un usuario que inicie sesión en el BPM Workspace, de lo contrario una vez hecho el login se mostrará toda la pantalla en blanco y en el log del servidor encontraremos errores relacionados a que no encuentra algunos de los roles dentro del realm (por no decir reino que suena raro).


Por ejemplo, el Active Directory tiene configurados grupos de manera predeterminada en las siguientes ubicaciones (recuerda que miserver.com es el nombre de mi dominio):


cn=Users,dc=miserver,dc=com
cn=Builtin,dc=miserver,dc=com


Si nosotros especificamos un DN base como: cn=Groups,dc=miserver,dc=com y nuestro usuario pertenece a  algún grupo ubicado en alguno de los DNs mencionados anteriormente entonces nos toparemos con excepciones como está cuando intentemos iniciar sesión con dicho usuario:



Caused By: ORABPEL-10592

Identity Service soap error.
BPMIdentityService encountered soap error in method invoke for with fault "No Role found matching the criteria".
Ensure that the soap message is properly formed and has all necessary attributes and elements. Contact oracle support if error is not fixable.

        at oracle.bpel.services.identity.client.IdentityServiceSOAPClient.invoke(IdentityServiceSOAPClient.java:265)
        at oracle.bpel.services.identity.client.IdentityServiceSOAPClient.getGrantedRolesToGroup(IdentityServiceSOAPClient.java:540)
        at oracle.bpel.services.identity.client.AbstractIdentityServiceClient.getGrantedRolesToGroup(AbstractIdentityServiceClient.java:729)
        at oracle.bpel.services.identity.client.Group.getGrantedRoles(Group.java:122)
        at oracle.bpel.services.identity.client.Group.getGrantedRoles(Group.java:130)
        at oracle.bpel.services.identity.client.Identity.getAppRoles(Identity.java:186)
        at oracle.bpm.papi.ora.org.ParticipantAdapter.getRoleAssignment(ParticipantAdapter.java:180)
        at oracle.bpm.papi.ora.org.ParticipantAdapter.mapRoleAssignment(ParticipantAdapter.java:147)
        at oracle.bpm.papi.ora.org.ParticipantAdapter.(ParticipantAdapter.java:49)
        at oracle.bpm.papi.ora.org.ParticipantAdapter.create(ParticipantAdapter.java:67)
        at oracle.bpm.papi.ora.mgr.OrganizationManager.lookupParticipant(OrganizationManager.java:61)
        at oracle.bpm.papi.ora.mgr.OrganizationManager.lookupParticipant(OrganizationManager.java:44)
        at oracle.bpm.papi.ora.ProcessServiceSessionAdapter.participantCurrent(ProcessServiceSessionAdapter.java:1235)
        at oracle.bpm.workspace.model.common.PapiBean.getLayouts(PapiBean.java:3338)
        at oracle.bpm.workspace.model.container.ContainerBean.buildStoredPaginatedLayout(ContainerBean.java:612)
        at oracle.bpm.workspace.model.container.ContainerBean.initPreferences(ContainerBean.java:73)
        at oracle.bpm.workspace.model.common.ComponentBeanMap.newComponentBean(ComponentBeanMap.java:144)
        at oracle.bpm.workspace.model.common.ComponentBeanMap.get(ComponentBeanMap.java:77)
        at oracle.bpm.workspace.model.common.ComponentBeanMap.get(ComponentBeanMap.java:66)
        at oracle.bpm.workspace.model.common.ComponentBeanMap.get(ComponentBeanMap.java:28)
        at javax.el.MapELResolver.getValue(MapELResolver.java:164)


Esto ocurre porque empieza a buscar todos los grupos asociados al usuario para saber de que privilegios goza, como su base es la rama definida por cn=Groups,dc=miserver,dc=com le es imposible alcanzar las demás ramas donde están los demás grupos.
Lo correcto aquí sería utilizar como DN base: dc=miserver,dc=com sin embargo aquí se le está pidiendo que busque en una rama mucho mas grande lo que puede degradar el tiempo de respuesta y ocasionar timeouts. Estos timeouts no tienen que ver con la configuración del proveedor de autenticación si no con el Workspace y aun no se como arreglarlo, es en lo que trabajo ahora.
Para los efectos de esta prueba yo construí mis grupos dentro de Users, por lo que mi configuración quedó de la siguiente manera:






Todos los demás parámetros de configuración pueden quedar con los predeterminados.


El workspace unicamente puede utilizar el primer proveedor de la lista en Weblogic, esto es debido al JPS (Java Portlet Specification) por lo que tenemos que reordenar los proveedores en la lista de la consola de administración. Ponemos primero nuestro nuevo proveedor y en segundo lugar el predeterminado.
Además configuramos ambos proveedores (ActiveDirectory y DefaultAuthenticator) con el valor SUFFICIENT en el atributo Control Flag.




Ahora solo nos falta modificar la configuración del JPS debido al cambio que hicimos en el User Name Attribute. Dicha configuración se encuentra en el archivo $DOMAIN_HOME/config/fmwconfig/jps-config.xml
Ahí buscamos este bloque y agregamos los dos parámetros:




       
         <!-- JPS WLS LDAP Identity Store Service Instance -->
        <serviceInstance name="idstore.ldap" provider="idstore.ldap.provider">
            <property name="idstore.config.provider" value="oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider"/>
            <property name="CONNECTION_POOL_CLASS" value="oracle.security.idm.providers.stdldap.JNDIPool"/>
            <property name="username.attr" value="sAMAccountName"/>
            <property name="user.login.attr" value="sAMAccountName"/>
        </serviceInstance>


Una vez modificado este archivo todo está listo, solo falta reiniciar el servidor.


Es importante hacer las siguientes observaciones:


1.- Podrás realizar login en la consola de weblogic y Enterprise Manager con cualquiera de los usuarios sin    importar de que origen sean (Active Directory o Default Authenticator) siempre y cuando sean administradores.


2.- En el BPM Workspace ya solo podrás iniciar sesión con un usuario del Active Directory, debido a que solo puede utilizar el primer proveedor de la lista no será capaz de ver a los usuarios del Default Authenticator.


3.-En Weblogic Console y enterprise Manager basta con que un usuario del Active Directory sea administrador para otorgarle permisos de administrador en las aplicaciones de Weblogic, sin embargo, para que un usuario del Active Directory sea Administrador en el BPM Workspace y pueda accesar el menú de Administración debe pertenecer explicitamente a un grupo llamado "Administrators" así tal cual, en plural y en inglés. Esto es debido a que así fue configurada dicha aplicación de fábrica (aunque es modificable en el menú de administración de BPM Workspace).
Espero esta pequeña y rápida guía les sea de utilidad y sobre todo a mi en un futuro que siempre olvido los pequeños detalles.