Thursday, February 3, 2011

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

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!

9 comments:

  1. Great post! looking forward to the next one :)

    ReplyDelete
  2. You have provided me with a way to finally tentatively find my way into the world of OAM. Thanks for that - and please keep up this good work of yours.

    Kind regards,

    Lucas

    ReplyDelete
  3. Nice post, looking for how external custom login form can be used

    ReplyDelete
  4. Nagesh,

    I've been getting a lot of requests for help with using an external login form with OAM 11g.

    So, I just put up a post on the subject:

    http://fusionsecurity.blogspot.com/2011/02/external-custom-login-forms-with-oracle.html

    I hope it helps!

    --Brian

    ReplyDelete
  5. looking for how to protect the resource(web application) that is deployed on same weblogic server containg OAM 11g, but without OHS reverse proxy

    ReplyDelete
  6. Hi Brian

    Thanks for the detailed post on OAM 11g Policy model. It was really helpful.

    I had a question. I was reading document and figured out that OAM 11g does not support LDAP filter based authorization policy. I deployed OAM 11g and validated the same.

    Now If I want to limit access to a resource to a group of users, Do I have to add those users manually to the policy? Also if new user is created, I will have to make sure that I add that user in the authorization policy. Is there a better way to create policy in 11g?

    Thanks
    Kiran Thakkar

    ReplyDelete
  7. Kiran,

    OAM 11g has the concept of constraints (which I haven't covered yet in my policy model series) which can be based on individual users or LDAP groups.

    So, if you want to limit access based on group memberships that is easy to do in 11g. What you cannot (yet) do in 11g is base membership directly on user attribute values since you cannot directly do LDAP filter based authorization.

    If you have a requirement to do authorization based on attribute values then you should look at creating dynamic groups, either with OVD or your directory of choice.

    Good luck,

    Brian

    ReplyDelete
  8. Good post.

    Quick question... I am having a little trouble understanding the architecture with OHS/Apache and protected resource. For example, say I have a JEE 5 app running on serverA with URI http://www.app1.us:7001/myapp. I install OHS on serverA, configure it to listen to http://www.app1.us:80/myapp and add the OAM files to OHS. Now, I tell my users to access the application through the OHS URI http://www.app1.us:80/myapp. But a few users don't get the memo and continue to directly access the application through http://www.app1.us:7001/myapp. How is this resolved? Should the application be re-designed to parse for OAMAuthnCookie? Should a firewall rule be put in place to block the original URI and then the protected resource entry within OAM becomes http://www.app1.us:80/myapp? Any help would be greatly appreciated.

    ReplyDelete
  9. Matt,

    Good question. You do need to ensure that the request has really come through OHS/Apache with the webgate on it. There are a number of ways to accomplish this.

    I discuss the issue in some detail in this post: http://fusionsecurity.blogspot.com/2010/04/security-clarification-oam-identity.html

    ReplyDelete

Note: Only a member of this blog may post a comment.