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.
Comments?
thanks
david jencks
