Virtual Identity Dialogue

Jackson Shaw responded to my post on OS security.

I have not yet updated any of test AD servers to R2 and thus wasn't aware that AD automatically was updating the schema to support NIS. I am familiar with the RFC but this is a repeated concern I do hear from customers - "we can't extend our AD schema". I literally hear this on a daily basis but this could be because we are one of the few options out there that can help customers who can't extend their AD schema.

I also learned something new - that others are supporting SUDO policies too. :) I didn't mean for my post to be obvious FUD on this feature. I'm still coming up to speed on the competitive landscape for OAS4OS myself (other members of the PM team primarily running that show while I have been concentrating on other areas that I can't yet publicly discuss - but since I am the more outbound focused PM on directory services team - I am talking more about it now).

In short - let me just say where I think organizations may get the most out of OAS4OS:

1  - Simplified installation of secure (e.g. SSL/TLS setup which apparently is pretty nasty manually) PAM and related configuration
2 - Migration tools from local/NIS to LDAP
3 - Support for managing user UNIX footprint outside of AD but keep password in AD (for those who can't or don't want to extend AD schema)
4  - Increase utilization of an existing OID deployment (for example if you have Oracle Portal - you have to have OID - thus could potentially get an increased ROI by using OAS4OS)
5 - The OAS4OS  is currently provided as a feature of the Oracle Directory Services or Oracle Identity & Access Management license(s)


.

So James has responded back to me on ADAM.

"I would love to know your thinking on why a database itself can't be
exposed via the LDAP protocol? For example, what would prevent
Microsoft from allowing SQL Server
to be accessed by not only the TDS protocol but also LDAP? The code
required to make this happen, wouldn't be too difficult for a talented
team to get right. Of course, if you have less talented individuals
then performance or other factors may emerge. Anyway, by putting it
into the DB itself, wouldn't it help customers avoid purchasing yet
another product with yet another support model?"

The point isn't to just use DB for LDAP. The purpose is that you have existing databases (which could be Oracle, SQL Server, DB2, MySQL, etc) that contain existing data you wish to integrate into an identity infrastructure. OVD allows you to quickly and easily do this. And while it's technically not hard to write the back-end code to that - it does take skill and effort to make it easy to configure and support. Additionally this doesn't count for other features we have such as renaming attributes on the fly, translating namespaces and of course linking data together (e.g. user your AD username and password, but link to data stored in HR for a complete real-time picture of your identity data).

"Relational databases have always had the notion of a view and it was built-in the database without requiring an extra product. So, isn't this another scenario where Microsoft or other LDAP vendors should be thinking about views for LDAP?"

OVD does views today.. I can't speak to whether other vendors should or shouldn't do that.

"OK, so what would be the real reason why the AD schema can't be
extended? Microsoft provides all the right tools. Is it stupid thinking
in large enterprises?"

I don't disagree with the fact that Microsoft allows you to extend schema. I think there are two primary reasons why organizations don't want to extend AD schema. First is that there is not currently anyway to remove added elements. Second is the more data you add into AD, the more impact it has on AD replication. This in turn can effect desktop login performance. And thus organizations try to keep AD lean. I'm not saying you can't or shouldn't extend AD schema - I'm just pointing out that in many organizations - this is not allowed.

OK, I guess I am now officially confused. I wasn't aware that the
concept of changelog was in any LDAP standard. If ADAM doesn't
implement changelog, does this make ADAM non-LDAP compliant? I do know
that the use of changelog isn't just limited to provisioning tools and
many fugly ECM products also leverage (used in the negative sense) this functionality.

It's not standard in terms of any RFC - but it is standard in the fact that every other storage-based LDAP server provides one. I wouldn't say ADAM is not LDAP compliant. Lack of changelog does make it harder to integrate with systems who wish to replicate ADAM data. While you can use other attributes (for example modifytimestamp) the problem is that without changelog, you must reconcile the data to figure out what has changed. A changelog gives you specifically what has changed.

I guess I would ask Mark, to instead of questioning the usage of ADAM, help others outside of Oracle write better enterprise applications that bind natively to LDAP and don't require anything fugly like syncronization...

As I have expressed before - we are already doing this. OVD is one option to help with this because developers can just learn to interact with a single consistent interface instead of having to deal with different back-ends. It will be fundamental component of Oracle's "identity dial-tone" (aka Identity As A Service) concept.

We are also helping to drive a new API via Project Liberty - the Identity Attribute Service API - which is one of the Identity Governance Framework components which we hope will make it easy to use identity information on demand as developers interact with databases similar to frameworks like JDO or ADO.


 

One benefit of blogs is that you can get educated fast by your own mis-informed comments :).

