Best Practices from Oracle Development's A‑Team

Configuration of Users/External Roles Relationship in OES 11G for a Database Identity Store


Recently I worked with a customer who wanted to use their existing database that is tied to other applications as the identity store for OES11G implementation. We all know that for OES 11G, the Identity Store must be an LDAP based directory. So to address this use case we took the help of  OVD.  The prerequsite is that the database must have the users and groups and also must have an existing relationship between them. This post will show you how to surface the existing user/role relationship in a database as an LDAP representation of the user/group relationship in OVD so that OES 11G can leverage that as an Identity Store.


Basic Data Model

While the actual data relationship for that customer was complex, for this post we will assume a very simple data model. The user/group relationship is as follows where a user can belong to multiple groups.


The following Figure shows some sample data:


Configuration of the Identity Store


We will use OVD as the Identity store. But before we configure the OVD, we need set the OVD as the Identity Store.  Please follow the link below to configure the OVD as the Identity Store: http://docs.oracle.com/cd/E27559_01/admin.1112/e27153/get_start.htm#BABGJCCC

Configure an OVD as an Authentication Provider and then configure the Users and the Groups for the provider as required by your setup. In our example, the domain Base DN is  “dc=oracleateam,dc=com”, the user container is ou=people,dc=oracleateam,dc=com and the group container is ou=groups,dc=oracleateam,dc=com. It can be noted that in our example we put the Group Base DN in the Authentication Provider as “dc=oracleateam,dc=com”. The reason being in OES we will use the Groups (External Roles) as the Principals in our Authorization Policy and it needs to search the user which is in the other container.

Following is the sample setup for our example:


User Base DN: ou=people,dc=oracleateam,dc=com

All Users Filter: (&(cn=*)(objectclass=person))

User From Name Filter: (&(cn=%u)(objectclass=person))

User Name Attribute:cn

User Object Class: person



Group Base DN : dc=oracleateam,dc=com

All Groups Filter : (&(cn=*)(|(objectclass=groupofUniqueNames)(objectclass=groupofurls)))

Group Name from Filter : (|(&(cn=%g)(objectclass=groupofUniqueNames))(&(cn=%g)(objectclass=groupofurls)))


Static Groups:

Static Group Name Attribute: cn
Static Group Object Class: groupofuniquenames
Static Member DN Attribute: uniquemember
Static Group DNs from Member DN Filter: (&(uniquemember=%M)(objectclass=groupofuniquenames))

The following figure shows a sample configuration of the Users/Groups in the OVD Authenticator:



OVD Database Adapter


Now, we need to the setup the OVD and use the database adapter so that the database views can be represented in an LDAP hierarchy.

The following figure shows how to configure the adapter for the users (in this example it is db_user)


The following figure shows how to configure the adapter for the groups (in this example it is db). It can be noted that we used a multi-valued attribute named “member” to represent the user.


As we need to represent a relationship between the groups and the users, we need to use the ‘uniquemember’ attribute in a DN format such that a group (represents an objectclass groupofuniquenames) can have multiple users as its member. To do that, we need to configure a “Virtual Attribute” plugin. The following figure shows the configuration.


To make sure, the users and groups are configured correctly, we ran a ldapsearch for the group "cn=HR" who should have the user TUSER as its member. The following figure confirms that:


Validation of User/Group Relationship in OES


Now, we should validate the data relationship through the OES APM.  We will write a policy and will validate the access through the simulation.

The following figure shows the groups as External Roles and the Users:



The following Figure shows the External Role Assignment of the user. In the LDAP terminology the user cn=tuser,ou=People,dc=oracleateam,dc=com is a uniquemember of the groups as shown.


The following figure shows a sample Authorization Policies where the External Role (group) ‘HUMAN RESOURCE’ (cn=HR,ou=groups,dc=oracleateam,dc=com) has been added as a Principal.


The following Figures show a Simulation Result of the “Check Access” for the Policy for the user 'NUSER' (cn=nuser,ou=people,dc=oracleateam,dc=com) and the user 'TUSER' (cn=tuser,ou=peole,dc=oracleateam,dc=com).

The user NUSER does not belong to the role HUMAN RESOURCE where as the user TUSER has that role.




It can be verified that the Access is denied for the user 'NUSER' as it does not have the role of HUMAN RESOURCE, where as for the user 'TUSER' the Access has been granted as it has the role of HUMAN RESOURCE.


If we model the data and configure the OVD Database adapter properly, it is possible to surface the relationship of users and groups in the database to an LDAP form through OVD. And then by configuring the Authenticator in the Weblogic provider properly, OES can leverage OVD as an external identity store and then can use the users/external role relationship to write Authorization Policies. The main effort for the configuration though lies in configuring the OVD adapters and the Authentication Provider.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha