Hi
as far as I can follow you on my current state of enlightenment...
I was reading the j2ee 1.3 spec this weekend
(http://java.sun.com/j2ee/j2ee-1_3-pr-spec.pdf).
Please have a look at chapter 9!
They consider a component container for client-applications to provide
them with a secure context. This container is responible for
authentication (or he can direct this to the application itself if a
CallBackHandler is specified). I think this is the right approach to
get a generic security framework (and we meet the spec compliance).
I will dig deeper into this security stuff so I think I can say more in
a few days...
bye Daniel
On Mon, 09 Oct 2000, you wrote:
> 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
