Maybe you have a single-sign-on application that runs on the client platform, takes the user credentials and authenticates to the server retaining the connection handle. Each subsequent application could request that your sign on application query the server for an attribute that is associated with the new application. These attributes could have ACL's applied to them to disallow access to all but those allowed to access them. The sign on app can then return success or failure to the calling app, approving the activity or not.
For a website, you could build a hierarchy in LDAP matching your URL's. ACL's could be applied to each node. Your "browser" app would run through the approval stage for each page before navigating.
This scheme has some obvious security problems, but I think they are pretty obvious. When your security is in the client, it's susceptible. Maybe it can serve as a catalyst for something that will work for you.
From: Thomas Gagne [mailto:email@example.com]
Sent: Wednesday, August 15, 2001 4:15 PM
To: openldap list
Subject: Single Signon
I figure for this to work, there must be a way for LDAP clients to determine
if a user is logged-into the system. There probably also has to be something
unique the user's client can pass my application so I can compare it with
something stored in LDAP to see if they're the same--to get around people
masquerading as users already logged-in.
Has anyone done this with LDAP and has suggestions on how to do it? I'd like
for our web application and our transaction processor to share the same login,
and not have to badger the user twice for a password.