Thanks Ian,
I think the concrete Authorizor class can be passed to container as a strong 'hint'
from Bean Provider to Application Assembler to Deployer. If deployer decided not
to deploy the Authorizor, s/he is solely responsible for the consequence.
Since Bean Provider has full control of the Authorizor implementation, s/he can
decided what data source is needed in what way (this may also be conveyed to the
deployer as part of the DD info) - thus less guess work for deployer.
What's your opinion?
cheers
chuck
Ian McCallion wrote:
> 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".
===========================================================================
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".
