The first chapter of the EDG includes a good diagram and description of Oracle’s reference architecture for the IAM platform for Fusion Apps. The rest of the EDG walks you through building out an IDM environment that fits this reference architecture.
In this post I’ll give a guided tour of this reference architecture and at the end discuss how you can still use the EDG to build out a simplified environment if that is the route that you want to take.
IDM Reference Architecture for FA Overview
Above you see the IDM reference architecture for FA (without the inclusion of OIF). The IDM reference architecture for FA includes 12 hosts spread across 3 tiers where each tier is in a separate firewall zone.
From bottom to top we have:1) The directory or data tier consisting of the directory (OID), virtual directory (OVD) and databases supporting the whole IDM environment.
2) The application tier consisting of all the services (OAM, OIM, ODSM, SOA) that run in WebLogic Server.
3) The web tier consisting of the web server (OHS) and HTTP load balancer.
The reference architecture is fully highly available. For the databases, this is accomplished through use of RAC. For everything else, it is accomplished by having 2 nodes with redundant services and utilizing load balancing in some form or another for all communication. If you are no planning on building an HA environment or if you just want a simplified view of things, you can almost cut the above diagram in half and only consider one side.
The reference architecture is pretty complex in that it is completely HA, separates all the IDM services into 3 tiers for maximum network security, and separate many of the services onto different physical nodes to account for load separation for high volume production environments.
There are reasons one might want to simplify this for development, QA, or even production environments. Specifically, you may want to consolidate physical hosts, not do HA, or not use a load balancer for some traffic that does in the reference architecture.
These simplifications can all be done and I’ll discuss this in more detail in my next post. For now, just know that you can build a functional IDM environment for Fusion Apps without FA and on far less hosts than the reference architecture. In fact, the IDM environment can be consolidated all the way down to 2 hosts, 1 for the DBs and 1 for everything else.
A Walk through the Logical Hosts
Now that we are through the overview, let me walk you through what is contained in each of the twelve hosts present in the reference architecture. Going again from bottom to top…There are two databases in the data tier. The OID RAC DB is the repository for OID and the other DB is the repository for everything else. The EDG shows these as separate databases. They can in fact be on the same physical host and be part of the same database install (ORACLE _HOME) but they should be separate instances. The DBs are specified as RAC but RAC is not required for non-HA environments.
Moving up from the DB in the directory/data tier we have the OIDHOST1, OIDHOST2, OVDHOST1, and OVDHOST2. These hosts contain the instances of OID and OVD respectively. Note, that this does not include ODSM, WLS, EM or other components that come when you do a basic install of OID and/or OVD on a single node. I’ll also mention that combining the OID and OVD hosts is a good way to consolidate nodes (while preserving the tiers) if you are looking to do that.
Moving up into the application tier we have IDMHOST1 and IDMHOST2. The IDMHOST is probably the most central host in the reference architecture. It is the “master node” for the WebLogic domain that will be the central part of the IDM environment. IDMHOST1 contains the following applications all running on WebLogic: WLS admin server, Enterprise Manager, OAM admin server, OAM managed server, and ODSM (the admin app for OID and OVD). IDMHOST2 contains the OAM managed server and ODSM and inactive instances of the WLS admin server, enterprise manager and the OAM admin server.
The reason that the WLS admin server, OAM admin server, and EM are inactive on IDMHOST2 is because you can only have one WLS admin server running in a domain at 1 time and all these apps run in the WLS admin server. In fact, the admin server for a domain is configured to bind to a single specific IP address and so if you want to be able to run it at all on IDMHOST2, you have to configure a virtual IP address (VIP) that can float between IDMHOST1 and IDMHOST2 for the admin server to bind to.
The other hosts in the application tier are OIMHOST1 and OIMHOST2 which host the managed servers for OIM and the OIM specific deployment of SOA suite. OIMHOST can be consolidated with IDMHOST if you are looking to do node/host consolidation. The thing to keep in mind is that OIM can chew up a lot (all) of a system’s resources when it does bulk operations like reconciliations. If you have a small number of users and/or aren’t using OIM as your enterprise identity management / provisioning solution then this probably isn’t too much of an issue. However, one should definitely keep this and mind and tread carefully when running OIM on the same box as other critical services.
Finally in the web tier we have an HTTP load balancer, WEBHOST1 and WEBHOST2 which contains the web servers (OHS). The OAM webgate is installed and enabled on both OHS servers. This is an important point to understand. OAM is used to protect the web interfaces in the IDM environment and all HTTP traffic into the IDM environment comes through the OHS servers in the web tier. There is no direct access to any of the services.
Lastly, I’ll point out that the naming conventions here are somewhat confusing. For instance, IDMHOST does not contain OIM. Rather it is the “master” host for the IDM domain and contains the admin server along with OAM and ODSM. Keep this in mind as you go through your build out as I’ve seen many people get understandably confused by this and attempt to execute steps on the wrong box during the build out.
Communication Links
Now let’s consider request flow and the communication links in the reference architecture. This time we’ll go from top to bottom.
HTTP requests (be they from users or web services) come into the system and hit the load balancer where they are dispatched to OHS running on one of the WEBHOSTs.
OHS sends the requests along to one of the WLS servers in the app tier on IDMHOST or OIMHOST. Here load balancing is done by the WLS plug-in for OHS (mod_wl_ohs). This plug-in is cluster aware and will perform session sticky load balancing without the need for any external load balancer.When one of the services in the app tier needs to talk to the identity store and policy store, it will talk to OVD on OVDHOST and OID on OIDHOST (depending on specific configuration) over well… the LDAP protocol. More accurately, the services will talk to a load balancer that may or may not be the same as the load balancer used for the HTTP traffic. My point being that a load balancer is required here to load balance the LDAP traffic.
LDAP traffic will also come into the system from Fusion Apps itself which will query both the identity store and policy store. Requests to the policy store will come through the load balancer and be dispatched directly to OID. Requests to the identity store will come through the load balancer and be dispatched to either OID or OVD, again depending on the configuration.
SSL
In the reference architecture, SSL is terminated at the load balancer and it is assumed that network security will ensure integrity and confidentiality of traffic behind the load balancer.
That being said, SSL is supported at every communication link in the IDM environment for Fusion Apps.
You can configure OHS with SSL and put the load balancer in pass through mode so that the entire browser to OHS connection is over SSL.
You can configure WLS and mod_wl_ohs so that the OHS to WLS connections are over SSL.
Lastly, you can configure the directories and individual product configurations so that the connections to OID and OVD occur over SSL (LDAPS).
Teaser
In my next post I’ll talk about the hostname references in the IDM EDG which is a cause of confusion for many people. I’ll also cover models for simplifying the IDM environment for Fusin Apps from the reference architecture and still use the EDG as your guide for the build out.
Posts
Nice post. I recently installed Fusion Applications(Sales)-11.1.1.5 in Amazon cloud and this blog has been the most helpful in understanding entire IDM configuration(Especially the OAM learning series). It is very good to get insights directly from Oracle experts. Keep posting. Thanks.
ReplyDeleteGreat post, One question. In this reference architecture I don't see how you would set it up for internal users and internal applications. Can I assume the internal users will use the same IDM architecture as the external (internet) users ? Or is best practice to install an IDMHOST3&4 and OIMHOST3&4 for the internal users ?
ReplyDeleteGood question Vermeertjes. The architecture is meant to service both internal and external users. The main thing you need to do is to make sure that that virtual host that OIM and OAM pages are served through (SSO.mycompany.com) is accessible both internally and externally.
ReplyDeleteOk thanks for the reply, one question left :
ReplyDeleteWhy should the OID repository and the other repository for everything be separate instances ?
Vermeertjes,
ReplyDeleteThat is a good question. I don't have a straight forward answer on that but I've been told that there have been DB level conflicts identified between OID and OIM that occur under some load.
--Brian