Entries Tagged 'Directory' ↓
December 20th, 2006 — AuthN, Directory, Penrose, Use Case
How does virtual directory relate to single-sign on solution ? Why do you need a virtual directory when you have SSO ?
They say a picture is worth 1,000 words. So here are four pictures for you.
Picture 1: before SSO
Picture 2: After SSO
As you can clearly see, an SSO solution removes multiple authentications so that a user doesn’t need to type (present) his credentials every time he accesses an application.
The nature of SSO implies that there will be only one central repository for user information and credential, preferably within an LDAP server. So, any additions, modifications, etc. of user information and credentials will have to be performed within this central store.
The reality is far from this simple concept, as described in this excellent blog from Radovan’s single directory paradigm.
This is where virtual directory technology comes to the rescue.
Picture 3: Here’s the picture before a virtual directory
Picture 4: Here’s after a virtual directory
The ultimate goal of a virtual directory is to create a single account (virtualized/centralized) for a user, which is obviously a real improvement.
Single account (end goal of a virtual directory) is not equal to single authentication (end goal of an SSO solution).
Make sense? Please feel free to chime in.
July 26th, 2006 — Directory
Let say your company utilizes CRM system which contains all your customers information. Penrose allows you to repurpose that informaton and turn-it into a global address list (GAL).
You can then use your favorite e-mail client, such as Microsoft Outlook or Mozilla Thunderbird, to use that global address list as a central/shared address book.
November 29th, 2005 — Directory
Identity Management Map November Edition is available. I will be revising it in the next few days. It is more readable now with the additional cloud coloring. HTML version with an image map is also available.
November 12th, 2005 — Directory
I have met many people along the way who scoff writing an LDAP server implementation in Java. Some of the reasons are:
Java is slow! LDAP server needs to be fast. Java and LDAP don’t go together.
Have you ever heard OpenLDAP?
Who want to build infrastructure software, it’s boring.
Their reasonings are valid, but myopic. I will expound this on a follow-up topic.
ApacheDS Project has gone thru incubation process for 18 months and graduated only a few months ago (March 2005). It has been steadily gaining a community. You can take a peek at its chatter log. The project is led by a good friend of mine, Alex Karasulu, who is not only passionate but has a unique ability to bring together various passionate developers together. (Check out these testimonials)
I lead an open source virtual directory project called Penrose which utilize Apache DS as its protocol layer (LDAP). Penrose leverages ApacheDS project for many reasons. Our goal was to add new functionalities to a plain ol’ LDAP server, namely virtualization, synchronization and federation (what Burton Group called “Identity Data Service“), and doing so without reinventing the wheel. Take a look at the following numbers:
lines of code in ./apacheds/trunk = 84606
lines of code in ./asn1/trunk = 30137
lines of code in ./authx/trunk = 9553
lines of code in ./clients/kerberos/trunk = 867
lines of code in ./clients/ldap/trunk = 10420
lines of code in ./naming/trunk = 17139
lines of code in ./network/trunk = 20323
lines of code in ./protocol-providers/changepw/trunk = 2842
lines of code in ./protocol-providers/dhcp/trunk = 4858
lines of code in ./protocol-providers/dns/trunk = 6825
lines of code in ./protocol-providers/kerberos/trunk = 3772
lines of code in ./protocol-providers/ldap/trunk = 2193
lines of code in ./protocol-providers/ntp/trunk = 1598
lines of code in ./sandbox/trunk = 31889
lines of code in ./sandbox/trunk/apseda/trunk = 15176
lines of code in ./sandbox/trunk/kerberos-sam/trunk = 1325
lines of code in ./sandbox/trunk/osgi-spec/trunk = 5083
lines of code in ./sandbox/trunk/protocol/trunk = 583
lines of code in ./shared/kerberos/trunk = 13331
lines of code in ./shared/ldap/trunk = 124599
lines of code in ./shared/protocol/trunk =
lines of code in ./standalone/trunk = 3161
lines of code in ./testsuite/trunk = 3004
Total: 393284
85K in apacheds core (Server Code) + 125K in ldap-common (Shared Code) + 30K in ASN.1 (Shared Code) = 240K lines of code for LDAP ONLY!!
It may not be anywhere close to 50M LOC, but maintaining and re-factoring a 250,000 LOC code is still a pretty challenging undertaking. Jboss codebase is about 500,000 LOC and requires more than 30 dedicated developers to maintain it. Penrose code is about 70,000 LOC. Had we chosen to implement our own LDAP server; we would be maintaining a total of 310K LOC ourselves.
November 1st, 2005 — Directory
Cache is King is an important read for understanding how cache plays role in a virtual directory. Without it, a virtual directory is simply an LDAP proxy/router. Future versions of Penrose will add a persistent cache and a synchronization service.
Cache is Evil is also an important read emphasizing the benefit of a having dynamic access functionality.
IMHO, “Virtualize if you can, synchronize if you must” is a good rule of thumb in designing multi-site and complex directory system.
