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
|