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
