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
