Introduction

I recently worked with a customer who needed to do some OAM session manipulation via custom code in order to implement a complex use case. While the focus of this post is not to go into details about a specific implementation, I did want to share some advice on a very necessary building block needed to do “out of band” session manipulation: retrieving the OAM Session ID.

What is the Session ID (used for)?

OAM 11g supports the concept of a server-side session (unlike previous versions where the only session state was represented by a browser cookie) and this architecture allows for a far richer set of functionality, including the ability to manipulate the server-side session through the addition of attribute values that can be considered during the evaluation of an OAM policy. Each session stored in the server session store (shared across the cluster using Coherence) is identified by a unique GUID known as the Session ID – that’s the long number you see in the folllowing screenshot, taken from the OAM Admin Console:

The reason this identifier is useful, though, comes when you start to look at the API Docs for the OAM Access SDK, which is the component you’ll need to use in order to do things like session manipulation from custom code. Looking specifically at the UserSession class, you’ll note that several of the utility methods require that you pass the SessionID as argument; this is a mandatory step in order to obtain a reference to an existing session in order to manipulate it.

Just a clarification at this point. Please do not interpret this post as a blanket endorsement of writing a custom Access Client as the solution to any and all problems. As always, work with your chosen OAM architect to carefully weigh up the pro’s and cons and various options available, with a strong preference for using out-of-the-box functionality, before concluding that custom code is the best way to solve your particular problem.

Assuming we’ve complied with the above caveat, done the necessary homework and concluded that the custom Access Client solution is what we have to do, what we then need is a way to obtain the Session ID from an existing authenticated user session in order to pass it to our custom code.

Using Identity Assertion to obtain the Session ID

Step 1 here is (perhaps obviously) to ensure that we place a WebGate in front of our custom code in order to ensure that there is actually a session in place and that we can use an authorization policy response to transfer information to that code via headers (the usual OAM approach). Now, for a number of very good reasons, the Session ID (a sensitive piece of information that needs to be protected) is not available as a direct policy response, in the same way that the user id, profile attributes or session attributes would be. As is perhaps clear from reading the AccessSDK documentation, you can do a lot of harm with this SessionID in your hands and, as such, it behoves you as an organization to take appropriate steps to protect this data within your code and over your network.

Treat the SessionID, in other words, just as you would a password. Do not write it into log files, do not send it over network links in clear text and take the necessary precautions to ensure that headers sent from your web tier to your app tier cannot be tampered with or spoofed. All the usual rules regarding safe and secure identity propagation apply, in other words.

With caveats and good practice advice out of the way, let’s talk about how to get this magical nugget of info into your custom code. The answer is to enable Identity Propagation for the Authorization policy protecting the URL, as per the following screenshot.

Once you do this, you will find that a SAML assertion is sent from the WebGate to your app in a header called “OAM_IDENTITY_ASSERTION”. There’s a lot of info inside this assertion, but you’re looking for the following snippet within the XML body.

<saml:Assertion xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xs=”http://www.w3.org/2001/XMLSchema” Version=”2.0″ ID=”6714fd68-596c-4cfa-af61-91b43a5ecd2a” IssueInstant=”2015-10-23T09:34:23Z”>
<saml:Issuer>OAM User Assertion Issuer</saml:Issuer>
…..
<saml:AttributeStatement>
<saml:Attribute NameFormat=”urn:oasis:names:tc:SAML:2.0:attrname-format:uri” Name=”urn:oasis:names:tc:SAML:2.0:profiles:session:sessionId”>
<saml:AttributeValue xsi:type=”xs:string”>d8ccd738-522f-4700-a91c-fd630b70ff61|S+kAgs+tqO+Rblq6abFwllAo5J4=</saml:AttributeValue>
</saml:Attribute>
……
</saml:AttributeStatement>
</saml:Assertion>

Right there, in the bolded text, is your Session ID. Use it wisely – keep it secret, keep it safe.

All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission

INTRODUCTION

This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available.

People typically are introduced to Webgate tuning in one of two ways, either forced into it because of a crisis or actively preparing an environment to do some aggressive load testing.  Hopefully you are in the later group.  Unfortunately, there is still a lot of mystery behind tuning some of these Webgate parameters.  Creating a comprehensive article to cover all aspects of tuning is a real challenge.  That said, this article will be focused on what I feel are the most important tuning parameters; 1) Max Connections, including the relationship between Max Connections and Max Number of Connection, 2) the Failover Threshold, and 3) the AAA Timeout Threshold.  If you can grasp the concepts around these few important key parameters your success in getting better performance and stability out of the Webgates and Access Servers will greatly increase.

Quick Overview

Knowledge in this article is based on extensive experience in the field, discussions with Oracle Webgate developers, and of course invaluable peers.  As I already mentioned in the introduction I will break out the Webgate tuning into three areas to help make it a little easier to digest.   Each of the three parameters are not necessarily relate to each other or dependent, so you are free to jump to the section you are interested in.  However, I highly advise that you spend time reading the entire article before making any major tuning changes.  Below is a screenshot of an 11gR2PS3 (OAM 11.1.2.3.0) Webgate definition that highlights the parameters I will cover plus any associated field; all settings are R2PS3 default values.

Max Connections — Not so Literal

The Max Connections parameter can reap some big improvements in performance, but beware — increasing the value does not necessarily equate to increased performance and in fact can even have a negative impact. The official Oracle OAM 11g 11.1.2 Administration Guide says, “Max Connections is the maximum number of connections that a Webgate can establish with the Access Server.” This statement is a bit confusing and could lead you to believe that by applying Max Connections value X will only send X number of connections to the Access Server, but that is completely false.

I want to cover more detail on the Max Connection parameter, but first things first, we need to understand how connections work with web servers and how it relates to the Webgate module. To keep this simple I want to focus my examples using OHS (Oracle HTTP Server) especially since the majority of the audience use OHS. As a side note OHS is basically Apache from a fundamental level. Therefore, my explanations with OHS going forward will also apply to Apache. If you use a different 11g Webgate supported web server, how connections work can be different so please extrapolate this information and try to apply it to your web server environment.

Worker or Pre-Fork Mode

OHS will run in one of two modes, “Worker” or “Pre-Fork”. The default in OHS is Worker mode, but with Apache it can depend on how it was compiled though typical implementations use Worker mode.  Be sure to verify what mode you are running in. As far as Worker mode, it uses multiple child processes with several threads for each process. Each thread will handle one connection at a time.

Now, the thing that is important to understand here is that the Webgate module is actually instantiated by the child processes directly, rather than by the OHS parent process. Again focusing purely on the multi-threaded “Worker” mode, a number of directives within the web server configuration file control exactly how many child processes will be spawned based on the number of incoming requests. From a Webgate point of view, we must bear in mind that each of these child processes will open its own pool of connections to the Access Servers, as defined by the Max Connections setting in the Webgate profile.

As a working example, let us specify Max Connections as “12” and our web server is configured to spawn up to 20 child processes, the total number of connections from the web server as a whole to the OAM servers will thus be 12 Max Connections times 20 child processes for a total of 240 connections; (12 x 20 = 240). We should always consider this multiplicative effect in mind when defining “Max Connections”, since we don’t want to end up opening too many connections and risk overloading the Access Servers. In the sections that follow, this multiplicative effect will not be explicitly called out, but please remember that it still applies in every case. So let’s apply another example so we fully understand the ramification of both the Max Connection and OHS configuration settings and how they relate.

Take for example the default mpm_worker_module section from an OHS httpd.conf file; shown below. We see ThreadsPerChild is set to 25, MaxClients is 150, and StartServers equals 2. The MaxClients value basically limits the maximum number of threads that can be opened by OHS while StartServers says open up 2 child processes at start up. That means at start up we will immediately get 2 children times 25 threads for a total of 50 threads. We know that each child has X WebGate connections where X is defined by the Max Connection setting in the webgate profile.  So if our Max Connection is 12 we will immediately have a total of 24 connection (2 StartServers x 12 Max Connections = 24 Webgate connections).  As traffic increases, OHS/Apache will spawn more children and therefore more webgate connections until the MaxClients limit is reached.  With MaxClient set to 150 and ThreadsPerChild set to 25, we can expect somewhere between 6-8 children max (the extra are due to the spare threads portion of the algorithm).  With 12 connections per child this means a maximum of somewhere between 72 and 96 connections for our example OHS/Apache server.

<IfModule mpm_worker_module>
     StartServers         2
     MaxClients         150
            ServerLimit                      6
     ThreadsPerChild     25
     MinSpareThreads     25
     MaxSpareThreads     756
     MaxRequestsPerChild  0
     AcceptMutex fcntl
     LockFile
</IfModule>

If Max Connections is changed to 24 then the number of connections goes to 1,200 (25 ThreadsPerChild x 2 StartServers x 24 Max Connections = 1,200 Webgate connections). As the web server accepts greater loads it will open up additional threads as needed. Each thread that is opened spawns 25 new children. We can easily see how the Webgate connections can multiply to become hundreds or even thousands of connections from one OHS server to each Access Server. The only throttle is MaxClients, which limits the total number of threads OHS will open. And keep in mind a production environment will have several OHS servers so the load on the Access Servers can grow quite fast. It is important when tuning Max Connections to monitor the utilization of CPU and Memory, plus the TCP connections on each Access Server as you tweak Webgate Max Connections or even the OHS ThreadsPerChild and MaxClients values. It is also important to understand that the specific number of threads per process is governed by the setting “ThreadsPerChild”.  The take away for this lesson is that a few Max Connections can go a long way, but too much of a good thing can be bad. Remember Mom always knew best when she said everything in moderation.

