[Opensource] LDAP-Expresso and missing elements in DTD

Michael Rimov mrimov at jcorporate.com
Thu Jun 6 12:51:56 PDT 2002


At 03:43 PM 4/17/2002 +0200, you wrote:
>Hi
>
>I'm currently working on integrating expresso with our LDAP server by 
>using the UserLDAP
>I suspect that the expresso-config DTD is not correct, should be (?):
>
><!ELEMENT context (description?, hasSetupTables?, jdbc?, type-mapping*, 
>images, startJobHandler?, showStackTrace?, mailDebug?, customProperty*, 
>path-mappings*, expressoDir?, setupDefault*, ldap?)>
>(the userInfo element is also missing)


Andreas,

Ok, so this is an old email, but at first I thought that this was simply a 
DTD but.  I was just getting to fixing it, but it turns out in reality that 
what you want to do is define a

<class-handler name="userInfo" 
classHandler="com.whatever.your.userinfo.object.is>

You can also include specific handler parameters if you want your 
classhandler to have certain configuration options.

>It also looks like I have to modify the CheckLogin init method in order to 
>support single sign on and J2EE declarative security
>Maybe something like this:
>
>// if GenericSession.getAttribute(request, "CurrentLogin") == null
>             Principal principal = request.getUserPrincipal();
>             if (principal == null) {
>                 logInAsNone(request, forceDB);
>             } else {
>                 String    uid       = principal.getName();
>                 // TODO: find user information in LDAP - using the 
> UserLDAP class ?
>                 CurrentLogin myLogin = new CurrentLogin(uid ...);
>                 GenericSession.setAttribute(request, "CurrentLogin", 
> myLogin);
>             }

The concept looks pretty good, although I haven't studied the JAAS spec 
enough to say for sure whether or not it would work as intended.  But Brian 
Showalter was going to do something similar to allow for container managed 
security, so I suspect we're in the right ballpark.

I think one problem we're going to have is that currently the integer uid 
must uniquely map to the login name somehow.  This works great for our 
database based login system.  In fact it's much more efficient than string 
based user keys.  The problem comes in with integrating with other systems 
that are not integer UID based.  I haven't figured out a good bridge 
mechanism yet, so if anybody has developed a good one, then I'd like to 
hear from them.

Sorry that it took so long to reply to this message.

                                                 -Mike




More information about the Opensource mailing list