On 9 Oct 00, at 13:51, Oleg Nitz wrote:
> On success uLoginModule stores the set of user roles to the Subject as
> a set of public credentials (Strings)
> and the user name for beans as a Principal, so that the user name for
> beans may differ from the user name that comes from client
> (I assume that uLoginModule for the given bean may be specified in
> jboss.xml, otherwise the default uLoginModule specified by
> the configuration file auth.conf it taken).
> After the successful login jBoss stores jLoginContext to the pool
> of successful logins.
Hi Oleg,
This sounds like a nice plan in general. It's also nice that you try to
allow for mapping of the user principal to different user names. The
specification mentions this, e.g. 15.2.5.1:
"An enterprise may have a complex security infrastructure that
includes multiple security domains. The security infrastructure may
perform one or more mapping of principals on the path from an EJB
caller to the EJB object."
Ultimately, of course, we'll want to be able to remap principals on a
per-bean basis as per the specification suggestion--especially if we
call an EJB on a remote application server. However, this isn't a
high priority in my opinion.
My biggest concern is your use of credentials for mappings
between the principal and its roles. Principal-to-role mapping is
done on a per-bean basis. This is fundamental to the security
architecture of EJB. (One motivation is that you should be able to
use third-party EJB components without modification.) In my
opinion, the EJB container should perform this mapping rather than
a security authentication scheme for this reason. For what it's
worth, my current sketchy implementation completely divides the
authentication functionality from the principal-to-role mapping
implementation.
Second, one advantage of using a JAAS authentication is to have
an authentication layer that could work with any back-end
authentication scheme. If I understand this part of your proposal
correctly, the JAAS module is responsible for understanding how
roles work with the jBoss container. Since an unmodified third
party JAAS module won't know how to do this, it seems that this
major advantage would be sacrificed.
Another big concern I have is that you are maintaining a pool of
successful logins. This implies that the container is maintaining per-
client state. In general, jBoss is designed as a stateless container.
Even calls to stateful session beans are stateless in their
implementation; the invocation has a key that lets us locate the
correct component. I think maintaining per-client state might be
bad for scalability, and potentially very bad for clustering. Right
now, the container re-authenticates every invocation. Ideally, we
will have a "trusted client" setup so that this isn't necessary under
certain circumstances: e.g. invocations from an in-VM web-app
where we can trust the principal we get; or perhaps if the stand-
alone client is using a secure transport-layer communications
protocol, and has authenticated once. (I haven't thought much
about how the case of the stand-alone client would work. We'd
probably provide the client with a token that gets them out of
authentication for a set period of time.)
To my way of thinking--and if I understand your goals correctly--
what you are trying to accomplish requires two additional pieces to
the existing architecture. (Plus someone--me, you, or someone
else--needs to make the existing pieces performant, convenient,
flexible, and reliable, of which the existing prototype pieces are
not.) Those two pieces are:
1. A "log-in" module on the client side--e.g. the JAAS client piece
that you described--needs to send the login notification to jBoss
(your step four) so that the client can be authenticated right away
(as most client apps expect), rather than waiting for the first
method invocation.
2. The server piece would be an implementation of
EJBSecurityManager whose isValid( Principal principal, Object
credential) would call JAAS for authentication.
That's my two cents. :-) Hope it helps.
-Dan