Now if your web server is configured for Pre-Fork mode, be especially careful because each request to the web server is handled by a dedicated (i.e. single-threaded) child process.  It follows that the maximum number of child processes – and hence the total number of Access Server connections – can quickly grow to a very large number.  I am sure you are asking, so what is a good value for Max Connections?  As for a magical recommended number, besides calculating the total sum based on the Max Number of Connections from each primary Access Server (more on that in the next section), unfortunately there is no sweet spot.  The value needs to be determined based on experimenting with load tests and recording the results that can be compared to see what values reap the best performance.  No implementation is alike, and as many deployments I have seen I have equally seen as many different values.   Now before you decided on the Max Connections value, you need to read the next section.

Making the Connection to Max Connections

There is no pun in the connection between Max Connections and Max Number of Connections. In a nutshell, the value for the Max Connections parameter should be the sum of all the Max Number of Connections from each Primary Server. Take the following diagram as an example.

The value for Max Connections in the diagram is 12. If you add up the Max Number of Connections from each of the three Primary Servers it totals 12 (4+4+4=12).

Let’s take another example, but this time change OAM 3 primary Access Server to a secondary server, and also update the Max Number of Connections value for each OAM Server from 4 to 6.

The first thing I want to point out is that the secondary Access Server will not get requests from the Webgate until connections to any primary Access Server fall below the Failover Threshold; more on that later. Since we have two primary OAM servers with Max Number of Connections values of 6 each, the total Max Connections value for the Webgate would be 12 (6+6=12); it is pretty simple. Now that we understand how to get the value for Max Connections parameter, you maybe wondering about what value to even use for Max Number of Connections; 4, 6, 20, 100? Good question, and fortunately Chris Johnson wrote a great article on this very subject, “How many connections do I need from the WebGate to the OAM Server?”. Again, it must be called out that the number you define in the Webgate profile will be multiplied by the number of Web Server child processes to determine the actual number of connections – so a little can often go a long way!

Does each Max Number of Connections need to be Symmetrical?

So far in my examples I have made each OAM server Max Number of Connections the same or symmetrical, but you don’t necessarily have to do that. You can optionally add more connections to different primary servers if you want more requests to go to any specific server. This strategy is basically a type of load balancing using the Webgate Max Number of Connections configuration value instead of using an actual physical load balancer appliance; take the following diagram as an example.

Notice that OAM 1 primary server has 8 Max Number of Connections while OAM 2 and OAM 3 primary servers have 4 each. So the total Max Connections value would be 16 (8+4+4=16). In this particular configuration OAM 1 server would get double the number of connections from the Webgates as the other two primary OAM servers. One reason to do this would be that OAM 1 is a much larger server, more memory, etc. and can handle more traffic, or maybe OAM 1 is physically closer to the Webgate so it can process requests much faster. In reality even though this is an option, I have never really seen this in practice because normally all the servers have the equivalent sized hardware, are in the same network, and therefore there is no need to distribute more requests to any one server. That said, I did want to at least bring this up so you understand that there are options for various reasons if you so decide it makes sense.

The Skinny on Failover Threshold

The latest (At the time of this post) official 11g Access Manager documentation in section Table 16-3 Elements on Expanded 11g and 10g WebGate/Access Client Registration Pages says the Failover Threshold parameter is “Number representing the point when this Webgate opens connections to a Secondary OAM Server.” It also gives an example, if 30 were used as a value, and the number of connections to primary servers drops to 29, connections begin to open up to the secondary Access Server; the default value is 1. This description kind of gives an idea of what is happening, but no recommendations and some find it confusing. So I wanted to add some of my experience with recommendations.

1. First, the word “Failover” in the parameter name is exactly what it means. As connections are lost from each primary OAM server, the Webgate will then try to make up that connection by connecting to a secondary OAM server; hence the word “Failover”.  So a big note here, this setting only works if there are at least one or more secondary OAM servers defined in the Webgate profile. The parameter Failover Threshold will do nothing if there is no secondary OAM server defined.

2. Second, the word “Threshold” in the parameter name is talking about at what point do connections begin to go over to the secondary OAM server(s).   Based on the official documentation, which is correct, if the Failover Threshold is set to 6 where the Max Number of Connections is also set to 6, then as soon as the number of connections going from the Webgate to the OAM server drops below the Failover Threshold of 6, connections will start to be sent to the secondary OAM server(s).   If there are two secondary OAM servers, the first in the list will be the one getting all the connections. As soon as the first secondary OAM server fills up its Max Number of Connections, the second secondary OAM server will start getting connections. Are you following?

So the big question is what is the best setting? My recommendation is two fold.

1. If you DO have Secondary OAM Servers configured:
Set the Failover Threshold value equal to the Max Number of Connections only if you have at least one secondary OAM server. Take my examples above, if the OAM server Max Number of Connections is 4, then set the Failover Threshold to 4. The reason for this is that you engage all the processing power needed as connections drop from any one primary OAM server since the secondary OAM server will start picking up the slack. As soon as the primary server having connection problems corrects itself, the Webgate will start failing back to the primary OAM server and slowly drop the connections from the secondary server until all the Max Number of Connections are met.

2. If you DO NOT have Secondary OAM Servers configured:
If you decide not to configure any secondary OAM server, you can leave the Failover Threshold value to the default of 1 because it will never be used. Remember, Failover Threshold requires a secondary OAM server to be configured. In practice, most clients like to see all their hardware provide some value, which means keep them all working to get their money worth. So I will typically see all OAM servers configured as primary servers; there is nothing wrong with this. That said, I have also seen various configurations with a mix of primary and secondary servers in a criss cross fasion that is a bit more complicated, but certainly has merrits too depending on the situation.

If you follow either of the points above you should have a solid configuration.

AAA Timeout Threshold

The AAA Timeout Threshold parameter setting determines how long the Webgate will wait on a connection response before it gives up and attempts to request a new connection. For example let’s say the Webgate has a connection opened, and a request comes through to validate some credentials. This process normally should take a fraction of a second, but there could be all sorts of variables to make this request take much longer. If the wait for the response is longer than the AAA Timeout Threshold, it will abandon the connection for that request, toss it back in the pool, and open a new connection to try again.

For most of OAM’s life (prior to R2 PS3), the default value for AAA Timeout Threshold is “-1” (minus one). The -1 is a special value that tells the Webgate to use the operating systems TCP timeout, which could easily be 2 minutes or even more! I have seen actual cases in practice where something goes awry with some Access Server and while the Webgate tries to connect to the Access Server or get some response from it, the Webgate keeps trying for a long time because the AAA Timeout Threshold was set to the default -1. As each connection tries for a very long time, the Webgate begins to get into a state that gives impression it is down when in reality the Webgate is doing what it was told, and that was to wait for a long time before retrying. When all the connections start doing this we have an OAM zombie apocalypse problem. Zombies are bad, but we can try to avoid this behavior by shortening that wait time.

The recommended value is any where from 5 to 10; this is in seconds. For example if you set the AAA Timeout Threshold to 5, the Webgate will open its connection, send its request, and expect to get a response back in say 5 seconds. If not, then it opens a new connection and tries again while the old connection is just freed up and tossed back into the pool. If the value is set to be shorter, like say 1 second, an authentication or authorization request could possibly take longer because the Access Server is waiting for a long LDAP search to be returned, and therefore send us into a whirling tail spin because you would never get your request completed since there is not enough time allotted for such an LDAP search. So we have found that a 5 – 10 seconds value seems to be a fair and balanced approach.  In R2 PS3 the default is now 5 seconds, which is reasonable.

User-Defined Webgate Parameters

One worthy parameter to mention that many may not know about is “client_request_retry_attempts”. A description of this parameter can be found in the latest (at the time of this article) in the official Oracle online document https://docs.oracle.com/cd/E40329_01/admin.1112/e27239/register.htm#AIAAG5856. The official description says; “WebGate-to-OAM Server timeout threshold specifies how long (in seconds) the WebGate waits for the OAM Server before it considers it unreachable and attempts the request on a new connection.” This at first seems similar to the AAA Timeout Threshold, but the difference is that this parameter is more about how many times the WebGate will retry its request before attempting the secondary server.

So if the AAA Timeout Threshold is set to 5 seconds, it will time out that connection after 5 seconds if there is no response, but using the client_request_retry_attempts tells the Webgate how any times it will attempt to retry that connection. If the value is set to 2, then the Webgate will wait 5 seconds (Assuming the AAA Timeout Threshold is set to 5), and if it times out it will try up to 2 times before timing out the connection. This configuration may be useful if you think a network connectivity between the Webgates and the Access Servers are not stable and you want the Webgate to at least try more than once before closing its connection.

Summary

I realize there are a lot of details in this blog, but it is all very useful and you may need to read each section carefully to absorb the data.  I can say that tuning the Webgate profile is a very important part of an OAM deployment and can save you lots of late nights worrying about performance or outages.  Good luck and be sure to load test your configurations before going live.

All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission

From Brian:  I'm adding this excellent post by Matt to our OAM 11g Academy series. To view the first post in the series which will be updated throughout to contain links to the entire series, click here: http://fusionsecurity.blogspot.com/2011/02/oracle-access-manager-11g-academy.html 
 OAM 11g has the ability to do Windows Native Authentication to give a Windows client desktop SSO to the OAM-protected application. This was possible in OAM 10g as well, but it required an IIS server to do the heavy lifting of getting the Kerberos ticket and authenticating the user. In 11g, Oracle does not require IIS to accomplish desktop SSO. WebLogic also had this capability by using its SPNEGO Identity Asserter, but this approach gives one SSO to any other OAM-protected application as well. The documentation is in chapter 7 of the Integration Guide.

