Introduction
In Part 1, we looked at the initialization of libOVD at server startup. Now let’s examine what happens inside libOVD when you actually click on the login button in BPM Workspace. Again, we are looking at BPM 11g PS5 BP7 with Patch 17315336.
The Workspace login is a two step process. The first step is checking the username and password against the LDAP. This step is performed in WLS security layer rather than the JPS layer. This means even if you turn on tracing in libOVD, you won’t see any trace log message related to this step.
The second step starts after the user credentials are successfully verified. In this step, the Workspace first constructs a Workflow context object, which triggers a user lookup query against the LDAP, and then it makes a request to the BPM server which invokes the follow method:
oracle.bpel.services.workflow.common.provider.WorkflowWSProvider.processMessage
This call triggers second user lookup into the LDAP. The LDAP queries performed in this step are executed through the JPS and the libOVD layer (not the WLS security layer). This post will focus on this step.
1. Building the WorkflowContext Object
This process includes three sub-steps: lookup user, find reportees and populate user details.
1.1. Lookup User
– LDAP query received by libOVD:
Base:
Scope: 2
Filter: (&(loginid=user1)(objectclass=person))
Attributes: [mail, sn, cn, description, usernameattr, orclguid, givenname, loginid, objectclass, displayname, usernameattr]
– Adapters selected:
Adapter#SchemaAdapter (does nothing, can be igored)
Adapter#DefaultAuthenticator
Adapter#ODSEE
Adapter#RootAdapter (does nothing, can be ignored)
– Query Adapter#DefaultAuthenticator
— Connect to the WLS embeded LDAP server at localhost:7001
— Build a connection pool if specified
— Map query to (&(uid=user1)(objectclass=person))
— Change the LDAP search base to: ou=people,ou=myrealm,dc=bpmdomain
— Perform the query (but yields no result in this case).
– Query Adapter#ODSEE
— Connect to the WLS embeded LDAP server at localhost:7001
— Build a connection pool if specified
— Map query to (&(uid=user1)(objectclass=person))
— Change the LDAP search base to: ou=people,dc=migration,dc=test
— Perform the query which yields 1 result.
– Post search processing, which does nothing in this case.
1.2. Get Reportees
– LDAP query received by libOVD:
BindDN:
Base: ou=people,ou=myrealm,dc=bpmdomain
Scope: 2
Attributes: [displayname, orclguid, manager, description, givenname, loginid, usernameattr, sn, cn, mail, objectclass, uid]
Filter: manager=cn=user1,ou=people,dc=migration,dc=test
– The rest of the process is the same as in 1. Lookup User
— Map query to: (manager=cn=user1,ou=people,dc=migration,dc=test)
— No result returned in my test case.
1.3. Populate User Details
– LDAP query received by libOVD:
Base: cn=user1,ou=people,dc=migration,dc=test
Scope: 0
Filter: objectclass=*
Attributes: []
– Adapter selected:
Adapter#ODSEE
– Query Adapter#ODSEE
— Map query to (objectclass=*)
— Perform the query which yields no result in my test.
2. oracle.bpel.services.workflow.common.provider.WorkflowWSProvider.processMessage
As one can see below, the LDAP queries performed in this step are exactly the same as in step 1, building the WorkflowContext. It is not clear from the trace log
that why the same queries have to be repeated.
2.1 Lookup User
– Same as 1.1 above
2.2 Populate User Details
– Same as 1.3
Note: there is no query to get reportees in this process.
Other Issue
During the testing, it was found that the property
<property name=”use.group.membership.search.config” value=”INDIRECT_ONLY”/>
has to be removed from jps-config.xml. If not, the Administration link in the Workspace will be missing even for an administration user.
In the next post of this series, we will look into the similar login process in 11g PS6 and 12c. Some different behaviors were observed with some customers.
All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission