OPSS 12.2.1.4: TaskQueryService - Identity Service Authentication Failure (Doc ID 2816161.1)

Last updated on DECEMBER 22, 2023

Applies to:

Symptoms

On : 12.2.1.4.0 version, OPSS

When attempting to invoke TaskQueryService, the following error occurs.

In config.xml, for the login module

<sec:authentication-provider xsi:type="wls:default-authenticatorType">
<sec:name>DefaultAuthenticator</sec:name>
<sec:control-flag>SUFFICIENT</sec:control-flag>

<wls:use-retrieved-user-name-as-principal>true</wls:use-retrieved-user-name-as
-principal>
</sec:authentication-provider>
<sec:authentication-provider
xsi:type="wls:active-directory-authenticatorType">
<sec:name>ADAuthenticator</sec:name>
<sec:control-flag>SUFFICIENT</sec:control-flag>
<wls:host><AD_HOSTNAME> </wls:host>
<wls:port><AD_PORT></wls:port>
<wls:ssl-enabled>false</wls:ssl-enabled>
<wls:user-name-attribute>SamAccountName</wls:user-name-attribute>

<wls:principal>CN=<CN>,OU=<OU>,DC=<DC>,DC=<DC></wls:principal>
<wls:user-base-dn>DC=<DC>,DC=<DC></wls:user-base-dn>
<wls:credential-encrypted>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</wls:credential-encrypted>

<wls:user-from-name-filter>(&(sAMAccountName=%u)(objectclass=user))</wls:u
ser-from-name-filter>
<wls:cache-size>32</wls:cache-size>
<wls:group-base-dn>DC=<DC>,DC=<DC></wls:group-base-dn>
<wls:group-search-scope>onelevel</wls:group-search-scope>
<wls:connection-pool-size>500</wls:connection-pool-size>
<wls:group-membership-searching>limited</wls:group-membership-searching>
<wls:max-group-membership-search-level>2</wls:max-group-membership-search-level>
<wls:keep-alive-enabled>true</wls:keep-alive-enabled>
</sec:authentication-provider>

In jps-config.xml, for application level authentication
<serviceInstance name="ADAuthenticator"
provider="idstore.ldap.provider">
<property name="username.attr" value="sAMAccountName"/>
<property name="user.login.attr" value="sAMAccountName"/>
</serviceInstance>
<serviceInstance name="idstore.ldap" provider="idstore.ldap.provider">
<description>LDAP Identity Store Service Instance</description>
<property name="virtualize" value="true"/>
<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"/>
<serviceInstanceRef ref="ADAuthenticator"/>
</serviceInstance>

 
The application integrates with the Worklist functionality by using the WebServices like TaskQueryService. To invoke TaskQueryService,first need to provide the authentication credentials, get the token and execute theTaskQuery Service. Most of the calls are successful but a few started failing
recently. Please see the error below.

The <sample_user> is defined in Weblogic as a local user using DefaultAuthenticator , Oracle SOA Suite 12.2.1.4

The recent change done was to connect to LDAP with ldaps.

<InvokeTaskQueryService_authenticate_InputVariable>
-<part name="payload" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">-<credential xmlns="http://xmlns.oracle.com/bpel/workflow/common">
<login>sample_user</login>
<password><password></password>
<identityContext>jazn.com</identityContext>
</credential>
</part>
</InvokeTaskQueryService_authenticate_InputVariable>

<fault>
-<bpelFault>
<faultType>1</faultType>
-<processingErrorFault
xmlns="http://xmlns.oracle.com/bpel/workflow/taskQueryService">
-<part name="payload">
-<taskQueryServiceFaultResponse
xmlns="http://xmlns.oracle.com/bpel/workflow/taskQueryService">
<message xmlns="http://xmlns.oracle.com/bpel/workflow/taskQueryService">

Failing with the following error

ORA-30501:exception.code:30501
exception.type: ERROR
exception.severity: 2
exception.name: Error in authenticating user.
exception.description: Error in authenticating and creating a workflow
context for user jazn.com/<workflowname>.
exception.fix: Verify that the user credentials and identity service
configurations are correct.

</message>
</taskQueryServiceFaultResponse>
</part>
</processingErrorFault>
</bpelFault>
</fault>

There is no failure (in most cases, see below for details).
The problem is that despite the user is found on the first provider, the libOVD is still queries the second provider. That is, the adapters_os.xml (as well as WLS config.xml ) has 2 adapters: WLS internal LDAP and <AD>.
Most of the operations are performed using the WLS internal LDAP, so it's configured to be the first one.
In this scenario the user is found on the WLS internal LDAP, but then we can see that the libOVD still goes to the <AD>.
The behavior has 2 implications:
The calls are slower because of the unnecessary request to the corporate LDAP after the user has been found on the internal LDAP . - Once in a while the request to the corporate LDAP fails with the above error

The goal here is to ensure that if the user is found on the 1st provider adapter, we should avoid the call to the 2nd provider.

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.