• Select Tools, Internet Options.
• Select the Security tab.
• Ensure that your WebGate-protected OHS site is in the list of trusted “Sites”
• Select Local intranet and click Custom Level....
• In the Security Settings dialog box, scroll to the User Authentication section.
• Select “Automatic logon only in Intranet zone”.
• Click OK.
• Select the Advanced tab.
• Scroll to the Security section.
• Make sure that Enable Integrated Windows Authentication option is checked and click OK.
• If this option was not checked, restart the client.

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!

From Brian:  I'm adding this excellent post by Matt to our OAM 11g Academy series. To view the first post in the series which will be updated throughout to contain links to the entire series, click here: http://fusionsecurity.blogspot.com/201...

This is the 2nd post in my OAM 11g Academy series. To view the first post in the series which will be updated throughout to contain links to the entire series, click here: http://fusionsecurity.blogspot.com/2011/02/oracle-access-manager-11g-academy.html

While my intent was to make the first few posts on the topic of the OAM 11g policy model, I’ve been getting a ton of requests for help on how to do form based logins using a custom, externally hosted login form with OAM 11g. So, I’ve decided to take a short break from the policy model to tackle that topic.

It is very common for customers to want to redirect users to their own custom login form to authenticate into OAM. There are actually several sub-scenarios to this use case that I will address in a broader post about authentication in OAM 11g, but the thing I want to focus on today is the case of redirecting the user to a login page or application that is “externally” hosted outside of the OAM managed server.

The idea is that when it is time to authenticate the user, the user will be redirected to your own page or application that can be built using whatever technology you like including JSP pages, ASP/.net, perl, PHP, etc.. You can render the form to look like whatever you want and even potentially do some pre-processing of the users submission (POST) before sending the credentials along to OAM.

The information on how to do this can be divided into two sections: the authentication scheme configuration and the login.jsp itself.
The Authentication Scheme

You want to create a new authentication scheme that you will use in your authentication policy. You can give it whatever name you want.

The settings should be as follows, this is basically what is in the 11g documentation on authentication schemes that can be found here except that there is a bug in the documentation that puts a “/” in the front of the challenge URL. You do not want the “/”.

Challenge Method: FORM

Challenge Redirect URL: /oam/server/ (note that you do not want to change this from the value used for the default OAM form)

Authentication Module: LDAP (or whatever you had before for the default OAM form scheme)

Challenge URL: The full URL starting with http or https of your login form which can be hosted wherever you like

Context Type: external

The Process

When you set up a form based authentication scheme with challenge type external, the webgate redirects the user first to the obrareq.cgi url which then redirect the user to the login page specified in the authentication scheme “challenge url”.

On the redirect to the login page it adds two things to the query string: request_id and redirect_url as in the following query string ?request_id=5092769420627701289&redirect_url=http%3A%2F%2Fateam-hq61.us.oracle.com%3A7777%2Fscripta%2Fprintenv

The Form/App

Again, the form or login application can be written using any technology you care to use to process the redirect from the user and render the HTML. The following is what you need to know about what is required in the login form you create. Beyond these three items, the login page can take whatever shape you’d like it to. These items are also documented in the “About custom login pages” section of the doc:

• You need to post back to the OAM server to the URI: “/oam/server/auth_cred_submit”. Note that in my sample, I’m on the same machine so I just have the URI and not the full URL, but if you are on a different server you’ll need the full URL.
• You need to post variables “username” and “password”
• You need code that will grab the request_id off of the query string and post it (as a hidden form variable) as well

Here is code from a sample login.jsp page that works as a external login form for OAM 11g.

Sample login.jsp:

I wanted to make a quick post to primarily let people know where to find bundle patches for Oracle Access Manager (OAM) and Oracle Identity Manager (OIM) patches. While I’m at it I will also cover where to find the major releases and patch sets (which are basically minor or mid-level releases) for OAM, OIM, and other Oracle IAM products.

While not entirely specific to OAM 11g, I’ll be including this post in my OAM 11g Academy Series. To view the first post in the series which will be updated throughout to contain links to the entire series, click here.

For those of you who are new to working with OAM and OIM (or Oracle products in general), patches for OAM and OIM are released in semi-regular bundles called bundle patches. These patches are easily applied using the OPATCH utility which I discussed in this previous post. For both OAM and OIM the bundle patches are cumulative. However, this is not necessarily the case for all Fusion Middleware Products or even all IAM products from Oracle.

For OAM, there is a nice article on support.oracle.com that includes the entire bundle patch history for OAM 11g, 10.3 and 10.2 with links to each patch. The article is updated with the release of every new bundle patch. So, it’s basically one stop shopping for what you need to know about patching OAM. The article number is 736372.1 and can be found by searching support.oracle.com or following this link.

For OIM, there doesn’t seem to be an exactly equivalent article but there does seem to be one or two articles per major release or patch set on bundle patches for that release which do appear to be getting updated as new patch sets come out. This includes:
Article 1247564.1 includes a list of patch sets for OIM 11g that includes the issues fixed in each patch set.

Article 1275998.1 is another article containing patch sets for OIM 11g that cross references the bundle patch numbers with the actual patch numbers. There are also links on this page to equivalent articles for OIM 9.x releases.

As for major releases and patch sets (a misleading name, think of them as minor to mid-level releases), the place to go is the following page on OTN: http://www.oracle.com/technetwork/middleware/id-mgmt/downloads/index.html

That page will take you to the appropriate page for 11g packages and the older 10g packages.

Hi everyone, this is my first posting so I wanted to first introduce myself. My name is Vinay Kalra and I'm also part of the A-team at Oracle. I came to Oracle in 2005 as part of the Oblix acquisition that brought with it Oracle Access Manager (OAM).Fr...

This is the 3rd post in my series going over the OAM 11g policy model and another post in the broader OAM 11g Academy series. To view the first post on the OAM 11g policy model, as well as the index to the entire OAM 11g Academy series, click here: http://fusionsecurity.blogspot.com/2011/02/oracle-access-manager-11g-academy.html.

In this post I’ll cover the OAM 11g concept of resources. The documentation does a reasonably thorough job of covering resources. Again though, in the interest of cutting through the clutter, I’ve compiled a list what I think are the most important points in understanding resources and OAM 11g:

• A resource is composed of a host identifier + URI expression. When a user makes a request it is normalized by OAM into an internal representation of the request consisting of a host identifier and URI; the query string is discarded. This internal representation of the request is then compared to the host ID + URL patterns of the resources you have defined. If there is a match then policies will be evaluated based on that resource.

• OAM 11g does not consider the query string when trying to match a request up to a resource

• 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.

• A request will be matched to one and only one OAM resource.

• The algorithm 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. We’ll go into more detail on this later in the post.

• A resource can be in no more than one authentication policy and no more than one authorization policy.

Defining Resources and Understanding the OAM Matching Algorithm 

As I mentioned earlier, I think the OAM documentation on resources does a pretty good job but let me expand on it a little bit and try to clarify a few things.

A resource is composed of three parts: the resource type (this posts only covers HTTP type resources), a host identifier, and a resource URL. The resource URL mirrors the URI portion of the request URL which is the part of the URL after the server name (including the / following the server name) and before the query string (the query string is the ?). I wish they had named this the resource URI but what can you do. The resource URL can contain two special character sequences with special meaning ‘…’ and ‘*’. We’ll cover these special characters in a bit.

When you create a resource you do so within an Application Domain. That resource can then become a part of one authentication and one authorization policy inside that Application Domain. Even though this resource is scoped to an Application Domain, you cannot define the same resource (host identifier + resource URL) in another Application Domain.

Now we’ll finally get to the special characters ‘…’ and ‘*’. * (asterisk) can only be used in the last level of the “path” and by this we mean after the final / in the URI. It can be used in two ways: as the last character in the resource URL or preceding a file extension (.jsp, .html, .gif etc). 

The * (Asterisk)

When * is used as the last character in the resource URL it matches any string of 0 or more characters that does not contain a ‘/’ (slash). In other words * when used in this way matches any resource that does not go another level deep. 

