LDAP against BEA identity

Question

This may sound...odd...but I swear there's a legit business reason. :)
Situation:
==========
* I have ~5 auth sources
- BEA DB ("native" users)
- ~4 separate LDAP sources
* Read: no central user store
- auth sources are confusing to users
- very difficult to resolve integration with external services as portal is never truly able to integrate with 3rd part apps that assume we use a central AD/LDAP user store
* I want to provide a way to solve the second bit of that problem, but ... realistically... I won't be able to fix it the right way by getting a central store set up.
- central store not possible given our IT and business constraints
- setting up my own store creates other issues
My dumb idea
===============
I'm wondering. Has anyone ever considered authing against the portal natively over LDAP? Process might work like...
1) Portal replicates users from multiple sources, etc. (it knows where to phone home for synch/auth per user)
2) Configure a web service that mimics LDAP interfaces such that systems can synch and auth against the portal
- does a search against user name (in theory, finds user - realize you could get duplicate matches)
- knows the "true" auth source for that user (database, ldap, ad, whatever)
- passes on provided credentials to "true" auth source
This may sound stupid, but my thought is that if the portal can become the central point of aggregation for apps, profile data, etc. and is being pushed as a nice bridge between all these places, why not set it up to also be the bridge for the "federated" identity management problems that prohibit us from integrating 3rd party apps that rely on a central LDAP/AD store shared by those apps and the portal. Basically, the portal becomes the user store "glue."
Yeah - it would be slow. Not as worried about that atm :)
Just kinda seeing if I'm the only one facing this problem and if there are other options

Answer 1

Hi Eric,
I understand where you're coming from. You don't necessarily control the "guts" of the authentication and authorization code for the third-party application and it is expecting a single central user repository like LDAP or AD. You want Plumtree to be that repository (which would allow you to use any number of LDAPs or ADs AND native Plumtree DB users as well) by sync'ing with all the user repositories and then "brokering" authentication to the correct repository based on which repository was used to sync the given user.
Here's a 10,000-foot view of how I would build this.
You'll need the following ingredients:
1) One or more LDAP and/or AD auth sources
2) A custom SSO or Login solution
3) A portlet "container" that gets credentials, calls the authenticator web service, and then redirects to the portlet application
3) An authenticator web service running on a machine that has access to the server APIs (plumtreeserver.dll)
First, bring all your users and groups in using the LDAP and AD auth sources. Create the necessary Plumtree DB users as well.
Next, build a custom SSO or customized Login solution that will (ideally, log the user in automatically) capture their username, password and auth source id and send these values to portlets. That's accomplished very easily in custom SSO by putting the headers or cookies into an array, which instructs the portal to forward them to the portlets. However, if you customize login, you can set these settings as personal settings in Login or in one of the Login PEIs and then configure them to be sent to the portlets as User Settings. If you don't know how to do this, let me know and I'll walk you through it.
Next, configure a portlet "container" of sorts. This "container" will call the EDK to get the username, password and auth source, call the authenticator web service* to re-authenticate the user, and then redirect the request to eRoom (or whatever application you're trying to integrate).
*The authenticator web service will be the hardest peice of this puzzle to write. You'll need to use the auth source id sent down by the container to figure out which auth source to use, then crack open the auth source to get the settings out of the property bag, and then manually authenticate the user and return success or failure to the caller.
Theorically, all this sounds great -- albeit a little complicated. If any of it doesn't make sense, let me know. I'm always up for a challenge, so if you want me to help you write some or all of this stuff, I'm game. (Read: will work for food and/or alcohol. :-)
Regards,
Chris Bucchere | bdg | [email protected] | www.bdg-online.com