OAM 11g : System error after DCC tunneling authentication

Hi All,

My apologies for taking long time to write a post in this blog. Better late than never. Today I'm writing about an issue we encountered in OAM 11g.

Our environment is OAM 11gR2 PS2 BP03 and we have tunneling enabled at DCC Webgate. An OHS application is protected using DCC tunneling authentication scheme (I will explain the DCC tunneling in a separate post). When the user access the OHS application, a login page is displayed and user submits credentials. Post authentication, instead of redirecting to OHS application, System error message is displayed.

I'd ensured that credentials are correct, back end user identity store is running fine.

I'd seen below exception in OAM Server diagnostic logs:

oracle.security.am.pbl.protocol.plugin.oam.AMFailureResponseHandler] [SRC_METHOD: processResponse] OAM-02073[[
oracle.security.am.common.utilities.exception.AmRuntimeException: OAM-02073
at oracle.security.am.engines.enginecontroller.AuthzEngineController.checkProtected(AuthzEngineController.java:614)
at oracle.security.am.engines.enginecontroller.AuthzEngineController.processEvent(AuthzEngineController.java:199)
at oracle.security.am.controller.MasterController.processEvent(MasterController.java:596)
at oracle.security.am.controller.MasterController.processRequest(MasterController.java:788)
at oracle.security.am.controller.MasterController.process(MasterController.java:708)
at oracle.security.am.pbl.PBLFlowManager.delegateToMasterController(PBLFlowManager.java:209)
at oracle.security.am.pbl.PBLFlowManager.handleBaseEvent(PBLFlowManager.java:147)
at oracle.security.am.pbl.PBLFlowManager.processRequest(PBLFlowManager.java:107)

I'd ensured that Authentication scheme is correct as the same setup was working in other environment.

I'd come across an article 1578776.1 talking about similar exception but it was in OAM 11gR1 and for custom Login page. In our case, we are using default login page served from OAM Server.

I did see that OAM Server could not redirect to the requested URL post authentication as I don't see OAM_REQ cookie in /oam/server/auth_cred_submit http request.

I remembered a setting in oam-config.xml "serverRequestCacheType" which takes BASIC, COOKIE and FORM values.

Currently it is set to FORM in a non working environment. FORM value means, the OAM_REQ token has to be returned to OAM Server in Login page. COOKIE value means, only userid and password along with request_id has to be returned to OAM server in login page. Since we are using default login page, only userid and password are returned to OAM Server.

Therefore with FORM value setting, OAM Server authenticates the user but does not know the requested URL or data containing original requested URL and it throws System Error.

Fix:

1. Stop the OAM servers (managed + admin).
2. Take backup of oam-config.xml
3. Change the value serverRequestCacheType from FORM to COOKIE.
4. Change the Version (increment with 1).
5. Start OAM Servers.

Retest the scenario and you will see that user is redirected to original requested URL. 

Please leave your comments.

Reading OAM Http header variables through CGI script

I was working on providing single sign-on for one of the CGI applications. I had set header variables in Authorization Rule Actions for User ID and other attributes as say AUTH_USER etc., While trying to read the headers in CGI app with name AUTH_USER, it is not available.

Upon reading/displaying all the headers in CGI application, it was reading with HTTP_AUTH_USER instead of AUTH_USER. I'm wondering if this is the default behavior of CGI app for reading headers! You can post your thoughts too...

OAM WebGates in SELINUX environments

I have recently worked on OAM SSO integration issue in RHEL 6.3+ environment which is SELINUX enabled.
There is Apache 2.2 Server 64-bit and respective webgate is installed. After restarting the Apache Server, we are seeing the error messages given below:

 Oblix: 2014/02/03@20:20:41.155559#01115170#01115183#011ACCESS_GATE#011FATAL#0110x00001520#011/scratch/alnguyen/Oblix/coreid1014/palantir/webgate2/src/apache2entry_web_gate.cpp:433#011"Exception thrown during WebGate initialization"#011

 Oblix: 2014/02/03@20:20:41.161535#01115170#01115183#011ACCESS_GATE#011FATAL#0110x0000182A#011/scratch/alnguyen/Oblix/coreid1014/palantir/webgate2/src/apache2entry_web_gate.cpp:434#011"An internal ObError exception was caught."#011raw_code^219#011

Essentially, the webgate is not working and hence the web page access is resulting with error "This webpage has a redirect loop".

We have tried to look below options:

1. Upon enabling the webgate log in TRACE, nothing interesting was found except that webgate initialization error. Verified the webgate folder level permissions to match the web server user group permissions.
2. Reconfigured the webgate using configureWebGate command.
3. Verified the connectivity from WebGate to OAM host.

Finally, we found some denied errors in web server audit log while accessing the webgate protected pages. These errors are due to insufficient permissions at the Unix level. After modifying those permissions, webgate has started working fine.

I will post the Unix level changes made to fix the issue soon.

OAM 10.1.4.3 bundle patches list

Here is the metalink note 736372.1 that provides OAM Bundle Patches list for all versions including 7.x, 10.x,11g

Find OIF version

After patching OIF from base 11.1.1.2.0 to higher version and still you're seeing OIF 11.1.1.2 in WebLogic console? Do you want to know if the version has upgraded after patching successfully, well here is a simple way to do:

1.     Goto /inventory/Patches21/oracle.idm.oif
2.     Run 'ls -la'
3.     It would display 3 results. OIF version can be found from the below sample results of this command.

drwxr-x---   3 idmadm   idmadm        96 Jan 20  2012 .
drwxr-x---  33 idmadm   idmadm      2048 Jan 20  2012 ..
drwxr-x---   3 idmadm   idmadm      1024 Jan 20  2012 11.1.1.5.0

There is an alternative approach.

1. Goto  /OPatch
2. export ORACLE_HOME variable.
3. export PATH variable by appending ORACLE_HOME/OPatch
4. Run opatch lsinventory

Using the customized OIF.ear file in 11g

This is regarding OIF 11g environment. There are 2 OIF servers in a cluster. Typically when OIF application is customized the updated oif.ear has to be moved to the location $ORACLE_IDM_HOME/fed/install (I have made changes to web.war present in oif.ear. To make changes to oif.ear don't unzip or extract it, just open it using zip tools and make the changes and save the ear file). If the OIF cluster instances are in different servers, then oif.ear has to be placed in all the other servers too.

Delete the files present in the locations $WL_DOMAIN/servers//tmp/_WL_user/OIF_11.1.1.2.0 in all OIF server instances.

Restart the OIF managed servers. Access the OIF application and observe the changes. It has not reflected in my case. I spent a lot of time figuring out the locations where oif.ear is present and making sure whether changes are reflected. Finally I identified that WebLogic staging directory is where the OIF application is moved to and is holding old oif.ear.

So I copied the oif.ear to staging directories of all OIF instances and removed the files under $WL_DOMAIN/servers//tmp/_WL_user/OIF_11.1.1.2.0 and restarted the OIF server instances. I am glad that everything worked!!

oracle.security.fed.event.exceptions.UnknownProviderException: Unknown Provider

While testing the IDP initiated SSO with IDP as OIF and SP as custom solution, we are getting 500 Internal Server error error.
The URL is of the format : http://idp_host:port/fed/idp/initiatesso?providerid=http://sp-host:port/app

We got the below exception in OIF logs.

[2013-06-25T13:00:29.732-07:00] [wls_oif1] [ERROR] [FED-15034] [oracle.security.fed.eventhandler.profiles.idp.sso.CreateAuthnRequestEventHandler] [tid: [ACTIVE].ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: ] [ecid: 8285f2bb4b55ec93:-773f8c6e:13f5ce4fa24:-8000-000000000000e9a4,0] [APP: OIF#11.1.1.2.0] Profile is unknown: https://sp-host:443/sso/saml/SSO
[2013-06-25T13:00:29.732-07:00] [wls_oif1] [ERROR] [FED-12064] [oracle.security.fed.controller.ActionStateMachine] [tid: [ACTIVE].ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: ] [ecid: 8285f2bb4b55ec93:-773f8c6e:13f5ce4fa24:-8000-000000000000e9a4,0] [APP: OIF#11.1.1.2.0] Exception: {0}[[
oracle.security.fed.event.exceptions.UnknownProviderException: Unknown Provider: https://sp-host:443/sso/saml/SSO

The root cause is accessing wrong service provider URL.
To know the correct provider ID URL, login to OIF console -> Oracle Identity Federation -> Federations. Notice the provider ID and use it in the IDP initiated SSO URL.