Virtual Identity Dialogue

I have been meaning to respond to Radovan Semancik's "Single Directory Paradigm"
for a  while, but combination of end of Oracle fiscal year and
upcoming software releases, has meant limited time to blog.




Semancik raises some points about whether it's possible to have all of your
enterprise identity stored in a single enterprise directory server.
While he does raise some valid points - I wanted to take the chance to
show how Oracle Directory Services (which means the combination of
Oracle Internet Directory, Oracle Virtual Directory and Directory
Integration Platform) could meet his challenges.



I want to point out with that Semancik points are pretty much spot-on
when discussing traditional directory servers or meta-directory
approaches. In these approaches you are constantly tryinng to
synchronize data into a single storage system. This has a tendency to
not be successful for many reasons such as internal "data-politics",
scalability problems with first-generation directory servers like Sun's
& Microsoft as well as regulations that prevent data-copying (but
allow data-querying).
 

Semancik presented a set of key areas he thought were particularly
glaring and I'd like to show how Oracle Directory Services addresses
them:



Inconsistency of Identifiers
In
many organizations- you usually
find that there are multiple network identifiers. For example you can
have your employee identification number, a Windows network id, a VPN
id and of course an email address. Attempting to unify these into a
single profile, using traditional synchronization techniques can be
challenging because of constant reconciliation. However, the Oracle
Virtual
Directory (OVD) can be used to link identities stored in multiple
sources into a unique virtual LDAP entry - in real-time. 



Inconsistency of access controls

While all directories have access controls - there is very little
standardization in their formats. Plus if you are switching between
directories or data-stores run by different departments, it's very hard
to provide consistent controls and audit trails. With Oracle, we can
provide multiple approaches to solve the problem. One is that you could
move your directory data into Oracle Internet Directory (OID), which is
our more traditional directory server product - but that utilizes
Oracle Relational Database as its storage system. OID is has met the
Common Criteria Level 4 designation - a high level of security required
for U.S. Military adoption making it one of the most secure directory
servers on the market. Or if you want to keep your directory data where
it's at but want to improve its overall security model - you can use
OVD as an abstraction layer to provide a consistent set of access
controls to clients plus additional benefits such as unique views of
data per application and a directory firewall.

Inconsistency in object structure

One of the initial benefits of LDAP over a traditional relational
database approach to identity was the concept of a standardized user
attributes and objects. However, inconsistencies have arisen - in
particular because of Active Directory which all-but totally ignores
the inetOrgPerson standard instead using its own proprietary "User"
object. Thus if you are in a situation where you're lucky enough to
have an application that can speak to multiple directories - but one of
those directories is say Sun and the other is Active Directory - you
can have a mess on your hands. For example - most directories store
their network login in an attribute named "uid" while Microsoft stores
theres in "samaccountname".



One of the benefits of directory virtualization is that we can in OVD
normalize your directory server schema. Specifically we can
in-real-time, without any modification on your current AD setup - make
AD entries look like standard inetOrgPerson entries.



Thus solving one of the biggest consistency challenges.



Directory server is not an authentication server

Of all of the points in the initial blog post, this is the most
correct. LDAP is primarily a service designed to provide access to
attributes about objects, usually people and groups. Kerberos was
supposed to be the standard for authentication, but for a variety of
reasons it never really caught on. This is one area that Microsoft got
correct with Active Directory. However, with Oracle we do have a
solution that solves this predicament in the form of Oracle Access
Manager (formerly COREid Access Manager). OAM provides you with a
sophisticated mechanism to provide single sign-on and delegated
application access control to extend the benefits of having a
centralized directory service - either virtualized or not.



Directory server is  "stateless"

This point is the most incorrect. LDAP is a stateful protocol so of
course it knows what clients are connecting to it. I think what he
means to imply is that normally clients accessing the directory are
really acting on behalf of another user. But that's a standard
middleware feature/problem. And one that is well understood.



Deprovisioning of stateful applications is a problem

This point is a bit confusing and makes me wonder if perhaps Mr.
Semancik doesn't actually understand directories. Typically directories
are the "end-state" data repository and not the authoritative source.
Meaning that there are other systems (such as HR, Student Information
Systems, etc) that are the actual "sources of truth". And yes, if you
are doing a traditional synchronization of data from one of these
systems to your directory - you run into a problem where if someone
leaves or is terminated there can be a signifigant delay between when
the user is removed and the data is synchronized into all of its proper
directories.



In Oracle we can solve this in real-time using directory virtualization
- because the virtual server is
stateless - it always queries the "source of truth" in real-time. This
includes databases or Web Service based systems, thus the answer OVD
gives is always accurate up to the second.



Or if you still need a more traditional synchronization approach - you
might consider our related identity management products such as:

• Directory Integration Platform - is our meta-directory product
  that helps makes sure that OID (and applications that synchronize with
  OID such as our eBusiness Suite) is always in synchronization.


• Oracle
  Identity Manager (formerly Xellerate) provides a mechanism to keep
  multipe types of applications in constant synchronization