Oracle Access Manager 11g Academy: The Policy Model (Part 1)

Today I begin what will be a long series of posts covering Oracle Access Manager 11g (OAM 11g). I will be calling this series “OAM 11g academy”.

OAM 11g was released last summer and constitutes a major upgrade/rewrite of OAM, which happens to be one of the more popular Oracle IAM products. My goal with this series is to help everyone attempting to use and deploy the product at various stages by explaining major OAM 11g concepts, making architectural recommendations, pointing out potential pain points, and walking you through common yet non-trivial tasks such as setting up authentication to an external custom login form.

For the entire series content, see here: Oracle Access Manager Academy Index

OAM 11g Policy Model Index:

OAM 11g Policy Model Overview -- Continue below...

OAM 11g Policy Model Part 2: Application Domains and Host Identifiers

OAM 11g Policy Model Part 3: Resources

OAM 11g Policy Model Part 4: Resource Protection Levels and Excluded Resources

OAM 11g Policy Model

Today I would like to kick off this series by giving a general overview of the OAM 11g policy model. I define policy model to broadly mean the set of configurations that determine how OAM will handle a given request. I will be following up today’s post with 3-4 more posts on the

At a conceptual level this means the configurations that determine whether a given resource is protected or unprotected, how to authenticate a user that is trying to access a protected resource, whether a given resource is authorized to make a given request, what headers and cookies to generate in the process of authenticating and authorizing a request, etc.

At a lower level I define policy model to describe all the objects that make up OAM policy configurations and how they relate to each other. This includes objects like resources, ID stores, authentication schemes, and policies themselves.

Yes the Policy Model for OAM 11g is New

The OAM 11g policy model is a little different from the 10g model. At first glance the 11g policy model may seem complicated and some people may feel a little intimidated at the idea of having to learn a whole new policy model from scratch. However, I’m here to tell you today that:

1) The OAM 11g policy model is the most straight forward, easiest to understand model in the WAM space.

2) There is still quite a bit of overlap with the 10g model, so OAM 10g users don’t have to feel like you are starting over.

The documentation actually does a pretty good job of laying out the nuts and bolts of the policy model including the object hierarchy.

Policy Model Overview: http://download.oracle.com/docs/cd/E14571_01/doc.1111/e15478/sso.htm#BJFGDIAJ

What You Need to Know

As I mentioned, when you first look at this documentation, it can seem pretty daunting. However, if you cut through the clutter following the steps I’m about to describe you will find that creating OAM 11g policies is fairly straight forward; even more so than with OAM 10g.

In the next few posts, I’ll break down the OAM 11g policy model in detail; but to get you started here is what you need to know:

1) When a user makes a request the host part of the URL is transformed into a host identifier and combined with the rest of the URL into an internal representation of the resource being protected. The best way to think about the host identifier is a binding between the hostnames (real or virtual) and URI based resources. I’ll cover host identifiers in more detail in my next post.

2) This internal representation of the request is then compared to the URL patterns of the resources you have defined. If there is a match then policies will be evaluated based on that resource. I’ll write more about the URL patterns for resources in my next post.  The important thing to know for now is that a request will be matched to one and only one OAM resource.  The algorthim used to decide what resource the request will be matched to in the event that more than one URL pattern match the URL in the request is a "best match" algorithm. 

3) A resource can only be in no more than one authentication policy and no more than one authorization policy.

4) You choose how you want to authenticate users by changing the authentication scheme selected in an authentication policy.

5) You control what users can access what resources by creating constraints in authorization policies. Additionally, you can use OAM to generate HTTP headers containing information about the user or user session by defining responses in authorization policies. Responses can also be defined in authentication policies but most of the time you’ll want to define them in authorization policies. I’ll cover this in detail in a future post.

6) Anonymous access to resources can be granted by adding the resource to the application domain’s Public Resource authentication and authorization policies. The Public Resource authentication policy utilizes the anonymous authentication scheme and the Public Resource authorization policy simply contains no constraints. Both of these are setup by default in the application domain that is created when you register an agent.

That is really all there is to it. Define resources in OAM to broadly or narrowly match your real application resources. Add each resource to the appropriate authentication policy based on whether or not you want to require users to be authenticated when accessing those resources.

If you want to limit certain resources to certain user communities then define authorization policies with constraints that restrict access to those communities and put each resource in the appropriate policy. If you don’t care who can access what once your users are authenticated then just put all your resources in an authorization policy with no constraints.

The following are a couple additional details that may help round things out:

1) If a request fails to match up with any of the defined resources then a failure is returned by the OAM server. With 11g webgates this always means that the request will be blocked. With 10g webgates the behavior is controlled by the “denyOnNotProtected” setting. If set to true then the request will be blocked. If set to false, then anonymous access will be granted and the request will be let through the webgate.

2) If the request matches a resource but that resource is not in any authentication policy or not in any authorization policy, then the request will be blocked.

In my next post I will cover the topics of application domains, host identifiers, and resources in detail.  Until then, happy policy authoring!