Clayton Donley

Author
+ Follow
since Mar 03, 2003
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Clayton Donley

Here is an example using JNDI (included with Java 1.3 and above and available for download with older versions of Java). I've thrown in some comments that walk through what it does a bit.
This program does a simple LDAP search for the root entry in the directory. It doesn't print anything fancy, but shows the general process of searching and retrieving results.

(edited by Cindy to format code)
[ March 21, 2003: Message edited by: Cindy Glass ]
21 years ago
Manning has put up two free chapters for preview from my book. One gives an overview of LDAP and one is specific to security with some Java-based examples. The link to the Manning page is in my signature and you can get the sample chapters in the link on the left side of the page.
One place that you might want to look at for more general answers is the OpenLDAP FAQ-O-MATIC. There is a whole section on General LDAP FAQ which covers many of the kinds of questions I've seen here, including the directory vs. database questions (see here). OpenLDAP is at http://www.openldap.org/.
There are many other resources out there. A search on Google or such will usually turn up good stuff.
Clayton
21 years ago
You're doing it about the only reliable way to do it. The only issue is that with LDAP if you are doing a modify and want to track state in case another part of the operation fails and you need to roll back, the state of the entry on the server may have changed on the server from another connection so the rollback could fail or cause undesired results to exist within the server.
However, it really depends on how much concurrent access you are dealing with and the data that is being changed on the LDAP side. Certainly in some designs the risk above is not very important because of the nature of the change and the infrequency of likely conflicts. You would be covered in most cases because at least you would be rolling back to something that was likely valid in the directory in the last few miliseconds.
Clayton
21 years ago
There are a couple ways you could do this.
One way would be synchronization. If going from the database to the directory, this could be done by creating a database trigger that feeds you changes as they happen (or places them in a change table), allowing you to use that list of changes to propagate the change to Active Directory.
An alternative when going from DB to LDAP is to suck down all of the contents of the database on a periodic basis (depending on size and change rate) and use the delta between contents to perform LDAP changes. I have a few basic examples of doing this using Perl in the directory integration chapter in my book as well, though probably not complete enough to put into production without some exception management. Such processing could easily be done in just about any language. This is less invasive with the database, but obviously could be too much overhead and offer too much lag between updates to be useful to you.
Certainly in a large enough environment you might be able to justify the expense of a meta-directory to do the synchronization for you. If you're using Active Directory and a lot of Microsoft stuff (C# sounds that way to me) you could look into Microsoft Metadirectory Services (MMS). I'm told that the 3.0 version is based on underlying database technology and is really good. Not sure how well it integrates with Oracle, though.
Clayton
21 years ago
Hello,
It really depends on what you currently have in your database.
If you mostly just associate users with various roles or such within the database, you might be able to simply create various groups to correspond to those various roles. One class that could be used for this purpose is the groupOfUniqueNames class. One could list the people that have that role by listing them inside those group entries.
The alternative is to associate that the user-related authorization information directly within the user entries by extending the inetOrgPerson class or such.
If you are storing information about authorization targets, or roles that associate users/groups, actions, and targets, you'll not find a lot of widely used LDAP schema that can be reused with off-the-shelf components, though this doesn't limit you from using LDAP for this purpose (Netegrity and other products do exactly that).
Clayton
21 years ago
When you upgrade the connection it creates an SSL tunnel on top of the plain socket and puts all subsequent operations inside that tunnel. However, you will get the performance hit mentioned above at the time when the connection is upgraded, so this is only REALLY useful if much of what you are transfering can be passed in the clear and only some connections must be secure. This allows the client to select the level of security it wants to use, potentially avoiding some SSL overhead. In fact, some newer access control systems in the directory servers themselves allow you to set access controls based on the session's security in addition to typical user, group, and similar criteria.
Clayton
21 years ago
Hi,
I actually used to do consulting with the Policy Director product for IBM back in '99 and 2000.. it's changed considerably lately (removed dependencies on DCE, which used to make installation pretty tricky).
The WebSeal component is basically a proxy server that sits between a web browser and a destination web server/application server. I have another reply on a topic in the last day related to single sign-on that talks about this type of SSO/Policy Service product and how it works. Let me know if I can shed any more light on how this works.
I should point out that unlike some other products, IBM/Tivoli allowed you to use the same framework using Netseal with client/server applications, though because these are not web-based, implementing it was a little more invasive.
Clayton
21 years ago
Not being relational, LDAP doesn't have the concept of subselects. If the subselect contained multiple UID values that you wanted to retrieve, you would in fact have had to do multiple searches to retrieve all of the matches that would have been retrieved via the statement above.
While this may seem like a limitation, it really comes down to this functionality being outside the scope of what LDAP is suposed to provide.
Clayton
21 years ago
Another way of thinking about the LDAP vs. DB argument really comes down to what already exists. In an Internet environment you may have the luxury of creating a whole new registration system for new users. If you're creating an intranet focused application there may already be a lot of user information in places like Active Directory (Windows Accounts), Domino Server's directory (email accounts), Sun/Netscape directory (email and some apps), etc...
In those cases it's less an issue relevant to application functionality as it relates to security than it is an issue of fitting into what the organization is already maintaining and supporting. Creating something that fits into existing directory environments will certainly simplify the deployment phase to some extent.
Obviuosly if you're talking about an environment where there aren't a lot of existing user repositories, or where the users are in directories, you might make a different decision.
Oh, and the decision doesn't have to be LDAP or DB. In fact, not only can you synchronize them, you can also use LDAP on top of your database tables if you have an LDAP-enabled application by using virtual directory products that translate LDAP into SQL. Unlike LDAP directories built on Databases (Oracle and IBM for example), these products map to your existing tables rather than create new LDAP-specific tables.
Clayton
21 years ago
Exactly, David. Every time I hear about performance as the reason to pick LDAP over database, I typically cringe because most sites and such would probably have a hard time maxing out performance on Oracle, DB2, Mysql, etc... simply with the load generated from user logins (particularly if the user is given a session id of sorts after the initial login).
I think it really comes down to the application and environment. If you're using off-the-shelf products or components that can support LDAP for authentication, you'll probably get a lot more reuse of the LDAP directory. Particularly if you expect that additional applications or components will be deployed later tat could use that same directory, removing the need to somehow provision users in multiple databases.
I will agree that I'd generally keep the user-related authorization information where I keep the user information. Policy information (related primarily to the resource being accessed) can be stored pretty much anywhere, though.
As many of the other threads in the last few days have noted, just because you need user information in the database doesn't mean you can't also have some of that information in a directory if a directory makes sense from an authentication/authorization standpoint and the database will be used for generating reports or associating users with orders, etc...
Clayton
21 years ago
What it really comes down to is using something the way it was designed to be used.
I've actually seen LDAP servers that could do higher numbers of writes with a trade-off a bit on reads and such. However, even here, the issue becomes that often when people are looking for high numbers of writes, they're usually looking to do something that would require some level of transactional capabilities.
For example, one issue that I see pop up on the OpenLDAP lists every once in a while is something like "how do I increment a counter with LDAP?" The problem is that there is no way to specify a single atomic operation in LDAP that will both read the existing value and write the new value without the risk that someone else will read the same value between the time that the entry read and changed by the first set of operations. In a database this is all very easy.
While we could call these limitations, what it really comes down to is something outside the scope of the standard. LDAP really was never intended to do complex sequences of data manipulations. In fact, it's earliest use wasn't even security, it was primarily to provide phone and email type user lookup information to client applications on various platforms back in the days before the web made this easy by simply using a browser.
It's still used for that purpose, but clearly security has taken over as the primary reason to deploy new LDAP-enabled directories and consolidate existing directories with security information.
Clayton
21 years ago
I wish there was a positive answer.
Even with JSSE and JNDI performance is horrible when creating new connections. One thing that I've liked about some recent versions of servers and at least the latest JNDI in Java 1.4.1 (not sure if JLDAP has it yet) is the StartTLS operation. This at least offers the option of only upgrading the session to SSL when it is really needed.
Clayton
21 years ago
Not in the sense of say...a Windows registry, though there are some applications that will allow you to change their preferences and such by reading their configuration or user personalization information out of a directory.
LDAP is sometimes talked about when the topic of web services/component registries come up, but LDAP is usually used under the covers in those cases and the developer would use a protocol like UDDI via some non-LDAP APIs.
Clayton
21 years ago
When Netscape was bought by AOL, AOL and Sun formed the iPlanet aliance to sell their various server products. As part of that they both got ownership of various intellectual property related to the directory server. At around the time that 5.0 came out, the alliance ended.
The Netscape 6.0 product is the one sold by AOL, while Sun sells both the Sun One Directory. The only real differences I saw the last time I looked at the Netscape version was that it offered the ability to tie in and see AOL screen names and such. This may have changed since the last time I looked. It is my understanding from various people at Sun that the new Sun 6.0 product will be substantially different from the current Sun and Netscape directory products and obviously without the iPlanet alliance, AOL/Netscape will likely not be making those same changes and the products will become much different.
Clayton
21 years ago
Someone was developing an open source tool, but I can't seem to find the link anymore with a Google search. The commercial ones are a bit pricey, but worth it if you have many environments (particularly ones that require specialized skills to connect to).
Some vendors with full-blown provisioning solutions would be Business Layers, IBM/Tivoli, Waveset, and Thor.
If you're just looking to do an LDAP server plus Active Directory, you could probably cobble together what you need by extending a few of the LDAP management tools out there to change multiple directories from a single change.
Clayton
21 years ago