I want to deploy OAM like this:The answer is "If you really want to do that then yes. But you probably shouldn't do it that way." Read on for why. The first thing to think about is how you are going to deploy OAM "for real". Consider a company like Oracle who uses OAM to protect basically everything. If you go to http://support.oracle.com/ to open or look at a support case, or to http://www.oracle.com/ to read up on the products, or to https://edelivery.oracle.com/ to download software, or nearly any Oracle site that requires you to login you are going to login through OAM. But before you are prompted for your credentials OAM first needs to see if you have an existing session.
Is this supported?
Here's my post about how the OAM login process actually works. If you were to deploy OAM as in the diagram above then when you deploy your second application every OAM will need to redirect every user to the first web server to see if they have a session and to login if they don't. When you add your third application it too will need to redirect users to the first web server. And on and on. Which is why this is how you should deploy OAM:
Posts
I 'm having trouble comparing your pictures to the 'official' guidance here: http://docs.oracle.com/cd/E21764_01/core.1111/e12035/whatis_im.htm#CHDJDIEH. From Figure 1.1 there one could assume that various apps could use app specific VIP names on the load balancer and use virtual hosts on WEBHOST1, WEBHOST2. Or are you saying that WEBHOST1, WEBHOST2 should be used strictly/only for OAM infrastructure names (like sso.company.com) and instead setup additional webhost/webgates like WEBHOST3, WEBHOST4 for app specific names (like edelivery.oracle.com, support.oracle.com etc.). Please clarify.
ReplyDeleteIt's not really clear what your diagrams are doing.... especially in the 'solution'... what is the line from user to OAM??
ReplyDeleteThese lines are HTTP traffic. In a real world deployment you would normally not have users talking to the OAM server directly. Instead they go through some sort of proxy server - in this case I use OHS but it could be an F5 or some other load balancer and/or an HTTP traffic filtering proxy of some sort.
ReplyDeleteI left out the lines for other communication like NAP from the WebGate to the OAM server for simplicity.
Vamsee:
ReplyDeleteAs the disclaimer below says "The views expressed on this blog are solely our own and do not necessarily reflect the views of Oracle."
In general I prefer to have a larger number of smaller, more manageable "boxes" in an architecture. So it would be my preference to have the OHS server facing the Internet and/or Intranet only front end the OAM servers. So when I draw that above I'm putting OAM and only OAM behind the OHS server on the lower fork.
The other thing I don't like about the official diagrams is that they imply that ODSM and the OAM Admin Server are all behind the same OHS server. I can't imagine an enterprise deployment doing that - why would you want either of those administrative interfaces exposed to the Internet or even the Intranet?
I don't think the EDG is saying that you should. But in collapsing everything to the single picture some of those nuances are lost.
Hence my blog post.
Hope this helps!
This comment has been removed by a blog administrator.
ReplyDeleteAmol: Please contact me directly by email. Christopher.Johnson at oracle
ReplyDeletei am a little confused as to why the oam would have to redirect to the first web server to determine session information. I wasn't aware that the web server stored any session state?
ReplyDeleteI am planning on deploying the following (simplified) architecture:
-> Clustered OAM servers
client -> HLB -> Clustered OHS servers |
-> Clustered Apps managed Servers
I was under the impression the session state was held in cookies on the client and that the OAM would be able to determine whether login is required from the client request?
are you saying that we should have a seperate set of clustered OHS servers (high avaliability) just for the clustered OAM servers and not share the clustered OHS servers fronting the apps managed servers?
Most of the session state IS kept in a cookie. But in OAM 11g we fundamentally changed the way sessions work.
ReplyDeleteIn the old 10g model everything was in the cookie (ObSSOCookie) and usually the cookie was set to be sent to every machine in your domain. This worked pretty well but it was built for a simpler time.
In the modern world when you have to support SAML or need the ability to kick people off when they're being mischievous, or you want to squirrel away more data than can reasonably be put in a cookie we need something more. So in 11g we use a Coherence cache to track session. And we also made all of the cookies used by OAM "per host" cookies which makes them much more secure. I wrote a blog post about this at http://fusionsecurity.blogspot.com/2011/04/oam-11g-single-sign-on-and-oam-11g.html