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.

Feldet error : "java.lang.ExceptionInInitializerError"

I have completed the SP initiated SSO integration with IDP partner using Fedlet as Service Provider. Later, when I moved the fedlet configuration directory to a different location, it is throwing the below exception:

java.lang.ExceptionInInitializerError
at jsp_servlet._saml2._jsp.__fedletssoinit._jspService(__fedletssoinit.java:132)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:34)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:301)
Truncated. see log file for complete stacktrace
Caused By: java.lang.NullPointerException

Changes I made:

• Moved the fedlet configuration directory to a different location.

• Updated the startWebLogic.sh script to include the new fedlet home as shown below.

JAVA_OPTIONS="${JAVA_OPTIONS} -Dcom.sun.identity.fedlet.home=/apps/tap/Oracle1036/user_projects/domains/tap_pit1/config/fedlet"

export JAVA_OPTIONS

• Restart the WebLogic server.
• Access the fedlet SP initiated SSO URL.

Troubleshooting:
Upon starting the weblogic server, the new fedlet home is not visible as JAVA_OPTIONS.

Fix:

• Update startWebLogic.sh script to include fedlet home parameter directly in java execution line as shown below. Update in the same manner in all the other java execution lines present in the script.

echo "${JAVA_HOME}/bin/java ${JAVA_VM} ${MEM_ARGS} -Dweblogic.Name=${SERVER_NAME} -Djava.security.policy=${WL_HOME}/server/lib/weblogic.policy ${JAVA_OPTIONS} -Dcom.sun.identity.fedlet.home=${DOMAIN_HOME}/config/fedlet ${PROXY_SETTINGS} ${SERVER_CLASS}"

• Restart the WebLogic server. Make sure that fedlet home appears in java options by using ps -ef | grep java

JDK version while using Fedlet

Please make sure you all use JDK6.0 version while customizing or setting up fedlet instance. This is because the fedlet jars such as openfedlib.jar and opensso-sharedlib.jar are generated based on JDK6 version.

Customizing Fedlet

I have been working on fedlet a lot these days. The greatest advantage of using fedlet is the customization. Since it is open source product, the jars available from fedlet application allows us to customize the federation process. It is also more useful to integrate with Custom IDPs.

The important jar files are:
openfedlib.jar
opensso-sharedlib.jar

These jars are present in fedlet sample application generated during fedlet setup. The major java files where customization can be made are:

SPSSOFederate.java generates the SAML Authentication request.
SPACSUtils.java processes the SAML response.
SAML2Utils.java verifies the response for validity of SAML response and assertion, signature and encryption.

Once these java files are modified appropriately, compile the class file and put the class file back to openfedlib.jar. Place the jar under application WEB-INF/lib folder and restart the application server (where fedlet is deployed) for changes to take into effect.

If you get any exceptions in fedlet, you can look for libSAML2.properties file located under WEB-INF/classes for all mapped error scenarios.

For example, while testing the SAML SSO, if  you see exception "Version is not present in the request" then look for mapped error in the libSAML2.properties file. Then search in fedlet java classes where missingVersion error is thrown.

missingVersion=Version is not present in the request.

Let me know if you need assistance to customize any specific functionality with fedlet, I can help you.