Hi,
within the scope of my diploma thesis I am working an security issues in
regard to EJB. I worked out some ideas and a proposal how a security
structure might look like. I tried to document the ideas I had so far to
bring them into the discussion. (see the javadocs on my homepage:
http://www.uni-ulm.de/~s_fkohma/diplomarbeit/main.html).
The scope of this proposal is to provide a flexible security architecture
that avoids the serious drawbacks of the specification 1.0, which are the
following:
- No interfaces for server independent authentication are provided
- Access control can only be achieved through an Acl like approach (list of
identities for a bean or bean's method). There is no possibility to
implement other authorization strategies like label-based authorization for
instance.
- Access control decisions can not be made on instances. This is essential
for entity beans.
- No concept of delegation.
The main idea is to provide a domain concept that is similar to the one of
the CORBA Security Service for the EJB framework. Interfaces for different
types of domains (authentication, authorization and delegation) are
introduced. Each bean has to be member of at least one domain of each type.
The implementation of the interfaces provides the realization of a certain
policy. That could be authentication with passwords or credentials or
authorization that is label-based or Acl-based and so on. A domain provides
two types of methods: Methods that are accessible for a client and methods
that are only called by the container. The first type of methods provides
functionality needed by the client like getting information about the domain
or authentication methods for instance. This is realized by extending the
EJBMetaData interface. The methods called by the container are called to
comply with the policy of the domain. This distinction is made for security
reasons. It is not necessary for instance, that the client knows any details
of the authorization algorithm.
The container does not know how a domain ensures a certain policy. It is
only responsible to delegate theses tasks to the appropriate domain at
certain times. The authorization domain for instances provides a checkAccess
method. If a bean's method is being invoked the container calls checkAccess
on the accordant domain before actually calling the method on the bean's
instance. Dependent on the result the container can take the appropriate
action: call the instance's method or throw an exception.
The information on domain memberships of beans as well as additional data
required by the domain to implement the policy has to be maintained in some
place. I propose to do such by extending the deployment descriptor with the
domain class, the domain related data (SecMetaData class) and their
serialized instances. Another possibility would be to find a general XML
description of a domain respective their policy, to keep the descriptor free
of specific class files. However, this is not an easy task.
The main advantages of such architecture are the following:
- The security service is pluggable into every container that supports the
interfaces.
- The implementation of the domains and their policy would be independent of
the client application on the one hand and the container implementation on
the other hand. I see a great advantage of the independence of the
container. It makes it very easy to map the security functionality to
existing technologies without the need of changing every specialized
container. It even opens the possibility for security solution vendors to
plug in their product into the EJB-framework. Security management is a very
complex task that in my eyes even could be another role within the EJB
framework.
Possible disadvantages:
- Performance: By shifting responsibility from the container to the security
domains, also the influence of the container on performance during security
related work is given away. Since this functionality is needed very often
during execution, the container has to rely on a fast domain implementation.
Outstanding issues:
- Integration of a transmission domain, which can be used to assure a secure
transmission between client and server or between different servers.
Cheers
Frank
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
