Chuni Lal Kukreja Kubernetes, OAM, OAAM, OIM, Webgate,Active Directory,SharePoint,IIS Blog: OAM 11G r2ps2

Showing posts with label OAM 11G r2ps2. Show all posts

Tuesday 9 December 2014

Purpose of Max Session Time OAM

Purpose of Max Session Time field:

Max Session Time (hours)

Maximum time to keep server connections alive. The unit is based on the maxSessionTimeUnits user-defined parameter which can be 'minutes' or 'hours'. When maxSessionTimeUnits is not defined, the unit is defaulted to 'hours'.

What does this above definition means?

Basically this is the session time for the OAP/NAP connections made between Webgate & OAM Server.
This is the TTL (Time to live) of these OAP/NAP connections.

Is this field defines the time in minutes or hours?

By default it is in 'hours'. But when you create a Webgate Agent Profile there is a user defined parameter defined as 'maxSessionTimeUnits' & it has value 'minutes'.
Thus this makes the value configured in 'MAX SESSION TIME' in minutes.

In this agent profile we have max session time configured as '2'. This is in minutes why?

Because we have configured the user defined parameter 'maxSessionTimeUnits' & value of this parameter is 'minutes'.

But if you remove this parameter 'maxSessionTimeUnits' than MAX SESSION TIME will have 'hours' as its unit.

Note:

User won't be challenged for credentials again because of the 'MAX Session time'. This time is not user session timeout. It is for the OAP/NAP connection timeout.

How will you test these connections?

bash$> netstat -anp | grep 5575 | grep httpd.worker

Note:

Port 5575 is the listening port used by the OAM Server. While creating webgate agent profile server connection port is mentioned.
'httpd.worker' is the OHS server process.
In this example 2 worker threads have made OAP/NAP connection with the OAM Server.

After 2 minutes these connections are re-established, here is the proof.

Hope it clears your doubts.....!!!!!!

Reference Doc:
http://docs.oracle.com/cd/E40329_01/admin.1112/e27239/register.htm#AIAAG631

Enjoy :-)

Monday 1 December 2014

[OAM]: Configuring pre authentication Advance Rules

Configuring pre authentication Advance Rules:

Pre-Requisites:

OAM Managed & Admin Server are up & running.
You have already created the 'Webgate Profile' & the artifacts are placed in the webgate instance directory.

1) Log in to OAM Console: http://<host:port>/oamconsole

2) Go to 'Application Domain' & select the webgate profile that you have created. Like in our case i am using 'dcc-7778'.

3) Select 'Authentication Policies' tab:

Open 'Protected Resources':

4) Now we need to select the 'Advanced Rules' tab:

Let's create a pre-authenticate rule: Click the '+' sign

Fill the fields:

Rule Name - Provide the rule name.
Condition - This will be a condition which needs to be configured using Jython Script style.
Switch Authentication Scheme - If condition is true, than we will switch the Authentication Scheme.
Deny Access - If this flag is true, than no need to configure 'Switch Authentication Scheme'.

Click 'Add' to add the rule.

Apply the changes.

5) The rule that we have created above states that if User IP Address starts with '10.' than switch the configured Authentication Scheme from the one we have configured to 'Basic Scheme'.

6) Now we are good to test the changes done. Let's hit the request, it should ask for credentials but as per 'Basic Scheme'

http://<host:port>/index.html

Note: The Client IP Address here starts with '10.'

Reference: https://docs.oracle.com/cd/E52734_01/oam/AIAAG/GUID-1E9A2B43-140C-4A85-8DEA-521CE3F57B12.htm#AIAAG88930

Hurray.... we are done... congrats... :-)

Enjoy :-)

Monday 27 October 2014

Exception: "Oracle AccessGate API is not initialized"

Problem Statement:

Following exception is seen while starting the OHS Server (which has webgate.so included):

"Exception thrown during WebGate initialization"
"Oracle AccessGate API is not initialized"

Issue:

This is surely a configuration related issue. Remember always first doubt the configuration and than the component. That's the thumb rule.

Solution:

1) Usually when we use security mode other than Open i.e. either Simple or Cert mode. We get this type of exception.

Now the question arises why?

Basically there are some steps that we follow to change the security mode.

Like for Simple Mode: http://oracleoam.blogspot.com/2014/08/configure-simple-mode-communication-for.html

Here say if we don't provide the Global Passphrase Password. And we just apply the rest of the changes. So when we try to start OHS Server or any server using the webgate component. It will throw these exception.

Note:

Here if you don't provide any password for global passphrase, you still see the field as non-empty but that value is junk. And it needs to be provided a valid password, which could be any. But you have to provide it.
Basically while doing the SSL handshake with the OAM Server this password is passed with other values. That's why it is important to provide one.

Enjoy :-)

Monday 22 September 2014

Installing and Configuring Oracle Identity and Access Management 11g Release 2 (11.1.2.2.0)

Installing and configuring the latest version of Oracle Identity and Access Management 11g components involves the following steps:

Note: ** If you are installing Oracle Identity Manager, you must install Oracle SOA Suite 11g Release 1 (11.1.1.7.0). Note that only Oracle Identity Manager requires Oracle SOA Suite. This step is required because Oracle Identity Manager uses process workflows in Oracle SOA Suite to manage request approvals.

Enjoy :-)

Friday 5 September 2014

Configuring OAM11G R2PS2 for Impersonation Module (Integrated Mode)

Enabling Impersonation Module:

This post is part of series Enabling Impersonation Module in OAM11G R2PS2 IIS7.5

1) Registering Impersonation Module

· We need to register the impersonation module at Global level and so that other sites can configure it at their end.

· Go to the Global site level, open Modules

· Go to “Configure Native Module” (see at the top right corner)

· Click Register.

o Provide a name -> “OAMImpersonation” & path to the IISImpersonationModule.dll (present in webgate install directory).

o Press OK

o As you can see the Module is added to the list.

o But beware don’t add this module at Global Level. We only need to register it here & we will be adding this per site level.

2) Adding Impersonation Module at Site Level:

· Go to your site -> Open Modules

· Configure Native Module:

· The moment we add the module, web.config of the site gets updated.

Extract from it:

Note: The above configuration is valid for the site running in Integrated Mode.

· Thus now we have configured the IISImpersonationModule.dll with our site.

· Restart the IIS Server.

· Now we need to do some configuration at OAM Console end.

· Open OAM Console ->

1) Adding Response Header in Authorization Policy

· Go to Application Domain -> Open WebGate Profile -> Authorization Policy -> Protected Policy

Note- It is not mandate to use ‘Protected Policy’, we are using because we have explicitly not specified the Policy.

· Open Responses Tab (in authorization policy) & add a new response field.

Note: The header field name should be “IMPERSONATE” and value “$user.userid”.

· Add the Response Header & Apply the changes.

· Now at User defined parameter in Webgate Profile:

MSImpersonationCredential=clk:Welcome1

Remember: This user defined parameter contains username & password, this should be an admin user. Because an admin user has the rights to perform impersonation.

· Apply the changes.

3) Performing Impersonation:

1) Deploy the ASP.NET application in your created site.

2) Impersonation feature is activated.

3) Now we will access the resource /WebApp/default.aspx. <we have created a sample app>

o Provide login credentials – try using some other user login rather than using admin login.

o Before you sign in to the system, Open Event Viewer -> Under Windows Logs -> Click Security

o Now do the login, after user authn & authz checks, user is provided the resource access.

Note: This is a sample app created.

· Now to check whether user is impersonated or not.

For this we check the system security event logs, to see that user ‘test’ is impersonated by the admin user ‘clk’.

As we have already opened the event log viewer, now see we have an entry ‘Credential Validation’ entry log.

It shows that system is authenticating the user with credentials of the admin user ‘clk’ that we have provided in the user defined parameters.

o Now Click ‘Log on’ event log above the ‘Credential Validation’ Log. It shows that the system has authenticated the user with ‘clk’. Thus it proves that user ‘test’ has logged in to the system with the credentials of ‘clk’ thus it is impersonated.