Configuring Authorization Policy Conditions/Rules in OAM 11G R2PS2

Authorization Policy : Creating Condition/Rules

Basically if you are aware of the SSO thing, than you must know that once you are authenticated than you are checked for - WHETHER YOU ARE AUTHORIZED OR NOT.
And what does that means?

It means that if you are allowed to log in to the system than it needs to be checked that whether you are authorized to access the resource or not.

Generally we have Authorization Policy for Protected & Public Resources. But we can also specify our conditions & rules for these authorization policies.

So now the question arises what's the use of these condition & rules?

• Basically we can add our condition to allow or deny the user to access the resource.
• And thus we need to add these condition to the rules for allow or denial access.

Remember - You can create your condition & rules for each of the authorization policies created for the webgate profile. Their is no constraint of only single condition or so.

In this post we will be creating a condition for IP Range, for other condition soon i will be posting a new post.

Pre-Requisites:

• Webgate Profile is created.
• Working Webgate Instance is in place i.e. webgate is integrated with your server say OHS
• And You can properly access a protected resource.

Let's see how to configure Authorization policy:

1) Log in to oamconsole: http://host:port/oamconsole

2) Go to Application Domain -> Select Webgate Profile -> Go to Authorization policy

• Note: I will be adding condition with my Protected Authorization Policy
• By default there is just one condition added 'TRUE' which is also available in the Rules.
• This is allowable condition, & TRUE in all sense.

•  Now we will be adding a new condition, and this will be for IP Range testing.

• Apply the changes
• Now once it is added, than we need to add a condition in it. In the above step we have just created a condition entry, now we will be adding a condition to it.

• Here i will be adding a IP Range - i am blocking the IP Addresses starting from 10.0.0.0 to 10.255.255.255. Any IP Address coming for authorization having IP Range b/w this mentioned series. It will be not be able to access the resource.

 

• We need to add this condition in the rules table. You can see that we have 2 types of rule:
• Allow Rule
• Deny Rule

• Here we will be adding the condition in the 'deny rule' table.

• Apply the changes & we are good to go.
• Note: 
• We need not to restart the server instance, because the changes are done at the OAM Server side and as webgate talks to OAM via OAP/NAP connection. Thus OAM Server will tell the webgate about access or denial via this NAP only. That's why no restart required.
• But remember that in case we have done changes in the webgate profile, than server restart is a must.

• Lets test this by accessing the Protected Resource URL. And my ip address starts with 10.* series. Thus i will be getting a resource denial message.
• Access the resource. http://host:port/index.html
• Provide the credentials

•  Eureka....!!!! Did you see, we get the denial message for the resource index.html.

We are done with the Authorization IP Range Condition/Rules Testing....... Soon i will be adding the use cases for other condition tests as well....


Enjoy :-)

Cache Pragma Header OAM

In OAM SSO Agent configuration we have 2 caching headers:

1. Cache Control Header
2. Pragma Header

As per the RFC 2616, Pragma Header is their for backward compatibilty while in all the browers & client specfic system we all are using HTTP/1.1

Thus as per the HTTP/1.1 standard Cache-Control Header is in use.

So as the OAM Webgate 11g is developed as per the HTTP/1.1 statndard. Thus it makes use of this Cache-Control Header & Pragma is their just for backward compatibilty.

That's why you see that they both have same values & Pragma Header uses the same value as that of Cache-Control Header value.

Some more info related Cache Control Header:

HTTP 1.1 introduced a new class of headers, Cache-Control response headers, to give Web publishers more control over their content, and to address the limitations of Expires.

Useful Cache-Control response headers include:

