| Carbon User Manager Module Design |  |
Author: Jordan Reed (jreed at sapient.com)
Version:
Created:
|
| |
|
Java provides standards for authentication
and authorization services through the use of the JAAS API and
application server's J2EE security model. Both of these existing
API's provides a means for tying validation of a user into an
existing user store.
What the APIs do not provide is a system of
managing the users in the store and updating their settings. The
specification delegate these tasks to the store-specific tools.
This implies using SQL for RDBMS user stores, JNDI for LDAP
store, etc. This presents no common user management interface
against these store an application could use.
|
|
The Carbon framework does not provide a
service that mimics or replaces the existing security models in
Java. It only serves to fill gaps that exist in the J2EE security
model. The most noticable of these gapes is a consistent
API for basic user management tasks (create/update/delete
users/groups).
It also includes adapter classes to tie the
service into application server user stores and Jaas modules.
|
|
| |
|
The User Management APIs of the security
service are the bulk of the functionality. This is meant to
compliment existing APIs, since there exists no standard
J2SE/J2EE APIs to manage a user store. The management API
includes the creation of users and groups, updating of user
credentials and control of the mappings between principals and
groups.
Handling of roles is not provided in the
APIs for the User Manager service. This is because the
creation and mapping of roles in the J2EE security model is done
by the application server. So what one sees in the mapping
is:
| Feature |
Provider |
| User |
User Manager Service is responsible for
the storing and updating of the User objects. |
| Group |
User Manager Service is responsible for
the storing and updating of the Group objects.
|
| Role |
Roles are handled in the application
server. They are usually defined in the generic
deployment descriptors or application server specific
deployment descriptors.
|
| Principal-To-Group |
The mapping of Principal (User or Group)
as a member of a group is handled by the User Manager
service. It provides APIs to manipulate the mapping
and to check group membership. |
| Principal-To-Role |
The mapping of Principal (User or Group)
to a role in the application server is handled by the
application server. These mappings are usually
defined in the application specific deployment
descriptors. Many application servers do not allow
these mappings to be changed at runtime but there is a JSR
adding an API to allow runtime management.
|
If role-like functionality is required from
this service directly, the recommended solution is two create a
second set of groups to be considered as roles. This allows
one to map User-to-Group, Group-to-RoleGroup. It provides
identical functionality, except the distinction between Group and
Role is purely semantic.
|
|
| | |
There is a single method provided for
authentication. It allows a call to be made to authenticate
a Principal object with a given credential specified as an
Object. Specifying a credential as an object is the
standard in the Java security model. This allows the
credential to be a password, certificate, biometric data or any
other appropriate credential.
There is no built-in design for encryption
of the credential or storing an encrypted version of the
credential in the data store. Currently, to provide hashing
or two-way encryption of the credential an application would need
to extend the implementation of the User Manager service and
override the appropriate methods to add the encryption in.
|
| | |
Along with the main Security Service
interface there are supporting classes with a Principal and Group
implementation. The J2SE provides only interfaces for
Principal and Group. Each application server provides it's
own Principal and Group objects, but some (e.g. Weblogic 6) do
not map to the Java APIs.
It is the responsibility of the Application
Server Adapter classes to convert or wrap the default
implemenation of the Group and Principal objects with the
application server specific requirements.
|
| | |
Each application server has its own way of
allowing one to plug their security service into the
system. Most require the service to be written to a
propriatary API (though JAAS is quickly replacing this
system). Therefore, for desired applications servers, and
adapter class must be written.
|
| | |
To provide JMX management of the User
Manager service requires an adapter class. Since JMX only
easily supports simple data types, a wrapper adapter is created
around the service to provide similar functionality, but use
weakly typed inputs and ouputs. All methods in the JMX
Adapter takes String, Collection or primitive types.
|
|
