Recommendations while using custom federation

Suppose you are the Service Provider using COTS federation product and your partner is Identity Provider using custom federation solution. Here are some personal recommendations for achieving SAML Single Sign-On in a smooth manner.

1. Identify the features you are implementing with your partner upfront such as HTTP Binding, Signing, encryption, logout, Query Attributes, Account Linking etc., 
2. Discuss and agree the certificate, private key, encryption algorithms etc., 
3. Setup local environment to do proof of concept with COTS products and make sure you implement all the agreed features.
4. Make sure your partner having custom federation solution has done POC so that you are sure that they are adhering to SAML standards. 
5. If your partner has not done any POC in their local environment then you will need to validate the metadata manually before importing it to Service Provider.
6. When partner metadata is validated and make sure it is imported in your Service Provider properly. Be heedful of syntactical errors. 
7. If your partner has SAML response tested by dummy client, then ask for SAML response. If the response is encoded, use a SAML decoder and verify if all the elements are present. This is where we ended up wasting lot of time while running the test and identifying each and every element missing in SAML response. 
8. It is always suggested to test the basic federation without Signing/Encryption/Attribute Query etc.,
9. Once basic federation is tested, signing is next step.
10. Then test the encryption.

wlst.sh failed to connect in SSL

We have enabled SSL for WebLogic Admin Server and disabled the non-SSL port. We wanted to run some WLST commands and ran wlst.sh from
While trying to connect to wlst.sh with SSL port to admin server, the connection failed. I've tried various combinations of hosts with/without domain name and localhost too. See the below screenshot.

The actual fix is to add -Dweblogic.security.SSL.ignoreHostnameVerification=true parameter in startWebLogic.sh script. This parameter will essentially disable the hostname verification and required for stand alone clients connecting to weblogic server.

Restarted the WebLogic servers after making the script changes and wlst.sh connection worked with SSL.

Upgrading OAM from 11gR2 PS2 to 11gR2 PS3

In my previous posts, I have shared information about documentation and binaries of PS3 release. In this post I would like to briefly share my experiences of upgrading OAM from PS2 to PS3.

I have WebLogic 10.3.6 and JRockit 6 before upgrade and there is no change in those components even after upgrade.

Here are the pre-requisites required before upgrade:

1. Backup Middleware home and Policy database/schemas.
2. Stop all weblogic servers.

Here are the high level steps upgrading OAM to PS3 in a pure OAM 11g environment (without involving OAAM/OES etc.,).

1. Upgrade OAM binaries to PS3 : This step is a typical OAM installation process and it installs all binaries that are part of IAM package. Ensure that below screen appears that implies binaries are upgraded successfully.
   
2. Upgrade OAM, IAU and OPSS schemas : This step upgrades OPSS, IAU and OAM schemas to latest version to be compatible with OAM PS3 binaries. Verify the schema versions post upgrade, find the below screenshot.
   
3. Upgrade OPSS : This step upgrades the OPSS with configuration and policy stores to PS3. It upgrades jps-config.xml and policy stores. Note that it does not upgrade the OPSS schema which was upgraded in previous step already.
4. Undeploying Coherence : This step un-deploys Coherence module from OAM deployment. 
5. Upgrading System Configuration : This step is required to enable the PS3 features in OAM deployment. Ensure that message "System Configurations have been successfully upgraded to version: 11.1.2.3.0" in the end of script output.
   

If you intend to use Federation in Oracle Access Management then follow the below steps to enable it.

1. Goto <>/common/bin
2. Run the wlst.sh command
3. Connect to admin server.
4. Connect to domainRuntime()
5. Run the command upgradeFedSTS111230(). Ensure that message "command was successful" was displayed as shown in below screenshot.
   

Post Authentication rules are disabled by default. If you intend to use it, enable them by following below steps:

1. Login to OAM Admin Console.
2. Select Configuration
3. Select Available Services.
4. Enable Adaptive Authentication Service as shown below.

Login to OAM Admin Console to see the new look and feel :)

I will talk about my experiences with PS3 and its features in the future posts. 

OAM 11gR2 PS3 has been released

Oracle has released the Oracle Identity Management 11gR2 PS3 and here it is http://www.oracle.com/technetwork/middleware/id-mgmt/downloads/oid-11gr2-2104316.html

I would say they did well for PS3 documentation by branching different features into different sections such as Single Sign-On, policy model, Multi Data centers and installation steps and this looks clean. 

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.