• max-age=[seconds] — specifies the maximum amount of time that a representation will be considered fresh. Similar to Expires, this directive is relative to the time of the request, rather than absolute. [seconds] is the number of seconds from the time of the request you wish the representation to be fresh for.
• s-maxage=[seconds] — similar to max-age, except that it only applies to shared (e.g., proxy) caches.
• public — marks authenticated responses as cacheable; normally, if HTTP authentication is required, responses are automatically private.
• private — allows caches that are specific to one user (e.g., in a browser) to store the response; shared caches (e.g., in a proxy) may not.
• no-cache — forces caches to submit the request to the origin server for validation before releasing a cached copy, every time. This is useful to assure that authentication is respected (in combination with public), or to maintain rigid freshness, without sacrificing all of the benefits of caching.
• no-store — instructs caches not to keep a copy of the representation under any conditions.
• must-revalidate — tells caches that they must obey any freshness information you give them about a representation. HTTP allows caches to serve stale representations under special conditions; by specifying this header, you’re telling the cache that you want it to strictly follow your rules.
• proxy-revalidate — similar to must-revalidate, except that it only applies to proxy caches.

References:

https://www.mnot.net/cache_docs/


Enjoy :-)

Configuring DCC Webgate 11g with IIS7.5 on Windows 2008 R2

 Pre-requisites:

1. IIS Server Role is already added: In case not follow Configure IIS Server Role
2. IIS Site is created: 
1. IIS Site Global Configuration IIS
2. New Site Creation
3. IIS R2PS2 Webgate is installed & configured with the IIS Sites: Configure IIS R2PS2 Webgate 11g

Let's start the process:

• Open OAM Console : http://host:port/oamconsole

•  Create Webgate Agent Profile:
• We need to create 2 profiles: One is the resource webgate profile & other is DCC webgate profile.

•  Create Resource Webgate Profile: rwg-9090

Note: I have configured my OAM Server in Simple Mode, that's why security mode is chosen as 'simple'.

• Create DCC Webgate Profile: dcc-9091

Note: Once you have created  the profile, to make it DCC we need to tick the detached credential collector flag.

• Once done the change, click apply to reflect the changes.

•  Now we need to add resources to with the DCC profile just created:
• We need to add a few excluded resources, so that no authentication/authorization is made for them.

•  Select the dcc-9091 profile:

•  Let's create excluded resource:

