Hi guys,
I've only just started to think about a jBoss security
implementation. (It's basically a no-op right now.) I was hoping
that some people on this list would like to brainstorm with me
before we write anything, especially since I'm no expert on security.
It seems to me that there are several things we need to consider.
I. Client authentication
We want to be able to handle the following cases:
* JAAS exists on the client; the client authentication is certificate-
based and the server can trust that authentication. This case
allows for "single sign-on" on a system with NT or a Kerberos
server on the network.
* JAAS exists on the client, but the client authentications available
are all password based and need to be verified by the server. This
might be the case with a database-based security system. The
password credential needs to be transferred across the
communication infrastructure.
* JAAS exists on the client, and the client wants to depend on the
application server (jBoss) to provide security.
* JAAS does not exist on the client, but the client can execute in a
jBoss container (per J2EE specs) that can provide custom
authentication.
* JAAS does not exist on the client, and the client is "standalone."
Custom authentication classes need to be provided. (This would
not be portable, of course.)
* The client is a web client using basic web authentication.
* The client is a web client using certificate-based authentication,
most likely through HTTPS.
It seems to me that there are (at least) the following implications of
these requirements:
1. The unit that we work with should be the Subject, which will
include the credentials that we will need on the server side. (Note
that the recently released Connector architecture uses the Subject,
not the Principal, as its basic unit.)
2. We should support retrieving the current Subject from both the
AccessControlContext (for the case of a JAAS-compliant client
calling doAs) and from a jBoss-specific static variable. We should
also be able to retrieve the Principal from a web server.
II. Server Authentication
It seems to me that we could write a particular security plugin to
require JAAS on the server side. (The client side would be more
problematic, for reasons of distribution and JDK versions.) Multiple
JAAS pluggable modules could be integrated with a single jBoss
server. Is this a reasonable requirement? (We could still write a
security plugin that didn't require JAAS; this would be a separate
project.)
III. Principal to role mapping
We would need to provide three things: a mechanism to choose
which Principal to make available to the EJB when the Subject has
multiple Principals; an administrative tool to map Principals to
Roles; and a persistence mechanism for this mapping.
The administrative tool provides some difficulties. As far as I
remember, there is no mechanism in a JAAS pluggable module to
retrieve available users and groups. This means that there is no
easy way to make them available in a GUI for the mapping to roles.
Does anyone have any good ideas for this?
The administrative tool and its persistence mechanism should be
dynamic, because it is quite likely that security mappings could
change at runtime. This is especially the case if the mappings are
done based on principals rather than groups (not that I would
recommend this practice!) I would suggest we use entity beans
with container-managed persistence for the persistence
mechanism, to provide maximum flexibility. The whole
administrative tool could be a JSP front-end to "administrative
EJBs," and/or a Swing GUI.
IV. jBoss-based security
Although one of the goals of the specification is to allow EJBs to
work with existing enterprise security systems, many people
expect that the application server be able to provide authentication
itself, especially for prototyping, experimenting, and department-
level applications. We should find or provide a simple certificate-
based JAAS authentication module that works with a database.
What do you guys think?
-Dan
