Tuesday, June 14, 2011
How to setup Oracle Access Manager in disaster recovery mode?
In every real time environment, you would use two production sites i.e., Active , Stand-by. At a time, only one site will be up and running. This means all the transactional data with respect to Oracle Access Manager will be present in LDAP (user data, configuration data, policy store). However I am going to talk about providing disaster recovery setup for LDAP used by OAM. I would like to stress the key points involved in setting up OAM 10g for disaster recovery with less or no manual intervention.
I have explained much detailed here.
I have explained much detailed here.
How clustering works with Access Server and WebGates
This post talks about webgate communicating with multiple access servers which are deployed in Primary/Secondary scenario. I have explained in detail about this post here.
Please feel free to reach me if you have any queries.
Please feel free to reach me if you have any queries.
Global Logout in Oracle Access Manager 10g
This post covers the Global Logout operation to be performed in Oracle Access Manager 10g. If you look at the OAM 10g documentation for Global Logout, it just talks about having logout keyword in the logout URL (except logout images etc.,).
In reality, achieving Logout is not an easy job with Oracle Access Manager. If there are multiple products integrated with OAM 10g, killing obssocookie alone will not suffice the job. The cookies or sessions of applications that are integrated with OAM 10g needs to be implicitly killed and this is all customization. This is explained in detail in the post.
The most challenging part of this Global Logout is : User logs into Portal 11g and access multiple applications (custom and Legacy) within same session so is different cookies/sessions gets created for respective applications. Logout link is enabled only in Portal 11g but not in any of the other downstream applications. The concept is simple that single Logout at a single place. When the logout is performed in Portal 11g, Portal and OSSO related cookies/sessions gets cleared. However, cookies/sessions pertaining to other apps are not deleted and hence logging in a different user with in same browser session pertains old user session. Easy way to overcome this is to close all the IE browsers. An exception to this is to use < IE6 as there is a browser session sharing feature implemented in IE7 and above.
Now let us talk about the actual scenario.
To talk about our environment, there are almost 8 applications which is a mix of Custom applications and Legacy applications such as PEOPLESOFT, SIEBEL, ORACLE PORTAL 11g. Since Oracle Portal 11g integrates with OSSO - OAM 10g directly, there is a Logout page in OSSO (of Portal) which has functionality to delete OSSO related sessions for Portal. Since we used logout URL which calls logout.jsp, the OAM treats as logout call by default and sets the ObSSOCookie to loggedoutcontinue.
Custom applications has Apache based servers in front-end and Tomcat/WebLogic in backend where target applications are deployed. Each custom application has their own Logout functionality implemented. Same is the case with Legacy applications which has their own Logout pages with specific logout functionality.
How is Logout implemented then? Primary source for all applications is Oracle Portal for which performing logout is an easy job and clears all Portal related cookies. So from Portal logout.jsp, a call is made to the other application say PEOPLESOFT to clear Peoplesoft related sessions. The chain goes like this until all cookies/sessions pertaining to all applications are cleared.
The negative side of this approach is that the latency because calls are made to all the applications in the architecture. You can take this granted for a single reason : Logout is performed as heavily as Login or other transactions.
In reality, achieving Logout is not an easy job with Oracle Access Manager. If there are multiple products integrated with OAM 10g, killing obssocookie alone will not suffice the job. The cookies or sessions of applications that are integrated with OAM 10g needs to be implicitly killed and this is all customization. This is explained in detail in the post.
The most challenging part of this Global Logout is : User logs into Portal 11g and access multiple applications (custom and Legacy) within same session so is different cookies/sessions gets created for respective applications. Logout link is enabled only in Portal 11g but not in any of the other downstream applications. The concept is simple that single Logout at a single place. When the logout is performed in Portal 11g, Portal and OSSO related cookies/sessions gets cleared. However, cookies/sessions pertaining to other apps are not deleted and hence logging in a different user with in same browser session pertains old user session. Easy way to overcome this is to close all the IE browsers. An exception to this is to use < IE6 as there is a browser session sharing feature implemented in IE7 and above.
Now let us talk about the actual scenario.
To talk about our environment, there are almost 8 applications which is a mix of Custom applications and Legacy applications such as PEOPLESOFT, SIEBEL, ORACLE PORTAL 11g. Since Oracle Portal 11g integrates with OSSO - OAM 10g directly, there is a Logout page in OSSO (of Portal) which has functionality to delete OSSO related sessions for Portal. Since we used logout URL which calls logout.jsp, the OAM treats as logout call by default and sets the ObSSOCookie to loggedoutcontinue.
Custom applications has Apache based servers in front-end and Tomcat/WebLogic in backend where target applications are deployed. Each custom application has their own Logout functionality implemented. Same is the case with Legacy applications which has their own Logout pages with specific logout functionality.
How is Logout implemented then? Primary source for all applications is Oracle Portal for which performing logout is an easy job and clears all Portal related cookies. So from Portal logout.jsp, a call is made to the other application say PEOPLESOFT to clear Peoplesoft related sessions. The chain goes like this until all cookies/sessions pertaining to all applications are cleared.
The negative side of this approach is that the latency because calls are made to all the applications in the architecture. You can take this granted for a single reason : Logout is performed as heavily as Login or other transactions.
Subscribe to:
Posts (Atom)