Since I linked to Jackson Shaw's post, I wanted to share a quick clarification I got from a friend I have who turns out to work for Centrify and reads my blog.

"Centrify does not require any schema extensions on AD in order to integrate a non-Windows system into AD, see our FAQ http://www.centrify.com/directcontrol/faq.asp#schemaextensions.
DirectControl was designed to integrate seamlessly into Unix by
supporting the established UNIX standards you mention (�PAM, NSS and
SUDO�), as well as standards such as Kerberos and RFC 2307 assuming a
customer is using Windows 2003 R2 or installs the Microsoft R2 schema
(customers will trust Microsoft and install their schema, just not any
3rd party schema extensions). However, DirectControl can install and
operate perfectly even without schema modifications of any kind."

So to clarify all of the products in this space that I am aware of (OAS4OS, Vintella and Centrify) don't require schema extensions to AD.

Thus we'll all have to come up with different FUD to throw at each other :).

I will admit it - This post got under my skin. The summary of this post is "You can't use APEX or JDeveloper without Oracle and thus they are not really free because you must have an Oracle licensed product". And then says these can't claim to be "free" unless they work with non-Oracle technologies.

I want to take a moment to explain what "free" means here and correct some misconceptions.

For those new to these technologies - Applications Express (APEX) is an application framework that lets you build Web applications with just some PL/SQL, SQL (plus some Javscript in certain cases) and the Oracle database. It is free to use but it does require Oracle database to run (while it is part of Oracle XE - most people use it with EE or SE in production). Prior to 11g, it was a separate install but in 11g it is a default feature.

JDeveloper is Oracle's Java IDE. It is highly optimized to be used for developing with Oracle's Java related products in particular ADF (our core UI framework), Web Center (an application development framework that lets you add portal concepts (such as personalization and content from multiple sources on a single screen) to any Web applications and SOA Suite (and SOA is much more design intensive than it is code intensive thus the need for a good design tool).

Since APEX is really a way to simplify taking your existing PL/SQL knowledge and use it to build Web applications - this is clearly something that would only work against Oracle DB. While there maybe some other databases out there that might run some PL/SQL - let's just be truthful to each other an admit that people who want APEX want to run that against Oracle DB. If you are running another DB - you're more likely to go reach for another tool - probably any tool that doesn't say "ORACLE".

That being said - PHP/Ruby/Perl/.NET all run well against Oracle DB :).

JDeveloper on the other hand is a different context. While it is not open-source it truly is free to use. And while it does let you edit any Java code - frankly if you are not using any of the Oracle related Java stack - I'd probably run Eclipse (and Oracle is also active in Eclipse project). It's not that JDev wouldn't work - but you'd probably have an eaiser time with non-Oracle stack.

On the other hand - if you want to build Web-applications running against an Oracle DB - there really isn't any faster way that I know than ADF. And with the new stuff coming in 11g ADF - you will be able to do many AJAX functions without touching Javascript.

And ADF itself is based on a standard (JSF) and is donated to the Apache MyFaces project.

Finally - you probably are not looking at the Web Center and SOA Suite components unless you planning to use those products..

So in summary - You are probably only interested in APEX or Jdeveloper because you are investing in Oracle technologies (DB and/or Middleware). If you are investing in these technologies - then these tools exist to help you more rapidly develop against this stack but they are not the only tools you can use.

And there is also a rich external market out there - both commercial and open-source tool/frameworks that let you develop against Oracle too. And I hear a rumor or two that there are even other databases :).