For example, the resource /foo/* will match /foo/index.html and /foo/helloworld but not /foo/bar/hello.jsp.

The other use of the * is preceding a file extension. Let’s say you want to make all the images in a particular webapp open to anonymous access so that they can be linked to from other apps without requiring authentication to OAM. Just create a /app/*.gif resource and throw it into public authentication and authorization policies. 

The … (Ellipsis)

The three periods (called an ellipsis) matches any sequence of one or more characters that starts and ends with the forward slash character ‘/’. It is used for creating resource objects that cover multiple “directory” or “realm” levels. The ellipsis can be used only once in a resource URL.

Now the documentation says that the ellipsis matches any sequence of one or more characters that starts and ends with the forward slash but my observation is that it also matches a single forward slash. So, /…/ will match ‘/’. ‘/index.html’, and ‘/foo/bar/help.jsp’

Most of the time you will be adding an asterisk together will the ellipsis. To create resources that match every request under a given context root (directory).

So, let’s say you have an application that handles procurement for your company that is deployed under the context root /procurement. You might create a resource /procurement/…/* that will match all requests under ‘/procurement/’.

Best Match

So, let’s say you have multiple resources that might match a given request. An example of this would be having ‘/…/*’, ‘/somedir/*’, and ‘/somedir/*.jsp’ defined as resources and having request scome in for ‘/somedir/index.html’ and ‘/somedir/hello.jsp’. 

OAM uses a “best fit” algorithm to determine which resource the request will be matched with; which is to say, it will pick the resource that contains the most amount of specific characters that match the URI of the request or put another way, the resource that has the least amount of characters in the request matching a wild card expression in the resource.

In our example /somedir/index.html will match with ‘/somedir/*’ and /somedir/hello.jsp will match with ‘/somedir/*.jsp’.

If this confuses you or if you are debugging a policy where you think the request is matching a resource different from the one you expect you can see what resource a request was matched with in 2 ways:

1. Look at the logs. Filter at the notification level for the word “protected”. Look for the “Called isResourceProtected ()” message that contains the request you want to examine. Then look for the next “Returning from isResourceProtected()” message which contains the resource your request was matched with.
2. You can configure a response that will create a header containing the resource (host ID and resource URL) your request was matched with. You can then examine this header in your application code. We’ll talk more about responses in a future post but the value for this response is $request.policy_res

Connecting to an LDAP ID store in OAM 11g over SSL (LDAPS) is a common scenario that many customers may need to implement. Unfortunately the documentation on this subject is scant and can be misleading. So as part of the OAM 11g Academy series, I'd l...

While this post is mostly a link to an external blog, it contains good information, so I’ll be including this post in my OAM 11g Academy Series. To view the first post in the series which will be updated throughout to contain links to the entire series, click here: http://fusionsecurity.blogspot.com/2011/02/oracle-access-manager-11g-academy.html

Our friend from Europe, Olaf Heimburger, has written a couple good blog posts on integrating OAM 11g with Oracle Forms. In the 2nd post he’s thrown in a little about OAM/ADF integration (though there is more to cover on that subject).

His posts can be found here:

https://blogs.oracle.com/olaf/entry/ofm_11g_implementing_oam_sso_w
https://blogs.oracle.com/olaf/entry/ofm_11g_oam_sso_for_forms_and

Old links that no longer work for some reason:
http://blogs.oracle.com/olaf/2011/01/ofm_11g_implementing_oam_sso_w.html
http://blogs.oracle.com/olaf/2011/02/ofm_11g_oam_sso_for_forms_and.html

This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available. In the last post here we pointed to Olaf's blog on integrating...

This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available.

Our compatriot Eric Leach over at the Oracle Access Management Blog wrote a post describing how SSO works in OAM 11g. It's a great post and fills in all sorts of details about the cookies used, how they're named and how all of the parts fit together. OAM 11g supports a few different PEPs - OSSO, OAM 10g and OAM 11g and Eric discusses them all.

but...

I find a pretty picture much more understandable than a great big blob of text. Part of it is that I'm more of a visual person and part of it is that I tend to get distracted easily. Plus if you're already familiar with OSSO or OAM 10g you probably already know what their cookies look like. So for the purposes of this post I'm only going talk about OAM 11g Server and the 11g WebGate cookies when you do an "HTML form" style login.

Basically if you want the contents Eric's post in pretty pictures and simplified down to include only the 11g cookies then this post is for you!

Here's a very simple diagram of the communication between the user, one OAM Server, one WebGate and one Application:

Note: In this diagram I've separated out the WebGate and the Application, though in reality the WebGate is plugged into the OHS Server and the app could be something as simple as a .CGI running in the same server. I've also shown the user talking directly to the OAM Server; in the real world this interaction would likely be through an OHS server with mod_wl installed.

Before we jump into the actual flows here's a little UML-ish sequence diagram for those of you that love those sorts of things:

And the OAM docs have a GREAT diagram that covers the flow:

When the user first attempts to access a protected resource the WebGate will detect that the resource is protected and that the user needs to be redirected to the OAM Server to login. The WebGate stores some information about the user's request, generates a cookie as a key to this context and sends an HTTP response with this cookie and the URL of the OAM Server. Here's a sample:

GET /protected/ HTTP/1.1
Host: idm11g.oracledemo.com
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.18) Gecko/2010021717 Oracle/3.0.18-1.0.1.el5_4 Firefox/3.0.18
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.1 302 Found
Date: Sun, 10 Apr 2011 21:39:34 GMT
Server: Oracle-Application-Server-11g
Location: https://login.oracledemo.com/oam/server/obrareq.cgi?encquery%3DvAdYBjjl2VsVKd4BUocWvKLrTgh7O%2FulOsfaTcOtj%2FHCW0jI0WaKRY%2BUklaoED8x6IQ%2FtnktpR%2FNN2NvsLZJb3wTyUomlOxQgqX59aRla2LTQUIBsbO4Tw5PlFFsgDYdWoUUAA6HHTU4P1ZyloMzcbqn4mtXK6t5CAbOvEuB787m0VKOCPhvaO5OEibx5MEYtW1P0b1nqOeAlMUQdA6dg7BW8PbjgI7Ek3Esy4yJJN2EUBw90%2BjAJzLgQMUxtd%2FOc%2B6q60WFnZEMyRlmJW7moeoyPbMnookrb22WEd8pTsQ%3D%20agentid%3Didm11g%20ver%3D1
Content-Length: 608
Content-Type: text/html; charset=iso-8859-1
Set-Cookie: OAMAuthnCookie_idm11g.oracledemo.com:80=loggedoutcontinue;httponly; path=/;
Set-Cookie: OAMRequestContext_idm11g.oracledemo.com:80_316f33=1o3lYFHrBi/OSAW5bGkEgA==; Expires=Sun, 10-Apr-2011 21:44:34 GMT; path=/;
Connection: close

If you look in the HTTP response above you'll see 2 Set-Cookie headers - one deleting OAMAuthnCookie_something (well setting it to loggedoutcontinue) and another named OAMRequestContext_something with a short key. Don't worry about the former for the moment; the latter is how the WebGate can get back to the original request later.

The browser then follows the redirect and loads obrareq.cgi from the OAM Server. Despite the name obrareq.cgi isn't a CGI. The name is historical and we kept it for a few reasons, none of which really matter for this discussion.

When the user requests obrareq.cgi the server responds with another redirect - this time to the HTML login form defined in the Authentication Scheme. Here's my Authentication Scheme configuration:

and here's the HTTP transaction when the browser requests obrar.cgi:

GET /oam/server/obrareq.cgi?encquery%3DvAdYBjjl2VsVKd4BUocWvKLrTgh7O%2FulOsfaTcOtj%2FHCW0jI0WaKRY%2BUklaoED8x6IQ%2FtnktpR%2FNN2NvsLZJb3wTyUomlOxQgqX59aRla2LTQUIBsbO4Tw5PlFFsgDYdWoUUAA6HHTU4P1ZyloMzcbqn4mtXK6t5CAbOvEuB787m0VKOCPhvaO5OEibx5MEYtW1P0b1nqOeAlMUQdA6dg7BW8PbjgI7Ek3Esy4yJJN2EUBw90%2BjAJzLgQMUxtd%2FOc%2B6q60WFnZEMyRlmJW7moeoyPbMnookrb22WEd8pTsQ%3D%20agentid%3Didm11g%20ver%3D1 HTTP/1.1
Host: login.oracledemo.com
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.18) Gecko/2010021717 Oracle/3.0.18-1.0.1.el5_4 Firefox/3.0.18
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.1 302 Moved Temporarily
Date: Sun, 10 Apr 2011 21:39:34 GMT
Location: https://login.oracledemo.com/oam/pages/login.jsp?request_id=8909287934039423969
X-ORACLE-DMS-ECID: 11d1def534ea1be0:-4189cb25:12f40a0ec71:-8000-000000000000169c
X-Powered-By: Servlet/2.5 JSP/2.1
Connection: close
Transfer-Encoding: chunked
Content-Type: text/plain; charset=UTF-8

Notice the "?request_id=" and a key? When the user requests obrar.cgi the OAM Server squirrels away the request information and generates a short identifier to remember the user's request. The value of request_id is how the OAM Server gets back to the original request information when the user POSTs their credentials.

Next, the user loads the login page (/oam/pages/login.jsp in this example).

GET /oam/pages/login.jsp?request_id=8909287934039423969 HTTP/1.1
Host: login.oracledemo.com
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.18) Gecko/2010021717 Oracle/3.0.18-1.0.1.el5_4 Firefox/3.0.18
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.1 200 OK
Date: Sun, 10 Apr 2011 21:39:34 GMT
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 3201
Content-Type: text/html; charset=UTF-8
Expires: 0
X-ORACLE-DMS-ECID: 11d1def534ea1be0:-4189cb25:12f40a0ec71:-8000-000000000000169e
X-Powered-By: Servlet/2.5 JSP/2.1
Connection: close

Finally! an HTTP 200 and we're done following redirects for a moment. This is the point where the user sees a login page. In this example I configured my Authentication Scheme to use the default JSP login page included with OAM. I'm sure you've seen it before, but that login page looks like this:

OK, so the user enters the username and password and hits the Login button. The browser does an HTTP POST to /oam/server/auth_cred_submit. Like so:

POST /oam/server/auth_cred_submit HTTP/1.1
Host: login.oracledemo.com
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.18) Gecko/2010021717 Oracle/3.0.18-1.0.1.el5_4 Firefox/3.0.18
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://login.oracledemo.com/oam/pages/login.jsp?request_id=8909287934039423969
Content-Type: application/x-www-form-urlencoded
Content-Length: 66
username=testuser&password=ABcd1234&request_id=8909287934039423969

HTTP/1.1 302 Moved Temporarily
Date: Sun, 10 Apr 2011 21:39:41 GMT
Location: https://idm11g.oracledemo.com/obrar.cgi?encreply=aHRPbw8cp0LjIHx9Dd6DaT1kcHzmbIUudciQui%2F7lC52miYo77nRNh8JtH1UKeJ5O%2B12QyAcNlEES0TFZW7zQ%2FtCnh9PKFD%2B1y%2BGLYsEbnfHrsnqFmT4R%2F15b8kGdSyUP5TatLW6X4oAc9B2n9qPF3YBPlwHK7rRXMmhKleJa6X%2FjSWB%2Ff3YeWz1xrGidkvUXekC75Kldmu%2FL6O9jgbxk0tksCTjumZINMFOREUjrBFdCIGNDJlKiXeqBPMMccQXp5gg%2Fh5gT2s7wycJeAgyNxSH75%2FiYb9fC4tlo3aNB8bQ0ExpUSx8%2BTdOTf%2B1CpCv8Ue%2BESOoxEJYCVeQ248Omjmj%2B2UML0A%2F3KvWZjSHJY%2FTaleo3mzVG64lbdJGGsp8cXpbwK6MNZEtS6aDPdq4rgmNNAhnJ8bvmIUrlm3FfFp66anpYkvSUCORoaN991YwgZ5tOQ5p%2BZqN6O9qL5T7XUS7HWPwixEy0zH1CHDrQzmf0GaN9x4BfY3EdyGVQIh04Sf2V3Tf3r3cF4aW6xJuNMiu24kZYJ3tF8%2BjmdAmb3GoXtwOrCOUcSc%2FKV9%2F4oIBoZH6b5GW047VF5NGgNfM17I0J%2Fe1epQE2%2Bs0iLXlBu0IhFkaYiyDI2dl8CXohgeoTjOD74EeZFBcDMZHAYEVNjfZg2BuTNn7qaUTJkUztbM%3D
X-ORACLE-DMS-ECID: 11d1def534ea1be0:-4189cb25:12f40a0ec71:-8000-00000000000016aa
X-Powered-By: Servlet/2.5 JSP/2.1
Set-Cookie: OAM_ID=PvUkA907xd81Jv/P53npTW0JOSDTacc3jdGiL3tMB87z/RfZP91Bh2dQmM8v71rQTCZnJ1isOaQeJw8dSjfo7kXMFA8URsmL9uiszpOQYEH7SuvHVr1IjVRY3pPAlYhUrfLwEW5lvKMY9MF3KYTzvfuUJLMKZb0sc70KxdmXcnJrAFOSVMALhUEaUVOTZVI3aQCqEVmdnkh0QlSBkz9tsqxE0/VTacEnhPg2DlPxC9uKnElAsByo+8wczYlBemiyMR9g0BWasN+uR4TMo9pLtky/B0TmA43uOQuFvItW6twFJH3wSu6XofKo/Cy4bS0i; path=/; HttpOnly
Connection: close
Transfer-Encoding: chunked
Content-Type: text/plain; charset=UTF-8

The OAM Server validates the username and password ("testuser" and "ABcd1234" in this case) and since they're correct it generates an OAM_ID cookie. This is the first cookie we've seen so far that identifies the user! If you look carefully you'll notice a couple of interesting things about the cookie: The first is that it doesn't have a domain= setting; as a result the OAM_ID cookie will only be sent by the browser to the OAM Server; no WebGates will ever see the OAM_ID cookie. The second interesting thing to notice is that the cookie is marked "HttpOnly"; the HttpOnly marker tells the browser that the cookie should NOT be accessible to Javascript or browser plug-ins.
(note: in an earlier version of this post I accidentally said "host=" instead of "domain=". My apologies for the error!)

The OAM Server redirects the user back to obrar.cgi (this time on the application) with encreply= and a big long encrypted string. The encreply that the OAM Server includes in that redirect contains enough information to allow the WebGate to pick up the user's session from the OAM Server. And so it does:

GET /obrar.cgi?encreply=aHRPbw8cp0LjIHx9Dd6DaT1kcHzmbIUudciQui%2F7lC52miYo77nRNh8JtH1UKeJ5O%2B12QyAcNlEES0TFZW7zQ%2FtCnh9PKFD%2B1y%2BGLYsEbnfHrsnqFmT4R%2F15b8kGdSyUP5TatLW6X4oAc9B2n9qPF3YBPlwHK7rRXMmhKleJa6X%2FjSWB%2Ff3YeWz1xrGidkvUXekC75Kldmu%2FL6O9jgbxk0tksCTjumZINMFOREUjrBFdCIGNDJlKiXeqBPMMccQXp5gg%2Fh5gT2s7wycJeAgyNxSH75%2FiYb9fC4tlo3aNB8bQ0ExpUSx8%2BTdOTf%2B1CpCv8Ue%2BESOoxEJYCVeQ248Omjmj%2B2UML0A%2F3KvWZjSHJY%2FTaleo3mzVG64lbdJGGsp8cXpbwK6MNZEtS6aDPdq4rgmNNAhnJ8bvmIUrlm3FfFp66anpYkvSUCORoaN991YwgZ5tOQ5p%2BZqN6O9qL5T7XUS7HWPwixEy0zH1CHDrQzmf0GaN9x4BfY3EdyGVQIh04Sf2V3Tf3r3cF4aW6xJuNMiu24kZYJ3tF8%2BjmdAmb3GoXtwOrCOUcSc%2FKV9%2F4oIBoZH6b5GW047VF5NGgNfM17I0J%2Fe1epQE2%2Bs0iLXlBu0IhFkaYiyDI2dl8CXohgeoTjOD74EeZFBcDMZHAYEVNjfZg2BuTNn7qaUTJkUztbM%3D HTTP/1.1
Host: idm11g.oracledemo.com
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.18) Gecko/2010021717 Oracle/3.0.18-1.0.1.el5_4 Firefox/3.0.18
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://login.oracledemo.com/oam/pages/login.jsp?request_id=8909287934039423969
Cookie: OAMAuthnCookie_idm11g.oracledemo.com:80=loggedoutcontinue; OAMRequestContext_idm11g.oracledemo.com:80_316f33=1o3lYFHrBi/OSAW5bGkEgA==

HTTP/1.1 302 Found
Date: Sun, 10 Apr 2011 21:39:41 GMT
Server: Oracle-Application-Server-11g
Location: /protected/
Content-Length: 209
Content-Type: text/html; charset=iso-8859-1
Set-Cookie: OAMRequestContext_idm11g.oracledemo.com:80_316f33=; Expires=Thursday, 01-Jan-1970 01:00:00 GMT; path=/;
Set-Cookie: OAMAuthnCookie_idm11g.oracledemo.com:80=BSMcTDP6bI93Nv7mrpH77ESezwe9OJJEvlB3Y7Bir3%2FrcwvB8j8xZj2tc0mzQKUJYfNEjnRB%2BJWg3EQw%2BAei51dq7IhVJQ4xZhfv9eKqB1f0BMwc%2BOMt9ADJ7wZ47rGqEp85DYTRIeXPE6wMSJMkRFIvEzh2zKmeZoBv7x2G2DsepKXwAsgv2OZqmXvISu4gzDweUbcY6N8%2B4KuYAqCd1FAHO6aMKlj6ak05cdAVtzGXBcc3y%2FdRW1Yhjer9oZEBBcW73e9uhrfwOq6lZHE0BHoPZT5YWrXQRUJH3VBxj7gPAMQASwQh6wUyvvC%2BN4Zm;httponly; path=/;
Connection: close

This is the second cookie we've seen that identifies the user. Again, this cookie is host-specific and HttpOnly. There's another interesting thing about the cookie - notice the cookie name "OAMAuthnCookie_idm11g.oracledemo.com:80"? The WebGate figures out the cookie name automatically.

The user follows the redirect back to the original resource - /protected/.

GET /protected/ HTTP/1.1
Host: idm11g.oracledemo.com
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.18) Gecko/2010021717 Oracle/3.0.18-1.0.1.el5_4 Firefox/3.0.18
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://login.oracledemo.com/oam/pages/login.jsp?request_id=8909287934039423969
Cookie: OAMAuthnCookie_idm11g.oracledemo.com:80=bQ%2Bx9MCKyEjON3nOt5d7niWgbSEksG4qCEPaGF82blgf76HBAgmnEy3gkGoPzTBs8Ac1zTBNSnvHS8EmubYuZR0I4spgrchEtuuKdKJHPkWXQg9S1RRoycAys%2F8GDa6rRbvWJNRFc11yfK0X3g3Buxb6MvpDmsEGraleqKtdBSjtRG1PS8zl4Mijd7Tu1a3NFMgONgdoHKnoNyF3T13HjFbILIvLVuTdjE6t9EyomX4XXijXxqUZtTrZB%2BjRzy3jVLUeKKHhcNn7CTZrKhMJYtDVd8Z4d34vyyGgE%2BlJd%2BdkKGQr1sstpfpVVlyivvo4

HTTP/1.1 200 OK
Date: Sun, 10 Apr 2011 21:39:41 GMT
Server: Oracle-Application-Server-11g
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=ISO-8859-1
Content-Language: en
Connection: close
Transfer-Encoding: chunked

So a quick summary:

• The OAM Server gets and sets a cookie named OAM_ID.
• Each WebGate gets and sets a cookie named OAMAuthnCookie_ + the host name and port.

Eric gave a couple of other details about the OAMAuthnCookie -

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:

Eric also mentioned that the 11g OAMAuthnCookie is encrypted with a key that is specific to the Webgate that issued the cookie. That means that if someone somehow compromises one web server and gets a copy of the OAMAuthnCookie for that server it isn't useable on any other web server and WebGate.

One other note: Because the OAMAuthnCookie is a "per host" cookie and the only communication channel in the redirects is the obrar.cgi URL single sign on works across domain names. So in my case I have both the OAM Server and the application in .oracledemo.com, but I could just as easily have them in two completely different domains. Like oracle.com and oracleateam.com.

In the next post I'm going to talk about how logout works so stay tuned!

This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available. Yesterday's post on OAM 11g SSO and Cookies discussed how login...

This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available. In my last two posts on OAM I discussed OAM 11g login and cook...

This is the 4th post in my series going over the OAM 11g policy model and another post in the broader OAM 11g Academy series. To view the first post on the OAM 11g policy model, as well as the index to the entire OAM 11g Academy series, click here: http://fusionsecurity.blogspot.com/2011/02/oracle-access-manager-11g-academy.html.
 
OAM 11g PS1 (11.1.1.5) introduced two important enhancements related to resource definitions in the policy model:

1. The ability to optionally include query strings as part of resource definitions.

1. The designation of a protection level for a resource and the completely new concept of excluded resources that go with it.

In 11.1.1.3, resources could not include query strings and OAM essentially ignored query strings in its policy evaluation. In 11.1.1.5, there is a specific field for query strings in the resource definition screen of the OAM console that you can optionally make use of. We’ll come back to this in a future post.

For now I’ll point you at the documentation but also point out that you don’t have to define query strings if you don’t want to. Incoming request for resources that include query strings will still resolve to resources that have blank query string parameters. For example, if you define a resource /foo/bar.jsp and leave the query string field blank, it will still match requests for /foo/bar.jsp?x=y and the like.

Protection Levels
With that out of the way, I’d like to talk about the 2nd important enhancement to resource definitions in OAM 11g and that is the notion of protection level and in particular the designation of excluded resources.

When you define a resource in OAM 11g PS1, you specify a protection level from 1 of 3 choices: protected, unprotected, and excluded.

Protected resources must be included in an authentication policy that uses an authentication scheme with a protection level greater than 0. Protected resources can be associated with any authorization policy.

Unprotected resources must be included in an authentication policy that uses an authentication scheme with a protection level of 0. Most often this will be the anonymous authentication scheme. Unprotected resources can be associated with any authorization policy. Indeed, OAM will block access to unprotected resources that are not included in an authorization policy.

However, it is worth noting that it probably doesn’t make sense to put an unprotected resource into an authorization policy with constraints. If you plan on applying constraints to requests to a resource, then you should make that resource protected.

Session validation is still performed on requests to unprotected resource. However, if a user session times out or is otherwise invalidated and a user tries to access an unprotected resource, they will be let through but their name will not be propagated in the OAM_REMOTE_USER header, rather OAM_REMOTE_USE will be set to anonymous.

Basically, unprotected resources are the pre-PS1 equivalent of associating a resource with the anonymous authentication scheme.

Excluded resources are entirely new to PS1 (11.1.1.5). When a request comes in and matches up with a resource that has been designated as excluded, then the webgate/agent just lets the request through.

No calls to the OAM server are made, no session validation is performed, and the OAM_REMOTE_USER header is not added to the request. Also of note, if you have configured your webgates/agents to issue certain cache control headers back to the browser, they will not be issued in the case of excluded resources.

As you can probably see, OAM’s handling of excluded resources is very fast because, well, it isn’t doing much for them.

Unprotected vs. Excluded
At this point (if you are like me) you are probably wondering about when resources should be designated as excluded and when they should be designated as unprotected. On some levels these are very similar designations, although there are some important differences.

For performance reasons, I think it is a good idea to designate as many of your resources as possible as excluded. At the same time you want to make sure that your applications are still secure and functional. So, I’ve come up with the following guidelines:

1) If a resource is private, which is to say only authenticated users should have access to it, then if should be designated as protected.

2) If the resource is public, which is to say that authenticated and unauthenticated users should have access to it but you want to be able to know the names of authenticated users and/or set responses to create headers containing certain information about authenticated users, then the resource should be designated as unprotected.

3) If you want to audit requests to a resource using OAM then a resource should be designated as protected or unprotected. Note that you can still audit using web server logs for excluded resources.

4) If you want session validation to be performed in advance of populating the OAM_REMOTE_USER header, then a resource should be designated as protected or unprotected.

5) A corollary to items 2 and 4 above is that if you want the WLS SSO Synchronization filter to be active and “protect” a resource should be designated as protected or unprotected. This is an important note for those using OAM to protect Oracle WebCenter or ADF based applications.

6) If none of the above are true and you have a resource that is public, that doesn’t need to know anything about the user, where you don’t care about using OAM to audit access to the resource, and you don’t care about the WLS SSO Synchronization Filter for the resource, then (finally) you can make the resource excluded.

Short Cut Guideline
A short cut to the above guidelines that many will find useful is to designate as excluded public static resources such as images, PDF, and static html.

If such resources are grouped in directories then you can exclude them by defining policies like:

/app1/images/*

/app1/public/html/*

If such resources are more scattered, then you should be a little more careful and define resources individually or by file/content type like:

/app1/*.jpg

/app1/*.png

Conclusion

The notion of protection level for resources is an important addition to OAM 11g. The designation of excluded resources is likewise very important and will prove very useful for maximizing performance of your OAM enabled applications. You can read more about protection levels, excluded resources, and query strings in resources (which we’ll blog more about later) in the 11.1.1.5 documentation: http://download.oracle.com/docs/cd/E21764_01/doc.1111/e15478/app_domn.htm#BABJDGBB

I've been playing around with the OAM plug-in API and working on putting together a very simple JDeveloper project that includes a custom login form and an OAM plug-in that demonstrates the basics of using the interface.

I'm going to get that blog post out eventually, but for right now I need to talk about logging inside your plug-in.

OAM uses the Java Logger (java.util.logging.Logger and related classes) to record all of the debugging information in an easily manageable way. When you write your first plug-in it can be a bit confusing to figure out how the heck you get your logging messages out. It's not at all complicated, but it does mean you need to understand how OAM manages its logging.

Let's start with the absolutely minimum amount of code you need to log:

package com.oracleateam.iam.oamauthnplugin;

// a bunch of imports go here

public class DemoAuthNPlugin extends AbstractAuthenticationPlugIn {
  public DemoAuthNPlugin() {
    super();
    LOGGER.finest(this.getClass.getName() + " constructor called.");
  }

  // other methods
}

That's it. The bare minimum needed to get logging working.

Of course you need to do a little more work... Click through to see what else you need to do.

But in order to convince the logging layer to actually put that string into a log file we need to actually enable that logging. The OAM docs talk about this in some detail in this section, but here's a quick recap:

Run wlst from the OAM home:

[oracle@linux OAMDomain]$ ~/Oracle/Middleware/Oracle_IAM1/common/bin/wlst.sh

Then connect to the running OAM server and actually enable logging for oracle.oam.plugin (note: the docs talk about a different logger. In OAM 11.1.1.5 I know for a fact that plugins log under oracle.oam.plugin!)

wls:/offline> connect('weblogic', 'ABcd1234', 't3://localhost:7010')
Connecting to t3://localhost:7010 with userid weblogic ...
Successfully connected to Admin Server 'AdminServer' that belongs to domain 'OAMDomain'.

Warning: An insecure protocol was used to connect to the 
server. To ensure on-the-wire security, the SSL port or 
Admin port should be used instead.

wls:/OAMDomain/serverConfig> domainRuntime()
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root. 
For more help, use help(domainRuntime)

wls:/OAMDomain/domainRuntime> setLogLevel(logger="oracle.oam.plugin",level="TRACE:32", persist="0", target="oam_server1")
wls:/OAMDomain/domainRuntime> listLoggers(pattern="oracle.oam.plugin",target="oam_server1")
------------------+-----------------
Logger            | Level           
------------------+-----------------
oracle.oam.plugin | TRACE:32

Do that, upload, distribute, and activate your plug-in and you should be rewarded with something like this appearing in your log file:

[2012-02-01T16:03:38.122-05:00] [oam_server1] [TRACE:32] [] [oracle.oam.plugin] [tid: DistributedCache:DistributionCache:EventDispatcher] [userId: ] [ecid: 0000JKuP1i6DsX55nRx0iZ1FAP
9N000002,0] [SRC_CLASS: oracle.security.am.engines.common.adapters.OAMLoggerImpl] [APP: oam_server] [SRC_METHOD: finest] DemoAuthNPlugin loading

Which log file? servers/oam_server1/logs/oam_server1-diagnostic.log of course!

OK, so that's all well and good, but what if you don't want to log in the same place all the other OAM plug-ins log?

Easy peasy. Just make one change to your code:

package com.oracleateam.iam.oamauthnplugin;

// a bunch of imports go here

public class DemoAuthNPlugin extends AbstractAuthenticationPlugIn {
  private final static Logger LOGGER = Logger.getLogger(DemoAuthNPlugin.class.getCanonicalName());

  public DemoAuthNPlugin() {
    super();
    LOGGER.finest(this.getClass.getName() + " constructor called.");
  }

  // other methods
}

And add a new logger to OAM's configuration:

wls:/OAMDomain/domainRuntime> setLogLevel(logger="com.oracleateam.iam.oamauthnplugin",level="TRACE:32", persist="0",  target="oam_server1",addLogger="1")
wls:/OAMDomain/domainRuntime> listLoggers(pattern="com.oracleateam.iam.oamauthnplugin",target="oam_server1")
-----------------------------------+-----------------
Logger                             | Level           
-----------------------------------+-----------------
com.oracleateam.iam.oamauthnplugin | TRACE:32

And you will be rewarded with lines like this in your log file:

[2012-02-01T16:13:11.713-05:00] [oam_server1] [TRACE:32] [] [com.oracleateam.iam.oamauthnplugin.DemoAuthNPlugin] [tid: DistributedCache:DistributionCache:EventDispatcher] [userId: ]
[ecid: 0000JKuP1i6DsX55nRx0iZ1FAP9N000002,0] [SRC_CLASS: com.oracleateam.iam.oamauthnplugin.DemoAuthNPlugin] [APP: oam_server] [SRC_METHOD: ] DemoAuthNPlugin loading 

The key here is to not go monkeying with the logging.xml file. Just let WLST take care of all of that for you!

This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available.

In an earlier post I talked about how cookies work when you're using OAM 11g server with OAM 11g WebGates. But the OAM 11g server also works with OAM 10g WebGates and there are reasons you'd deploy 10g WebGates today. But OAM 11g and 10g have fundamentally different behavior when it comes to the cookies.

So how do cookies work when you're using 10g WebGates with the 11g server?

In short they work pretty much the same way. Or at least they can work nearly the same way with 10g WebGates as they do with 11g WebGates.

I setup an environment with two servers - alpha and linux.ktest.oracleateam.com. Alpha is an IIS server with an OAM 10g WebGate and one protected directory which I cleverly named /protected/. The other machine (linux.ktest.oracleateam.com) is, as you've guessed, a Linux box with the OAM server installed. I'd include a diagram, but it looks exactly the same as the diagram in the older post.

Here's what the HTTP traffic looks like when I try to access http://alpha/protected/:

GET /protected/ HTTP/1.1
Accept: image/jpeg, image/gif, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)
Accept-Encoding: gzip, deflate
Host: alpha
Connection: Keep-Alive

HTTP/1.1 302 Redirect
Content-Length: 0
Location: http://linux.ktest.oracleateam.com:14100/oam/server/obrareq.cgi?wh%3Dalpha%20wu%3D%2Fprotected%2F%20wo%3D1%20rh%3Dhttp%3A%2F%2Falpha%20ru%3D%252Fprotected%252F
Server: Microsoft-IIS/7.5
Set-Cookie: ObSSOCookie=loggedoutcontinue; httponly; path=/
X-Powered-By: ASP.NET
Date: Fri, 09 Mar 2012 16:14:16 GMT

GET /oam/server/obrareq.cgi?wh%3Dalpha%20wu%3D%2Fprotected%2F%20wo%3D1%20rh%3Dhttp%3A%2F%2Falpha%20ru%3D%252Fprotected%252F HTTP/1.1
Accept: image/jpeg, image/gif, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)
Accept-Encoding: gzip, deflate
Host: linux.ktest.oracleateam.com:14100
Connection: Keep-Alive

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store
Date: Fri, 09 Mar 2012 16:16:55 GMT
Pragma: no-cache
Content-Length: 3326
Content-Type: text/html; charset=UTF-8
Expires: 0
Set-Cookie: OAM_REQ=VERSION_4~KJTasxCSm1Z1LVGtpMwu5nJ3cwSYLNx1TGFLYN7tRq3Jr1Pin693MMCJJHQ6bPQL1vSxK3En%2bFaQPCNevV3Idi1o07xN9LjfFWubXf4B98yXOGRH6fT7RaZjp2dfPyqCADEG022AZg7xWsrCjff848vcqwAzLXs2schaae8z7YLXxCNVoMUGMsHFahTPkuq31ZIaqK8lZq7glReQuZyiBGXWPr5EptvGcbWEe0X9iOoeiUGFoJt6LpOCz79%2fJPpURizXOCQej3M3eCpGw8QmzUGa5ajAsPu5M0KZPViBubQwM9dsePRYNYaFizHYla8%2ftYr%2fHpgxkNLmuZ3crkzSZES45dnWdaqZBPbAcZb9S8pdGsjxMiB18bcudXC5A4DXnPwYLu92RQKrtHHgiq1JYIfMz4ZsCK5Fks%2bH3waTnw4Ec9V6EFvWF2rHXeGjqsHNN3jdZDtUlRkYcgBffUpBVkd%2fppwds%2fRcS4RVie39kRqduhbS1qphdGdy6pH8cX%2f8LEn3QoR2GXcn8cxgDEtfTR4q2JvrhbSnSChrqX967ogq8b%2bi0HEzDwFkYbhuZudsCXRHPVeOjGe78SY5IumWqCBIxW0z9LiSOhmcBDbagRFByhcTMpHZPU%2fxJxL7vdqllS8BwRPeVZuI0yuGstbBxVgWMzPJD%2bahnJXwlNODHEBCuMtYyO7gTol9VqpJo2l40PUgQUkmtw3cNf%2btazp5uTY%2fy8MG9AAyTNMTlgvaSnNTe0fwxiVMVcjuIqYUl%2fhSy%2fh1Z0lodn0w6HZQoiIyYMiEA%2felDR38iBKP4%2b14IvKroONAhuX0Ly4XSNRqGbzKyt%2fmqkc%2bguL2OPAIFjeBGMuses6r5Ml%2fepyF%2f%2bqnXTBB%2bFweBmaxHdv1uU58kWwtTfkWJwEuALDJhAXG7ixRnkHISfizpkPKGTs5jAGDj8Lhcndl1IAKbekDS5d6g2zxSpl4RDGmZuWcVG2G8XSyBs5D317CWvx1Mq3SDZhcvGy7RscDcqy7ra66j1uS49QaKvAgdGA03RzwAfCLMD4wNnj06aAkh9BXTDv%2bgHYzCaWpXm8yjMAVPr9fhXzn3Nro3ffM8I%2bEdFq2lRLdFIo04Gc4o%2f7lS0dGZKS6%2fyB5UKCtmD%2fihmsHdCVFUcRCMdff21HGT%2f8y0j6yQHNf4X1RefEdYcjbYOEv%2bbm1Jq5zcat60maesmmiBl5n6LJFYSfG6QLs4wLqZjqEXPWU96JBQuFwDjf7ux4RTcmnLG3LbU3M6lUPqfB0k8TGee7XbtaW0Z%2b69CIsYElY1ftvszOT2uMw2yAjy8nvs7iIJVvXGb0yX57h77WiySby6ISqvIH1maMdzr6jIAL76ImMc%2bCVJzJvt4WgobY6nc4OH4MSPMg%3d; path=/; HttpOnly
X-ORACLE-DMS-ECID: bc0b467a62ba363a:-50e866c2:135cc4d3539:-8000-0000000000000ab5
X-Powered-By: Servlet/2.5 JSP/2.1

As is the case with 11g WebGates the WebGate redirects me over to the OAM server to see if I have an existing session. And since I haven't logged on yet I don't have a session or associated cookie. So OAM sends me off to the login page.

So far this looks remarkably like the 11g WebGate. And by "remarkably like" I mean exactly the same as!

At this point I'm staring at the login page so let me enter the username and password and POST them to the credential collector:

POST /oam/server/auth_cred_submit HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Referer: http://linux.ktest.oracleateam.com:14100/oam/server/obrareq.cgi?wh%3Dalpha%20wu%3D%2Fprotected%2F%20wo%3D1%20rh%3Dhttp%3A%2F%2Falpha%20ru%3D%252Fprotected%252F
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Host: linux.ktest.oracleateam.com:14100
Content-Length: 67
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: OAM_REQ=VERSION_4~KJTasxCSm1Z1LVGtpMwu5nJ3cwSYLNx1TGFLYN7tRq3Jr1Pin693MMCJJHQ6bPQL1vSxK3En%2bFaQPCNevV3Idi1o07xN9LjfFWubXf4B98yXOGRH6fT7RaZjp2dfPyqCADEG022AZg7xWsrCjff848vcqwAzLXs2schaae8z7YLXxCNVoMUGMsHFahTPkuq31ZIaqK8lZq7glReQuZyiBGXWPr5EptvGcbWEe0X9iOoeiUGFoJt6LpOCz79%2fJPpURizXOCQej3M3eCpGw8QmzUGa5ajAsPu5M0KZPViBubQwM9dsePRYNYaFizHYla8%2ftYr%2fHpgxkNLmuZ3crkzSZES45dnWdaqZBPbAcZb9S8pdGsjxMiB18bcudXC5A4DXnPwYLu92RQKrtHHgiq1JYIfMz4ZsCK5Fks%2bH3waTnw4Ec9V6EFvWF2rHXeGjqsHNN3jdZDtUlRkYcgBffUpBVkd%2fppwds%2fRcS4RVie39kRqduhbS1qphdGdy6pH8cX%2f8LEn3QoR2GXcn8cxgDEtfTR4q2JvrhbSnSChrqX967ogq8b%2bi0HEzDwFkYbhuZudsCXRHPVeOjGe78SY5IumWqCBIxW0z9LiSOhmcBDbagRFByhcTMpHZPU%2fxJxL7vdqllS8BwRPeVZuI0yuGstbBxVgWMzPJD%2bahnJXwlNODHEBCuMtYyO7gTol9VqpJo2l40PUgQUkmtw3cNf%2btazp5uTY%2fy8MG9AAyTNMTlgvaSnNTe0fwxiVMVcjuIqYUl%2fhSy%2fh1Z0lodn0w6HZQoiIyYMiEA%2felDR38iBKP4%2b14IvKroONAhuX0Ly4XSNRqGbzKyt%2fmqkc%2bguL2OPAIFjeBGMuses6r5Ml%2fepyF%2f%2bqnXTBB%2bFweBmaxHdv1uU58kWwtTfkWJwEuALDJhAXG7ixRnkHISfizpkPKGTs5jAGDj8Lhcndl1IAKbekDS5d6g2zxSpl4RDGmZuWcVG2G8XSyBs5D317CWvx1Mq3SDZhcvGy7RscDcqy7ra66j1uS49QaKvAgdGA03RzwAfCLMD4wNnj06aAkh9BXTDv%2bgHYzCaWpXm8yjMAVPr9fhXzn3Nro3ffM8I%2bEdFq2lRLdFIo04Gc4o%2f7lS0dGZKS6%2fyB5UKCtmD%2fihmsHdCVFUcRCMdff21HGT%2f8y0j6yQHNf4X1RefEdYcjbYOEv%2bbm1Jq5zcat60maesmmiBl5n6LJFYSfG6QLs4wLqZjqEXPWU96JBQuFwDjf7ux4RTcmnLG3LbU3M6lUPqfB0k8TGee7XbtaW0Z%2b69CIsYElY1ftvszOT2uMw2yAjy8nvs7iIJVvXGb0yX57h77WiySby6ISqvIH1maMdzr6jIAL76ImMc%2bCVJzJvt4WgobY6nc4OH4MSPMg%3d

username=weblogic&password=ABcd1234&request_id=-8330979068306697433

HTTP/1.1 302 Moved Temporarily
Connection: close
Date: Fri, 09 Mar 2012 16:17:01 GMT
Transfer-Encoding: chunked
Location: http://alpha/obrar.cgi?cookie=vBDzuSSiKglMEtxbyB1gBqe1aZvsE6WQhSF7%2Be%2FZ0DpntUvIXgPr79acpIo8FQ0V4mvuOrqn%2BGIendMpqPNgTuISUEDblFQjZKfNG4ixWaVW%2BitIr58w%2FvQ2kalnVL3zhKYAF2yU7rGyNolRifidAq7xW8%2BKQbyFq8GFAgga0Assv%2BxwGzvd%2FizmiXnx8cOD6KZBWGMtIeLBrJRBitqXoKgLZc6b2UuCc2VLkTufmlQdt0DZ7dOACr45efkrTSKgKhuqoykTsiKiGTIP4R2xe85TUfYYm%2F1i4E8p%2FdHmcD4tpJ4LRrslKI3MgDHj%2Ft1uq3ryhROxbcRBk2eM1Eo99QYNY6IOsFyo1sJA7YEkr7c%3D%20redirectto=%252Fprotected%252F%20ssoCookie=httponly
Set-Cookie: OAM_ID=VERSION_4~C7Iz5I0rodPWWPLR82CoQg==~bP8dGW/YVqe1NaHiCaZ3z6p2dbxVbpJpcSYMU6LVzUSBHp0C9OtSKbtvUlHHDsGImCi8KtAh3CLHXN+paF2+ZyxNOZOge2Mg2aH6vF8Wy2fUgIEYAVYjtVrP4bVTC0GpM7S6dt3XpjR/AHScYUdQNp5Olr5D3gSlBAnXWcyYxY9u/x620d5LHIYvBdZvqZzVsfAAV/5KovBKD/5wvhPWI/JDkYoUdT37VoaDp7BS1lOumUtTqzXkQTzMzAkLCzhS0M1NyCYTiT9904bIxfzhJw==; path=/; HttpOnly
Set-Cookie: OAM_REQ=invalid; path=/; HttpOnly
X-ORACLE-DMS-ECID: bc0b467a62ba363a:-50e866c2:135cc4d3539:-8000-0000000000000ab7
X-Powered-By: Servlet/2.5 JSP/2.1

Not terribly surprisingly I get an OAM_ID cookie and a redirect back to the protected resource, again just like with the 11g WebGate.

So we're on our way back to the WebGate to a fake resource called obrar.cgi with some encrypted data in the query string (yes, oddly familiar!).

The browser does the HTTP GET there...

GET /obrar.cgi?cookie=vBDzuSSiKglMEtxbyB1gBqe1aZvsE6WQhSF7%2Be%2FZ0DpntUvIXgPr79acpIo8FQ0V4mvuOrqn%2BGIendMpqPNgTuISUEDblFQjZKfNG4ixWaVW%2BitIr58w%2FvQ2kalnVL3zhKYAF2yU7rGyNolRifidAq7xW8%2BKQbyFq8GFAgga0Assv%2BxwGzvd%2FizmiXnx8cOD6KZBWGMtIeLBrJRBitqXoKgLZc6b2UuCc2VLkTufmlQdt0DZ7dOACr45efkrTSKgKhuqoykTsiKiGTIP4R2xe85TUfYYm%2F1i4E8p%2FdHmcD4tpJ4LRrslKI3MgDHj%2Ft1uq3ryhROxbcRBk2eM1Eo99QYNY6IOsFyo1sJA7YEkr7c%3D%20redirectto=%252Fprotected%252F%20ssoCookie=httponly HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Referer: http://linux.ktest.oracleateam.com:14100/oam/server/obrareq.cgi?wh%3Dalpha%20wu%3D%2Fprotected%2F%20wo%3D1%20rh%3Dhttp%3A%2F%2Falpha%20ru%3D%252Fprotected%252F
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Cookie: ObSSOCookie=loggedoutcontinue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cache-Control: no-cache
Host: alpha

HTTP/1.1 302 Redirect
Content-Length: 0
Location: /protected/
Server: Microsoft-IIS/7.5
Set-Cookie: ObSSOCookie=vBDzuSSiKglMEtxbyB1gBqe1aZvsE6WQhSF7%2Be%2FZ0DpntUvIXgPr79acpIo8FQ0V4mvuOrqn%2BGIendMpqPNgTuISUEDblFQjZKfNG4ixWaVW%2BitIr58w%2FvQ2kalnVL3zhKYAF2yU7rGyNolRifidAq7xW8%2BKQbyFq8GFAgga0Assv%2BxwGzvd%2FizmiXnx8cOD6KZBWGMtIeLBrJRBitqXoKgLZc6b2UuCc2VLkTufmlQdt0DZ7dOACr45efkrTSKgKhuqoykTsiKiGTIP4R2xe85TUfYYm%2F1i4E8p%2FdHmcD4tpJ4LRrslKI3MgDHj%2Ft1uq3ryhROxbcRBk2eM1Eo99QYNY6IOsFyo1sJA7YEkr7c%3D;httponly; path=/
X-Powered-By: ASP.NET
Date: Fri, 09 Mar 2012 16:14:22 GMT

Ah! There it is - the first real difference between OAM 11g and OAM 10g WebGates behavior. With the 10g WebGate I get a good old ObSSOCookie instead of a 11g's uniquely named cookie.

I also got and a redirect back to the original resource, which I then retrieve:

GET /protected/ HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Referer: http://linux.ktest.oracleateam.com:14100/oam/server/obrareq.cgi?wh%3Dalpha%20wu%3D%2Fprotected%2F%20wo%3D1%20rh%3Dhttp%3A%2F%2Falpha%20ru%3D%252Fprotected%252F
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Cookie: ObSSOCookie=vBDzuSSiKglMEtxbyB1gBqe1aZvsE6WQhSF7%2Be%2FZ0DpntUvIXgPr79acpIo8FQ0V4mvuOrqn%2BGIendMpqPNgTuISUEDblFQjZKfNG4ixWaVW%2BitIr58w%2FvQ2kalnVL3zhKYAF2yU7rGyNolRifidAq7xW8%2BKQbyFq8GFAgga0Assv%2BxwGzvd%2FizmiXnx8cOD6KZBWGMtIeLBrJRBitqXoKgLZc6b2UuCc2VLkTufmlQdt0DZ7dOACr45efkrTSKgKhuqoykTsiKiGTIP4R2xe85TUfYYm%2F1i4E8p%2FdHmcD4tpJ4LRrslKI3MgDHj%2Ft1uq3ryhROxbcRBk2eM1Eo99QYNY6IOsFyo1sJA7YEkr7c%3D
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cache-Control: no-cache
Host: alpha

HTTP/1.1 200 OK
Cache-Control: no-cache,private
Pragma: no-cache
Content-Type: text/html
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Fri, 09 Mar 2012 16:14:22 GMT
Content-Length: 2495

As with the 11g WebGate you probably noticed that there's no domain= parameter on the cookie. Which means that this ObSSOCookie is specific to the one WebGate. But wait, didn't OAM 10g WebGates use a domain-wide cookie?

Yes they did. And 10g WebGates still do if (and only if) that's what you want.

Here's my configuration settings for my 10g WebGate:

In my case I left out the cookie domain setting for the WebGate. And by doing that I told the WebGate to act like the 11g WebGate and use "host only" cookies.

Filling in that setting changes the behavior. For new deployments of OAM 11g with 10g WebGates I generally would recommend leaving the setting blank because it solves a number of problems with cookies in larger deployments of OAM. But I'm going to put off discussing those problems until a later post.