Tuesday, October 14, 2014
Since OAM 10g days, keeping track of Protected Resource that user wanted to access throughout custom authentication process has been a challenge. In OAM 10g, it was possible to create custom OBFormLoginCookie to overcome that challenge. With the introduction of Encrypted OAM_REQ cookie in OAM 11g, it is not feasible. That makes it difficult to do post Authentication operations or any customizations in Authentication process.
OAM 11gR2 introduced a feature where you can redirect user to a URL post successful Authentication (On Authentication success event in Authentication policy as defined in the screen shot below). OAM while doing that redirect, adds end_url query parameter to URL with the value of protected resource that user tried to access. You can do any post Authentication processing required on Authentication success URL and then redirect user to end_url.
One of the use cases of the feature is, when you do OAM-OAAM integration, you can invoke OAAM post Authentication rules before redirecting user to protected resource the user was trying to access. Here is the Architecture diagram for the use case described above.
Note: Architecture diagram below is representative diagram for the use case and does not represent Oracle recommended Architecture for OAM deployment.
Social Federation: a somewhat fancy name for a simple concept. We want to leverage identities in Social Network providers in our own applications. For example, granting access to either cloud or on-premise applications to end users using their Google identities. In this post we're going to take a close look at the necessary configuration in OAM M&S (Oracle Access Manager Mobile & Social) server to have Java Web applications leveraging Google and LinkedIn identities.
Conceptually, this is very similar to SAML-based federation model indeed. The difference is that we are now dealing with different protocols, like OpenID and OAuth. And the main appeal for federation keeps being the acceptance of third party identities by a service provider (a.k.a. relying party) without the need of having end user passwords stored locally.
Friday, September 26, 2014
Recently while working with a customer to help with an upgrade from OIM 11gR1 to 11gR2PS2, one interesting request came up regarding OIM GUI customization.
The requirement was to expose some User System Attributes that in R1 were directly available in the GUI customization data but in R2 are not exposed in the GUI Customization options.
There is a way in R2 to easily expose the data using a custom Managed Bean along with some GUI tweaks.
The process for customizing the OIM UI is easy enough and well documented in the OIM Customization Guide.
The following content takes you through the steps for exposing the User System Attributes.
Thursday, September 18, 2014
IntroductionThis post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available. The Detached Credential Collector (DCC) feature was introduced with the release of OAM 11gR2 --- 220.127.116.11.0. DCC brought some very interesting changes in the authentication model that in my opinion are very welcome; more on that later. There is already Oracle documentation out there on this feature, along with an A-Team blog article Debasish Bhattacharya created (Detached Credential Collector Configuration – OAM 11GR2) , which adds some more insight on configuring DCC. This blog is to enlighten everyone with some more information on what is going on with DCC, both for login and logout. Then in Part 2 – Custom Login and Logout with Detached Credential Collector, I want to clear up some confusion on how many may think using DCC can only be done with the Oracle supplied login.pl and logout.pl Perl scripts; that is far from the truth. So let’s dig in and expose some of the mysteries of the Detached Credential Collector.
Posted by Tim Melander at 12:55 PM