You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2007/07/04 19:40:13 UTC
What to do about remote login in geronimo 2.0/openejb 3.0?
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
Re: What to do about remote login in geronimo 2.0/openejb 3.0?
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 7/4/07, David Jencks <da...@yahoo.com> wrote:
> 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?
I read it a couple of times, but honestly I couldn't understand it as
much as I wish. If you got something working I think that it's time to
include it now as there will not be a better time to do it. Every
release will put on us an additional burden to maintain backword
compatibility. If you think it's necessary, I'm fine introducing it
now and include a note in RELEASE NOTES what steps are necessary to
upgrade Geronimo to the latest version.
As to OpenEJB, I see it as ready to be shipped as 3.0 (with some
rather small obstacles that prevent us doing it now) and would rather
avoid introducing new (revolutionary?) stuff into it.
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: What to do about remote login in geronimo 2.0/openejb 3.0?
Posted by David Blevins <da...@visi.com>.
On Jul 6, 2007, at 10:49 PM, David Jencks wrote:
>
> On Jul 6, 2007, at 10:15 AM, David Blevins wrote:
>
>> On Jul 5, 2007, at 5:44 PM, David Jencks wrote:
>>
>>> I'd like to modify the use of the openejb AuthenticationRequest
>>> to include a security realm name. Then we can use the openejb
>>> authentication request protocol to request an identification
>>> token from the server and put it in the client subject so calls
>>> to openejb can use it.
>>
>> This would be fine. Alternatively you can do like is done behind
>> the scenes in windows for example and concatenate the domain
>> (realm) onto the user name then pull them apart on the server side.
>>
>> Generally the contents of AuthenticationRequest bothers me as it's
>> the only place in our protocol where we force a username/password
>> paradigm. The rest of the protocol including
>> AuthenticationResponse simply passes back Object which only needs
>> to be understood by the SecurityService impl that created it and
>> possibly by the IdentityResolver but is guaranteed not to be
>> introspected upon anywhere else.
>>
>> I couldn't think of a way to open that up without too many more
>> moving parts in the security setup so I just left it simply
>> hardcoded to user/pass. Would like to fix that someday.
>
> Yes, me too. I'm still thinking about it.
>
> I opened OPENEJB-605 and attached a patch with my proposed
> modification. I think I can get all the tests to pass at once with
> this plus some geronimo changes -- we'll see if I have time to
> attach that patch before I jump on a plane.
Looks fine to me.
-David
Re: What to do about remote login in geronimo 2.0/openejb 3.0?
Posted by David Blevins <da...@visi.com>.
On Jul 6, 2007, at 10:49 PM, David Jencks wrote:
>
> On Jul 6, 2007, at 10:15 AM, David Blevins wrote:
>
>> On Jul 5, 2007, at 5:44 PM, David Jencks wrote:
>>
>>> I'd like to modify the use of the openejb AuthenticationRequest
>>> to include a security realm name. Then we can use the openejb
>>> authentication request protocol to request an identification
>>> token from the server and put it in the client subject so calls
>>> to openejb can use it.
I updated the AuthenticationRequest constructor to basically match
the SecurityService.login(realm, user, pass) signature.
Also move the "PropertiesLogin" string from the code in the client
into the SecurityService impl so people could configure what they'd
like used as the default. It was in the SecurityService before but
not really configurable as it should have been.
I like the version byte you added to RealmPrincipalInfo. I added
something similar in v2 which needs to be ported, but I also like the
idea of adding a byte to each request, response and metadata object.
Good idea.
-David
Re: What to do about remote login in geronimo 2.0/openejb 3.0?
Posted by David Jencks <da...@yahoo.com>.
On Jul 6, 2007, at 10:15 AM, David Blevins wrote:
> On Jul 5, 2007, at 5:44 PM, David Jencks wrote:
>
>> I'd like to modify the use of the openejb AuthenticationRequest
>> to include a security realm name. Then we can use the openejb
>> authentication request protocol to request an identification token
>> from the server and put it in the client subject so calls to
>> openejb can use it.
>
> This would be fine. Alternatively you can do like is done behind
> the scenes in windows for example and concatenate the domain
> (realm) onto the user name then pull them apart on the server side.
>
> Generally the contents of AuthenticationRequest bothers me as it's
> the only place in our protocol where we force a username/password
> paradigm. The rest of the protocol including
> AuthenticationResponse simply passes back Object which only needs
> to be understood by the SecurityService impl that created it and
> possibly by the IdentityResolver but is guaranteed not to be
> introspected upon anywhere else.
>
> I couldn't think of a way to open that up without too many more
> moving parts in the security setup so I just left it simply
> hardcoded to user/pass. Would like to fix that someday.
Yes, me too. I'm still thinking about it.
I opened OPENEJB-605 and attached a patch with my proposed
modification. I think I can get all the tests to pass at once with
this plus some geronimo changes -- we'll see if I have time to attach
that patch before I jump on a plane.
thanks
david jencks
>
> -David
>
>
>
Re: What to do about remote login in geronimo 2.0/openejb 3.0?
Posted by David Blevins <da...@visi.com>.
On Jul 5, 2007, at 5:44 PM, David Jencks wrote:
> I'd like to modify the use of the openejb AuthenticationRequest to
> include a security realm name. Then we can use the openejb
> authentication request protocol to request an identification token
> from the server and put it in the client subject so calls to
> openejb can use it.
This would be fine. Alternatively you can do like is done behind the
scenes in windows for example and concatenate the domain (realm) onto
the user name then pull them apart on the server side.
Generally the contents of AuthenticationRequest bothers me as it's
the only place in our protocol where we force a username/password
paradigm. The rest of the protocol including AuthenticationResponse
simply passes back Object which only needs to be understood by the
SecurityService impl that created it and possibly by the
IdentityResolver but is guaranteed not to be introspected upon
anywhere else.
I couldn't think of a way to open that up without too many more
moving parts in the security setup so I just left it simply hardcoded
to user/pass. Would like to fix that someday.
-David
Re: What to do about remote login in geronimo 2.0/openejb 3.0?
Posted by David Blevins <da...@visi.com>.
On Jul 5, 2007, at 5:44 PM, David Jencks wrote:
>
> On Jul 5, 2007, at 12:03 PM, David Blevins wrote:
>
>> How were we doing web services security before? Did it work for
>> EJBs too? (maybe that was the issue).
>
> Web services security works and worked fine. AFAICT it's using
> BASIC web authentication. Anyway we tell the web services client a
> user and password and it gets sent with the message and logged in
> and everything works. The user/pw comes out of a private
> credential in the Subject. In order for this to get into the
> Subject we need a login module running locally on the client to put
> it there. All this is working fine and has worked fine for a long
> time.
>
> The problem is that in order to call an ejb we (currently) need
> remote login modules on the client that are actually running on the
> server and get the identification principal back to the client
> subject. We seem to be able to configure logins that use either
> only remote modules or only local modules but I haven't been able
> to figure out how to configure something that uses both a local
> login module for the web services AND in the same login
> configuration a remote module for openejb.
Hmm. I can definitely see similarities and what you're feeling
around for. The paradigm is essentially the same on the client-side;
pull user/pw from userland, then put it in a known code location
(subject, static) where it will be fished out on request. The server-
side is also the same being a plain user/pw login. Could be possible
not just to use the same login configuration but the same login module.
> I also find the code and configuration around remote login modules
> to be incredibly hard to understand and confusing so I'd rather
> come up with something that appears to involve a little less magic.
Amen.
>>
>> I really lost you when you stated an issue with web services
>> security then jumped to solving the problem in the protocol that
>> doesn't use web services. I can't figure out how these things
>> connect.
>
> Just possibly the above will help :-)
>
> Anyway after perusing the jaspi spec some more I don't want to
> promise to implement it by geronimo 2.0 so I'm now trying option
> (0) and hope to have a proposed patch friday. [...] I think this
> special purpose solution will be a lot simpler and easier to
> understand than the geronimo code and will work fine while we think
> about jaspi.
Sounds like a plan.
-David
Re: What to do about remote login in geronimo 2.0/openejb 3.0?
Posted by David Jencks <da...@yahoo.com>.
On Jul 5, 2007, at 12:03 PM, David Blevins wrote:
> On Jul 4, 2007, at 10:40 AM, David Jencks wrote:
>> 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.
>
> Took me a couple times through reading this and I get the proposed
> changes, though I did not follow the above part where you explain
> the issue. I guess I'd like to understand the parameters of the
> problem better before moving on to resolution details.
>
> Not so much a concern more curious, was this an issue during G
> certification that just didn't have an affect on certification or
> has something changed since then and this is a new issue?
>
> How were we doing web services security before? Did it work for
> EJBs too? (maybe that was the issue).
Web services security works and worked fine. AFAICT it's using BASIC
web authentication. Anyway we tell the web services client a user
and password and it gets sent with the message and logged in and
everything works. The user/pw comes out of a private credential in
the Subject. In order for this to get into the Subject we need a
login module running locally on the client to put it there. All this
is working fine and has worked fine for a long time.
The problem is that in order to call an ejb we (currently) need
remote login modules on the client that are actually running on the
server and get the identification principal back to the client
subject. We seem to be able to configure logins that use either only
remote modules or only local modules but I haven't been able to
figure out how to configure something that uses both a local login
module for the web services AND in the same login configuration a
remote module for openejb. I also find the code and configuration
around remote login modules to be incredibly hard to understand and
confusing so I'd rather come up with something that appears to
involve a little less magic.
I'm not entirely sure why the tests in question were passing before
my "All subjects come from logging in" change, but I suspect we had a
default subject configured that was allowing the web services access.
>
> I really lost you when you stated an issue with web services
> security then jumped to solving the problem in the protocol that
> doesn't use web services. I can't figure out how these things
> connect.
Just possibly the above will help :-)
Anyway after perusing the jaspi spec some more I don't want to
promise to implement it by geronimo 2.0 so I'm now trying option (0)
and hope to have a proposed patch friday. I'd like to modify the use
of the openejb AuthenticationRequest to include a security realm
name. Then we can use the openejb authentication request protocol to
request an identification token from the server and put it in the
client subject so calls to openejb can use it. I think this special
purpose solution will be a lot simpler and easier to understand than
the geronimo code and will work fine while we think about jaspi.
thanks
david jencks
>
> Any help in understanding would be greatly appreciated.
>
> -David
>
>
>
Re: What to do about remote login in geronimo 2.0/openejb 3.0?
Posted by David Blevins <da...@visi.com>.
On Jul 4, 2007, at 10:40 AM, David Jencks wrote:
> 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.
Took me a couple times through reading this and I get the proposed
changes, though I did not follow the above part where you explain the
issue. I guess I'd like to understand the parameters of the problem
better before moving on to resolution details.
Not so much a concern more curious, was this an issue during G
certification that just didn't have an affect on certification or has
something changed since then and this is a new issue?
How were we doing web services security before? Did it work for EJBs
too? (maybe that was the issue).
I really lost you when you stated an issue with web services security
then jumped to solving the problem in the protocol that doesn't use
web services. I can't figure out how these things connect.
Any help in understanding would be greatly appreciated.
-David