Hi Dan,
DO> That's my two cents. :-) Hope it helps.
Thank you for your 2 cents, they are very valuable for me.
Below I reply in short to your remarks and then give the changes to my
scheme that were made under the influence of your 2 cents :-)
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.
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.
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.
DO> Another big concern I have is that you are maintaining a pool of
DO> successful logins. This implies that the container is maintaining per-
DO> client state. In general, jBoss is designed as a stateless container.
DO> Even calls to stateful session beans are stateless in their
DO> implementation; the invocation has a key that lets us locate the
DO> correct component. I think maintaining per-client state might be
DO> bad for scalability, and potentially very bad for clustering.
Good point, I absolutely agree. I have removed login/logout
notifications from the scheme.
DO> To my way of thinking--and if I understand your goals correctly--
DO> what you are trying to accomplish requires two additional pieces to
DO> the existing architecture.
DO> Those two pieces are:
DO> 1. A "log-in" module on the client side--e.g. the JAAS client piece
DO> that you described--needs to send the login notification to jBoss
DO> (your step four) so that the client can be authenticated right away
DO> (as most client apps expect), rather than waiting for the first
DO> method invocation.
In the new version of my scheme the JAAS LoginModule module on the
client side would just set the static variables in
SecurityAssociation, so it cannot be considered as an additional piece
of architecture - just the JAAS-specific piece of code.
DO> 2. The server piece would be an implementation of
DO> EJBSecurityManager whose isValid( Principal principal, Object
DO> credential) would call JAAS for authentication.
...and an implementation of RealmMapping.
Now the list of changes:
1) Login/logout notifications are excluded
2) Not the change but the clarification:
client JAAS may contain other LoginModules
3) Proposition: to add the method
Principal getUserPrincipal(String username);
to RealmMapping interface
4) The role of the server JAAS is rethought and cleaned.
The server JAAS is used for authentication on bean container.
This might be not what we usual mean by authentication (fingerprint
samples and so on), but it provides Credentials (roles) that are
used for authorization of user access to bean methods.
All server LoginModules represent some realm mappings.
Bean name is used as an application name for LoginContext
so that each bean may have its entry in JAAS configuration file
("other" section specifies the default realm mapping).
Server JAAS login is performed on invocation of bean's method if
the RealmMapping info for the given user name is not found in the pool.
Server JAAS logout is never called.
The pool doesn't keep track of user logins/logouts,
therefore it may have a timeout (for better scalability).
5) Two types of RealmMappings: primary and secondary.
Server LoginModules are Primary realm mappings.
A secondary realm mapping can be constructed on the base of some
primary realm mapping.
Secondary realm mappings are defined in jboss.xml.
The base realm mapping is referenced by the application name in
JAAS configuration file.
Secondary RealmMappings cannot change the Principal,
they define a new set of roles, like this:
<realm-mappings>
<realm-mapping name="NewRealm" base="other">
<role name="newRole">
<primary>primaryRole1</primary>
<primary>primaryRole2</primary>
</role>
...
</realm-mapping>
...
</realm-mappings>
This type of the realm mapping would enable Deployer to deploy beans
without writing Java code.
Is it a good idea?
Looking forward to more comments and criticism.
Thanks,
Oleg