•  We have created following excluded resources:
• /favicon.ico
• /oamsso-bin/login.pl
• /oamsso/** - Note this is an additional resource to be excluded as for IIS this needs to be excluded. Other wise for other servers it is not required.

•  Now we need to create a DCC Authentication Scheme: This scheme will be used by resource webgate & dcc webgate both.

• Now we need to attach the both created authn scheme with the profiles:

•  You can see that i have created 2 IIS sites & webgate is already configured with both of them.

• Now copy the artifacts to the webgate instance directory in the respective resource & dcc webgate sites.
• In our setup: we have rwg-9090 for resource webgate & dcc-9091 for dcc webgate.

• Once done, restart the IIS Server: using the command 'iisreset'. 
• Now access the protected resource webgate url:

          http://host:9090/welcome.html

• Did you noticed you get this login page, having url as http://host:9091/oamsso-bin/login.pl
• This is the challenge url that we have mentioned in the dcc authn scheme.
• With DCC webgate in picture, the oam server ip port is mot visible to the end user, that's why it is a detached credential collector. It has detached the credential collection process from the OAM Server.
• Now it is the DCC which creates OAP/NAP connections with OAM Server.

This end's the DCC Webgate Configuration with IIS 7.5/8.5 on Windows 2008 R2.

Enjoy :-)

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:

1. Port 5575 is the listening port used by the OAM Server. While creating webgate agent profile server connection port is mentioned.
2. 'httpd.worker'  is the OHS server process.
3. 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 :-)

[OID]: Disabling the User Account in OID

Let's disable the User Account in OID:

Note: We are considering that you have created a user account in OID. In case you have not follow  Creating User Account in OID

Follow the steps:

1) Before we lock/disable the user account, let's first access the protected resource.

• Access the url: http://<host:port>/resource

Note: I have logged in using username - clk, that i will be disabling in the OID Server.

2) Now let's log in to the OID Server:

• Log in to OID: http://<host:port>/odsm

•  Choose the OID Connection:

•  Provide the password & connect.

•  Now open the 'Data Browser' tab & expand the 'dn=com' tree.

•  Select the user you want to disable: I will be disabling 'clk' user

• Now we need to add an attribute that will disable the account. Open the 'Attributes' tab on the right pane.

• We need to add an optional attributes 'orclIsEnabled'.

       Note: Once you have added the 'orclIsEnabled' the attribute, than do 'Add Attributes'.

•  Default value of  'orclIsEnabled' attribute is 'ENABLED' but we need to set it as 'DISABLED'

Note: 

• Once you set the attribute value, click 'Apply' on the top right.
• Also remember that value of this field has to be set as 'DISABLED' even if you set as 'FALSE' it won't work. Account will be still accessible.

3) 

• Access the Protected Resource URL: http://<host:port>/resource
• Provide the credentials, here i will be using 'clk' as username that i have disabled. 
• And you see that when i tried to log in, it shows that 'User account is locked or            disabled'....

     Whooohoooh.... we have done it...

4) Now in case you need to enable the user account again, just set the attribute value:

    

    orclIsEnabled=ENABLED

Enjoy :-)

Webgate Caches: Understanding the Webgate Caching

We will be discussing the following:

1. When WebGate do the caching? At what time?
2. Why it is required to cache?
3. How it uses this cache?
4. How to tune this cache?
5. Webgate Caching Demo

1) When WebGate do the caching? At what time?

      Basically Webgate caches the information: 

• At the time of Authentication & 
• Authorization.

2) Why it is required to cache?

It is important to do the caching when we don't want the OAM Server to get overloaded.
And what does this means actually?

It means that if the webgate starts sending every similar request to the server, it is actually not adding any value. We are just asking the server to do the repetitive task.

But what if we can make these request a screening at webgate. What if webgate first looks to the request if found it has already served it than webgate takes the decision. As webgate already has the answer cached. And in case webgate doesn't have any info about the user request than it will make a trip to server asking for the same & hence caching it for future use.

3) So does it means that webgate caches the request for lifetime?

No, absolutely not. It do cache, but certainly it too have a life. And its life is depends on the configuration that we do while creating the Webgate Profile.

4) What all parameters do take care of caching in OAM?

    As discussed there are 2 types of caches:

• Authentication &
• Authorization

Parameters:

1. Authentication Cache Configurable Parameters:
1. Maximum Cache Elements
2. Cache Timeout
2. Authorization User Defined Parameters:
1. maxAuthorizationResultCacheElems
2. authorizationResultCacheTimeout  

5) Now the question comes that how these caches comes into picture? As in how webgate actually uses it?

Basically when user request comes to the webgate (obviously via a server where webgate is integrated), at that time a lookup is made to the cache. Now first look up is made to authentication cache for the required parameters & than look up is made to authorization cache.

Now the interesting point here is that in case cache miss hit occurs than a NAP/OAP call is made to the server, & the response is actually cached. So that next tym if the same request comes to the webgate before cache timeout than webgate has the capability to respond & do look up.

6) Tuning the webgate cache parameters:

As discussed at point (4), the parameters defined can be configured:

• Max cache elements: If we configure this parameter as -1, than webgate will not cache the elements.
• Cache Timeout: It tells after how much time will the cache drains out. If Max Cache Elements is configured as -1, than this parameter has no significance.
• maxAuthorizationResultCacheElems - This user defined parameter will set the max number of authorization cache elements that can be cached. 
• authorizationResultCacheTimeout - this is same a cache timeout but this is specifically for authorization cache. It has no impact on authentication cache. Default value is 15 seconds.
• If authorizationResultCacheTimeout is set to 0, Authorization Cache is disabled.

Reference Docs: http://docs.oracle.com/cd/E27559_01/doc.1112/e28552/oam.htm#ASPER490



Enjoy :-)