SQLAuthenticator and Human Worklist Application

Sometimes you need another authentication mechanism to verify the username and password. In WLS the default authenticator is file based and can be accessed via a lightweight LDAP interface. For simple straight forward applications, it is sufficient.

In a SOA environment, when you use the default worklist application, the users must be registered in the Weblogic Server. Legacy applications have there own mechanism of storing user data. In our Oracle world, users and passwords are often stored in tables of the database.

The goal is to re-use this table mechanism in combination with the default Worklist Application. The approach is rather simple, but it is not working.

• Add WebLogic SQLAuthenticator provider in your security realm.

When you have applied this new authenticator, the worklist application can not authenticate the users from the database. You will get an error:

Internal Error in Verification Service for user SKING. lookupUser.
Check the underlying exception and correct the error. If the error  persists, contact Oracle Support Services.                                            

ORABPEL-30504                                                                                                                                             
Internal Error  in Verification Service.

The issue is within the worklist application itself. It only authenticates via LDAP and ignoring the SQLAuthenticator.

We are able to fix this issue. The solution is based on the SOA Samples of the Human Worklfow; "workflow-120-SQLIdentityProvider". You can obtain the examples via Oracle TechNet or via your Oracle Rep.

The solution is as follows and is based on the SQL Authenticator Example of Edwin Biemond.

• Apply the SQL Authenticator in your SOA WLS environment.
• Test if users and groups can be viewed and edited.
• Shutdown the admin server and managed servers.
• Copy the dbprovider.jar to the SOA_DOMAIN/lib directory
• make changes in the SOA FMW  JPS config file:

1. Add a new Identity Store.
2. Add a new Service Instance.
3. Change JpsContext to the new Identity store.

• Start admin and managed servers
• Test the worklist application with database users.

Note: the dbprovider.jar is created with the "workflow-120-SQLIdentityProvider" example. Check the files

• DBUserSearchResponse.java
• DBRolesSearchResponse.java

If they are query the correct tables and columns. If they are not correct, compile and create a new JAR file.

Example of the jps-confix.xml file:

<serviceProviders>
  <!-- New ID provider -->
  <serviceProvider type="IDENTITY_STORE" name="custom.provider" 
class="oracle.security.jps.internal.idstore.generic.GenericIdentityStoreProvider">
     <description>Custom IdStore Provider</description>
  </serviceProvider>
  <!-- EOF New ID provider -->
...
<serviceInstances>
  <!-- NEW Service Instance -->
  <serviceInstance name="idstore.custom" provider="custom.provider" location="dumb">
      <description>Custom Identity Store Service Instance</description>
      <property name="idstore.type"            value="CUSTOM"/>
      <property name="ADF_IM_FACTORY_CLASS"    value="org.sample.providers.db.DBIdentityStoreFactory"/>
      <property name="DB_SERVER_NAME"          value="database.vijfhuizen.local"/>
      <property name="DB_SERVER_PORT"          value="1521"/>
      <property name="DB_DATABASE_NAME"        value="orcl"/>
      <property name="ST_SECURITY_PRINCIPAL"   value="demo"/>
      <property name="ST_SECURITY_CREDENTIALS" value="demo"/>
  </serviceInstance>
  <!-- EOF NEW Service Instance -->
...
<jpsContexts default="default">
  <!-- This is the default JPS context. All the mendatory services and Login Modules must be configured in this default context -->
  <jpsContext name="default">
      <serviceInstanceRef ref="credstore"/>
      <serviceInstanceRef ref="keystore"/>
      <serviceInstanceRef ref="policystore.xml"/>
      <serviceInstanceRef ref="audit"/>
      <serviceInstanceRef ref="idstore.custom"/>
  </jpsContext>

Good luck!