geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject What to do about remote login in geronimo 2.0/openejb 3.0?
Date Wed, 04 Jul 2007 17:40:13 GMT
We've run into a bit of a problem with javaee app clients and  
logins.  We need the same security configuration to support both  
remote access to openejb and web services security.  Remote access to  
openejb currently requires a "remote login" that ends up with an  
identity token on the client that is sent to openejb in each request,  
and that openejb uses to look up the previously logged in Subject.   
The web services security involves the client login configuration  
putting a private credential containing the username/password to use  
for the web services call into the Subject.  I can't figure out how  
to combine a "server side" login module that produces the identity  
token with a client side login module that produces the private  
credential.  If I can't figure out how to do this I have some doubts  
many of our users will be able to figure it out either.  I things  
there's general agreement that the remote login mechanism is a bad  
idea and should be removed in favor of some kind of security  
assertion idea.  I really don't like how the remote login occurs over  
a completely different channel than the openejb remote calls themselves.

I've been working on this for a while and have (maybe "had" before I  
got overly enthusiastic) a couple of things working and thought I'd  
outline our options as I currently see them:

0. (minimal) Write an openejb remote login module that does a remote  
login to openejb using the openejb protocol and puts the resulting  
identification info in a principal or (I'd prefer this) a private  
credential.  This would avoid the mystery of setting up mixed client- 
server login modules (2) by putting the "remote" into a specific  
login module rather than a lot of geronimo infrastructure.

1. (close to minimal)  Modify the geronimo IdentityResolver and  
SecurityService to always send a user/pw in a secure request and  
login on each request.  security realm could be determined from a  
system property.  This requires no changes to openejb (I think) but  
nearly hardcodes the security realm to use.  It also is really slow  
for multiple requests since each request has a separate login.  (I  
had this working before I got distracted by (5), it's easy to do)

2. (I can't figure out how to do this).  Set up a mixed client-server  
login config on the app client that uses geronimo remote login to get  
a indentification principal from the geronimo server and a local  
login module to add the names private credentials needed for jaxrpc/ 
jaxws.  I'm a bit worried about this option... if I can't figure out  
how to set this up it may not be too easy for our users.

3. modify the openejb protocol to allow shipping a security object  
back in a response, and modify the IdentityResolver and  
SecurityService interfaces minimally to support specification of the  
security realm you want to use and fish the identification principal  
out of the response.  This should be slightly faster than what we do  
now (one less round trip) but postpones authentication until the  
first ejb call.  I like this but at least Dain doesn't.

4. Modify the openejb protocol and interfaces to be jaspi-friendly  
but not actually implement jaspi right now

5. Actually write a jaspi implementation for geronimo/openejb.

I may be getting distracted by shiny objects but I'm working on 4 and  
5.  AFAICT this is definitely going to change the openejb protocol to  
include a security object in responses and the openejb  
IdentityResolver and SecurityService interfaces, so if this is not  
acceptable I'd rather know this sooner than later.  I'd expect that  
openejb would eventually want to support jaspi so before 3.0 is  
actually released seems like a better time to have modifications than  
say 3.1.


david jencks

View raw message