On 10 Oct 00, at 14:22, Oleg Nitz wrote:
> Dan OConnor wrote:
> DO> Ultimately, of course, we'll want to be able to remap principals on a
> DO> per-bean basis as per the specification suggestion--especially if we
> DO> call an EJB on a remote application server. However, this isn't a
> DO> high priority in my opinion.
> Agree, but let's add something like
>
> Principal getPrincipal(String userName);
>
> to RealmMapping interface.
Hi Oleg,
I guess I like to write these e-mails, because I couldn't resist
sending another one. :-)
Adding this method to RealmMapping for principal mapping sounds
like a great idea: +1. One small suggestion for you to consider
before we actually put it in: maybe the method signature could be:
Principal getPrincipal( Principal user )
on the off chance that the mapping algorithm wants to take into
account the implementation class of the user parameter. For
instance:
if (user instanceof JBossWebPrincipal)
return new MappedPrincipal( "web_user" );
else if (user instanceof JBossIntranetPrincipal)
return new MappedPrincipal( "intranet_user" );
I don't know if anyone will ever want to do this, but why forestall it?
But I don't feel strongly about this.
>
> DO> My biggest concern is your use of credentials for mappings
> DO> between the principal and its roles. Principal-to-role mapping is
> DO> done on a per-bean basis. This is fundamental to the security
> DO> architecture of EJB. (One motivation is that you should be able to
> DO> use third-party EJB components without modification.) In my
> DO> opinion, the EJB container should perform this mapping rather than
> DO> a security authentication scheme for this reason. For what it's
> DO> worth, my current sketchy implementation completely divides the
> DO> authentication functionality from the principal-to-role mapping
> DO> implementation.
> My use of credentials for mappings between the principal and its roles
> doesn't contradict to the requirement of principal-to-role mapping to
> be done on a per-bean basis. Different LoginModules may serve for
> different beans.
Assume a client calls a stateless session bean facade (bean A)
which calls a service layer component (bean B) which iterates
through 20 entities (bean C1-C20). I think that the JAAS module
will need to be called once for A, once for B, and twenty times for
C, right?
In the design that separates authentication from role-mapping, you
would not necessarily need to reauthenticate the principal on each
call, nor would you need to perform any authentication from a
"trusted client." But I think under your design, where JAAS
modules do both (am I understanding this correctly?) you can't
avoid these authentication calls.
Finally, I think for principal-to-role mapping, a call to a simple Java
class (cached in the container by the MBean) will have less
overhead than a JAAS call. Does this seem likely to you as well?
>
> DO> Second, one advantage of using a JAAS authentication is to have
> DO> an authentication layer that could work with any back-end
> DO> authentication scheme. If I understand this part of your proposal
> DO> correctly, the JAAS module is responsible for understanding how
> DO> roles work with the jBoss container. Since an unmodified third
> DO> party JAAS module won't know how to do this, it seems that this
> DO> major advantage would be sacrificed.
> I propose to use JAAS both on client and on server.
> Client JAAS login process is a usual one, any 3rd party login modules
> may be used here, jBoss LoginModule is in general one of many.
My understanding of the primary motivation for JAAS is to have the
same set-up with security that we now have with JDBC: a standard
API that allows multiple pluggable third-party implementations. The
role that I thought JAAS would have with jBoss security is to allow
third-party security implementations (e.g. LDAP security, database
security, NT operating system security, etc.) to be used with jBoss
simply by using a standard jBoss JAAS authentication MBean and
the correct JAAS module.
This would allow us to instantly interoperate with any back-end
security that has a corresponding JAAS module (which I believe all
of the important ones eventually will). You wouldn't need to
configure jBoss at all (except for container-specific role mappings,
which you can't avoid). You just need to configure JAAS.
So for authentication, you would have the choice of using (or
writing) a jBoss security MBean that implemented
EJBSecurityManager, or using (or writing) a JAAS module in
conjunction with the standard jBoss "JAAS-Security" MBean that
implements EJBSecurityManager and delegates authentication to
JAAS.
If the JAAS module is also responsible for role mappings, this has
a major consequence that I think should be avoided: third-party
JAAS modules can't be directly plugged into the system, because
they won't provide this role mapping.
In any case, I'm interested in your motivations for using JAAS for
do the principal-to-role mappings. What are the advantages of this
approach?
[...]
> This type of the realm mapping would enable Deployer to deploy beans
> without writing Java code.
> Is it a good idea?
I strongly agree with this goal. A deployer should never have to
write Java code.
I think security information will frequently change, so the best place
to store principal-to-role mappings is somewhere that can be
managed at runtime, e.g. a database or an LDAP server (the
database is probably the best choice). Of course, this is not an
argument for a particular architecture; JAAS modules can store
this role mapping in the database as easily as an MBean can.
>
> Looking forward to more comments and criticism.
Thanks for presenting this information. If you feel strongly about the
part of your proposal that uses JAAS to map principals to roles, I'd
like to hear about some of the advantages. That's where most of
my concern lies.
-Dan
>
> Thanks,
> Oleg
>
>
>
