Virtual Identity Dialogue

James McGovern recently wrote a question on whether using changelog was sign of good or bad architecture in response to another post on Sun's issues integrating their provisioning product with ADAM.

And James wanted to know - could OVD help?

First - I was surprised that Sun had issues - I figured this was a solved problem in provisioning maybe instead of Sun you should check out OIM :). Second, ADAM is really designed to be an "end-point" (hence no changelog) not a source, thus I would always question an architecture that used ADAM as a source of data.

But to more specifically answer James' question..

Whenever I hear about ADAM being deployed - I always question why is it being deployed - so see if there is a better way.

For example if the reason ADAM is being deployed is because you have data that exists in another database but you need it to be LDAP accessible, then that is clearly a benefit of deploying OVD. OVD could make that DB data look like LDAP without copying it into another storage system that needs to be made highly available, backed up and secured. OVD does all of that with a smaller footprint by leveraging all of the work you already have done in the existing system.

Or it could be that you need to make your existing AD user data look like InetOrgPerson (instead of AD's proprietary user schema). OVD can on the fly make AD look like InetOrgPerson without needing to bring up ADAM.

However, another use case could be is that you have a user population that needs to be stored in a directory but can't be deployed in AD. For example this could be external customers, partners or vendors. While ADAM definitely could be used there - OID could also be an option.

Another slight twist to this use case is where you are deploying an application such as a portal,web  access management or Unix authentication that needs to store data in user's entry but you can't extend the AD schema. OID allows you to store this data in OID while leaving the password stored in AD. OVD is also an option as long as the data can be stored somewhere (benefit of OVD is that possibly - depending upon the type of data, could be stored in a non-Oracle EE database).

And an additional benefit of OID is that it provides default support for synchronization to LDAP or databases via Directory Integration Platform (DIP) and exposes a standards-based changelog so your provisioning tools can easily integrate with it.

While you might be asking "Mark, why are you pushing OID if I have ADAM" - my answer would be two reasons.
First reason is that if you need to be notified of changes in the data being stored, ADAM is probably not the best option. It's not designed for that purpose.
Second reason is that with over 13,000 deployments of OID world-wide, there's a reasonable chance you may have OID (or need it to help deploy another Oracle application like Oracle Portal) and thus this will help increase the value of that solution.

In Summary:

• OVD is useful in avoiding unnecessary synchronization by leveraging existing data
  
• OID has unknown potential as a way to store extended AD attributes that otherwise would increase time needed to deploy new applications.

Today is a day it catch up on some blogging.

James McGovern posted a few questions on our new operating system security product - aka Oracle Authentication Services for Operating Systems or OA4OS.

First quote - " On one level, this feels like a good story, but on another it feels like a long-term trap."
It's just a good story :). There is no trap. Unlike competing solutions - we don't use any proprietary hooks or changes to the Unix /Linux systems. We are using all standard - based interfaces like PAM, NSS and SUDO.

Thus it would be possible to move to another directory solution.

Second quote - "First, if you are running Solaris, this you can setup NIS domains to aid in this problem."
NIS has been out of favor for a while. It has now been officially deprecated. And for the kicker - it is not SOX compliant.

Thus many customer's we've talked to about OAS4OS are specifically looking for how to replace NIS. This is one of the features we offer.

Third quote - "Consider that if you are a shop running Active Directory, Microsoft
provides Active Directory Services for Unix where by you can have Unix
servers and daemons participate as if they are native to the Windows
domain. This simplifies administration significantly, cheap to rollout
and even cheaper over the lifetime. There are of course some features
missing, which Microsoft will be addressing in upcoming releases."

Yes - Microsoft does offer this. However, it has many limitations that in many organizations will not be solvable. For starters - you must extend AD schema - in many organizations this is not allowed by corporate policy. Second, by storing this data this can add severe impact to your AD replication which affect desktop login (which is why this is not allowed by many corporate policies). Third - it does not auto-generate UID & GUID numbers (we do :)). Fourth - they do not have any system to allow you to address use case of where you have same username but different uid/gid numbers on different hosts (hello OVD)).  These are all features that AD lacks and some (such as schema change) will never be avoided.

Final quote- "You can also consider third party software such as Vintela and Centrify
which also provide deeper Unix/Linux integration to Active Directory.
Anyway, I humbly predict that the open source community will realize
that this type of integration should be in the box and not something
add-on and therefore will address within the next six months."

To my knowledge Vintela and Centrify require proprietary components and/or extensions to AD. Also they don't provide any mechanism to manage SUDO policies in your directory.  And I would also point out that this if our first release (if he can mention MSFT updating AD as being OK, I can use it hear for us too :)) so we are going to be adding in additional functionality in the future.