A Complete Identity Management Solution

Configuring High Availability for Oracle Virtual Directory - Part2

Testing the Failover design

To test the OVD failover configuration, I have used Apache Directory Studio as the client to connect both the Sun LDAP instances and the OVD instance.

The following picture shows the LDAP connection for Sun Directory Server instance running on port 3890. This view is from Apache Directory Studio
 

The following picture shows the LDAP connection for Sun Directory Server instance running on port 7890. This view is from Apache Directory Studio


The following picture shows the LDAP connection for Oracle Virtual Directory instance running on port 5890. This view is from Apache Directory Studio


Now stop the LDAP instance 3890. View from Apache Directory Studio


Now connect Oracle Virtual Directory running on port 5890 using Apache Directory Studio and you should see the results served from LDAP instance 7890


This is just example to show how easy it is to setup fail over configuration in Oracle Virtual Directory using only one LDAP adapter between two LDAP instances. For a detail documentation
 on various features, please refer to OVD product documentation.





Configuring High Availability for Oracle Virtual Directory - Part1

One of the design issues that I have always encountered during my  OAM-OVD implementation is that  implementation engineers seldom give thoughts to design H/A for Oracle Virtual Directory. The emphasis is always given to Oracle Access Manager Fail over design. It is either because the Oracle Virtual Directory documentation lacks proper emphasis on fail over unlike OAM documentation which has separate deployment guide (OR) it is left to the Hardware Load balancers to do the failover work for OVD.  One can always set up failover configuration in OVD as it has some nice features for fail over as well as load balancing.

For this example, I am using two instances of Sun Directory Server 5.x with multi master replication. Oracle Virtual Directory 10g is used to connect to both the Sun LDAP instances through a single Sun LDAP Adapter. The following is the screen shot of the Sun LDAP adapter configuration in OVD that has failover configuration.

The following parameters in OVD Manager are available to set up fail over between two ldap instances using a single LDAP adapter.

Maximum Load = 100%

R/W Operation = True

Failover Mode = Sequential

Heartbeat = 60 secs

Note: If you set Failover mode as Distributed, then OVD will be operating in a load balancing mode and not in Failover mode

Chained Authentication in OAM


I anticipated that this would happen sooner than later. What I call the ‘blogging mania’ has creeped into Likeminds. Everybody at Likeminds wants to blog now. Whats wrong? I think blogging just comes naturally to IDM experts – they all like to brag and blogging is a great way to do it. Also if somebody benefits from the bragging/blogging why not? Here I am, dying to tell the world what I implemented. Its not hard to guess who would have been the one of the first ones in Likeminds to come up with a blog. This blog is all about authentication , more precisely ‘Chained Authentication’ in OAM.  I am sure everybody even remotely related to access management knows that Authentication is the process of proving that a user is who he or she claims to be. For the ones who are familiar with setting up authentication schemes for policy domains, adding and managing plugins is nothing new

Consider this scenario – you have a Directory which stores two different types of user groups UserTypeA and UserTypeB. The requirement is such that
- UserTypeA need to be authenticated by 
         <b>verifying their credentials with the Directory and the Mainframe.
- UserTypeB need to be authenticated by 
           <b>verifying their credentials  only with the Directory

A custom plug-in is written which authenticates with the Mainframe. Now comes the tricky part, when setting up the Authentication scheme if you include this custom plug-in, this plug-in will be invoked for UserTypeB also which is unnecessary as UserTypeB do not need to be authenticated against Mainframe. This is where Chained Authentication comes in. It gives you the flexibility of limiting the usage of the custom plug-in only for UserTypeA. Also the authentication steps can be configured such that the plug-in which maps the user’s credentials to the Directory searches for the user only in the branch to which the user belongs. Only if the search fails in that branch it goes to the other branches. This is particularly useful when the branches are very huge.

To implement chained authentication add thenecessary  plug-in.


Add required steps



Now attach required plug-in for each step.  For example the

UsersA step includes only one plug-in with UsersA  branch as the searchbase



-         UsersB step includes only the plug-in with the UsersB branch as the searchbase,

-          Mainframe step includes the Mainframe custom plug-in

-         Passwordstep includes the validate_passwordplug-in. Finally the authentication flow shownbelow can be modified according to the requirement so it is not alwaysnecessary to stick to the Deafult Step.

FFor UserTypeA the followingsteps will be executed,

-UsersA step

-Mainframe step

-Password step

Whereas for UserTypeB onlythe

-UsersB step and the

-Password step will be executed.

F




 

Welcome to Like Minds IdM blogs

We have created this blog site to share some of the implementation and design issues and challenges that we have faced using Oracle Identity and Access Management suite. We call them as our own "Identity and Access Patterns". Please feel free to use the code samples, design patterns that we provide in this site. We hope you will find this site useful.

Authors

Calendar

May 2012
SuMoTuWeThFrSa
12345
6789101112
13141516171819
20212223242526
2728293031

Syndicate

Monthly Archives

Recent Comments

Subscribe


Tag Cloud