Chuck Zheng wrote:
> Hi again,
>
> I am thinking more generic means than isCallerCanAccess(data).
>
> Since each applicaiton/domain will have its own specific security policy,
>implementation
> of the above call will be hard to generalize.
>
> What I am thinking is that if we allow an EJBean to register (in its DD/or
>somewhere) with
> the container a class implements a Authorizor interface, and a class that implements
> SecurityData interface as below:
>
> public interface Authorizor
> {
> void hasPermission(SecurityData data) throws ecurityException
> }
>
> public interface SecurityData //or abstract class?
> {
> // concrete class must have a constructor
> // or a factory method registered with the container via DD
> // the signature of the ctor and factory method may need
> // to take params of the EJBean's params.
> }
>
> This is very much like register a comparison operator with C++ STL/Rogue collection
>(hash,
> stack, etc) template.
>
> Upon an invocation of the EJBean, the container will constructs an SecurityData
>object
> with appropriate params, (invoke via reflection may be needed)
>
> Then the container invoke the Authorizor.hasPermission. The EJBean's method won't be
> entered if the authorisation failed and the EJBean's method need not to perform any
> further authorization.
>
> Since concrete Authorizor and SecurityData class are supplied by Bean Provider, s/he
>can
> code any security rule needed by the specific application domain, as well as pick
>any data
> they want to use for authorisation. There is coupling between these Authorizor and
> SecurityData concrete classes.
>
> Is this approach feasible? Any show-stoppers?
You've changed my proposal in two ways.
(1) You have used a SecurityData class to encapsulate the data needed whereas I
proposed a
String.
(2) You have specified that the authorisation check should be done by the container
whereas
I proposed that the method would do the check explicitly.
I'm happy with your first change, however there are two interesting requirements that
your
second change does not satisfy:
- the data resource being protected may not be known by the deployer - it may be
supplied by
as a parameter to the method. (e.g. a getRowAsString() method that takes databasename,
etc
as parameter), or
- the method may only access the data resource under certain circumstances (e.g. a
checkLoanDetails() method only accesses the sensitive CompulsiveGambler database for
loans
over $1M, and only supervisors can process such big loans.)
Hence I'd prefer a flexible API to the additional deployer-determined security check
that
you are proposing.
Ian McCallion
===========================================================================
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".
