Configuring Design Console for OIM 11g

In OIM 11g, Design Console still is a required tool for system configuration, custom development and customization. But differently from OIM 9.x, Design Console 11g does not have its own installer anymore. It is installed and configured along with the OIM server installation.

One of the common questions around Design Console 11g is: if there is no installer anymore, how do I get it working on my desktop/laptop without installing the whole Identity and Access Management pack?

This is an easy task and this post describes the steps for getting it done:

1. If you don't have a JDK 1.6 in your laptop, you will have to install it.

2. Run the configuration script for OIM once again. The script is available at $IAM_HOME/bin (where IAM_HOME is the folder where the ‘Identity and Access Management Pack’ was installed). You have to run the ‘config.sh’ that is available at $IAM_HOME/bin folder and NOT the one available at ‘$IAM_HOME/common/bin/config.sh’

3. In the configuration wizard, select ‘Design Console’ checkbox ONLY.

4. In the next screen, enter the OIM server host and port name. The wizard will configure the Design Console files for you
Courtesy:http://fusionsecurity.blogspot.com/

More about → Configuring Design Console for OIM 11g

Quick “Report” of all OIM Open Tasks

Here’s a quick SQL script that’ll list out all the open tasks with their login, date, and details:

select oti.sch_actual_start,oti.sch_data,usr.usr_login from oti inner join orc on oti.orc_key=orc.orc_key inner join usr on orc.usr_key=usr.usr_key where oti.sch_actual_start>’15-AUG-10′

More Here

Courtesy:http://idmrockstar.com/blog/2010/08/quick-report-of-all-oim-open-tasks/

More about → Quick “Report” of all OIM Open Tasks

Starting/Stoping Oracle 11g Identity management stack

Starting/Stoping Oracle 11g Identity management stack

Starting IDM Admin server:

MW_HOME/user_projects/domains/domain_name/startWebLogic.sh

Starting IDM wls_ods1 managed server:

MW_HOME/user_projects/domains/domain_name/startWebLogic.sh wls_ods1

Starting Oracle Internet Directory and Oracle Virtual Directory:

ORACLE_INSTANCE/bin/opmnctl startall

You can verify that the system components have started by:

ORACLE_INSTANCE/bin/opmnctl status -l

Starting IAM Admin server:

MW_HOME/user_projects/domains/domain_name/startWebLogic.sh

Starting OAM, SOA and OIM managed servers:

MW_HOME/user_projects/domains/domain_name/bin/startManagedWebLogic.sh oam_server1

MW_HOME/user_projects/domains/domain_name/bin/startManagedWebLogic.sh soa_server1

Always start SOA managed server, before OIM. Although both independent, but OIM needs some of SOA workflow functionality.

More Here

Courtesy:http://www.gdbsinc.com/blog/?p=46

More about → Starting/Stoping Oracle 11g Identity management stack

How SSO works in OAM 11g

Here at Oracle, the access management PM team gets asked a lot of questions about how Oracle Access Manager 11g works, especially about the overall SSO model, what cookies are created and what they do, and processing flows between components, and how specific component interactions work to achieve authentication and SSO. In this post, we will explore the OAM 11g SSO model. It’s quite a bit different from the OAM 10g model, especially since we now support things like server side credential collection, server-based session management, and application scoped sessions.

Before we get started, it’s worth noting that OAM 11g supports the use of both OAM 10g and 11g Webgates as well as mod_osso plug-ins for Oracle HTTP Server (OHS). We support this through what we call the Protocol Compatibility Framework, which lets the OAM server communicate with and interpret protocol messages from the webtier agents mentioned above. This is an extensible framework so has the potential to support other clients or agents in the future.


OAM 11g uses a combination of host cookies or domain cookies (depending on the version of Webgate you use), a server cookie, and an in-memory session store (based on Oracle Coherence technology) to maintain and correlate user session information.
Since OAM 11g supports different Webgate versions and mod_osso, you will see different cookies depending on the version of Webgate being used, you will either see the ObSSOCookie (for 10g) or OAMAuthnCookie_host:port (for 11g).
However in both cases, the contents of the cookies are:

• Authenticated User Identity (User DN)
• Authentication Level
• IP Address
• SessionID (Reference to Server side session – OAM11g Only)
• Session Validity (Start Time, Refresh Time)
• Session InActivity Timeouts (Global Inactivity, Max Inactivity)
• Validation Hash

These cookies are updated periodically using an algorithm of 1/4 of idle session timeout. There are two main differences between the 10g and 11g cookies:

• The 10g ObSSOCookie is domain scoped and cookie encryption uses a shared key for all 10g Webgates.
• The 11g OAMAuthnCookie is hosted scoped and different host cookies may be issued for each resource accessed that is protected by a different 11g Webgate. Cookie encryption for each 11g Webgate is unique to that Webgate.

The values of the cookies will change over the life of a user's session, however you'll notice that the Session ID that is present is a reference to the server side session object, which remains the same across the life of a session.
In the typical deployment topology, you’ll have one or more Webgates deployed on web servers in the Web Tier, a variety of components deployed in the App Tier including an OAM admin server running on the Weblogic domain’s admin server, one or more OAM runtime servers deployed on Weblogic managed servers, a database to support the OAM policies, an LDAP directory against which you will authenticate users, an optional auditing database, and an optional BI Publisher instance for reporting.
Using an OAM 11g Webgate in the flow, let’s recap how this works:

1) An OAM 11g Webgate intercepts the incoming request for a resource, determines whether the resource is protected, and – if it is – the OAM 11g server constructs and returns a response back to the Webgate. That response contains the authentication scheme required to authenticate the user.

2) Next the Webgate sets a cookie (called OAM_REQ) to keep track of the target/requested URL and then redirects to the OAM 11g server, which routes the request to the credential collector. The credential collector serves up the login page, which captures credentials and posts the credentials to the OAM server. The credentials are validated against the ID store configured for this particular authentication scheme. Once the credentials are validated, the OAM server creates an authentication token, the session in Coherence, and creates a server side session cookie called the OAM_ID cookie, which has details about the user, the time the session was created, the idle timeout, and session identifier to the coherence session.

More Here

Courtesy:http://oracleaccessmanagement.blogspot.com/2011/03/here-at-oracle-access-management-pm.html

More about → How SSO works in OAM 11g