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?
cheers
chuck
Ian McCallion wrote:
>I believe the solution is for the container to provide a means to access security
information
>associated with a resource. This requires a different API, eg:
>
> boolean isCallerAuthorisedToAccess(String resourceName);
>
>Methods of EJBs typically run with container level of priviledge - i.e. whatever
the
>container is authorised to access the method will be able to access. This is
right and proper
>but there will be a few situations where the method needs to do additional
data-related
>security checking.
>
>> >
>> > Chuck Zheng wrote:
>> > >
>> > > Greetings,
>> > >
>> > > J2EE/EJB method-permission declarative security has simplify authorisation
service.
>> > > But it does not address data-related authorisation. This part currently
has
>> > > to be done by application specific programmatic security and it depends
on programmer
>> > > decipline and code-review to enforce these
>> > > security checks are performed correctly.
>> > >
>> > > Since data-related security authorisation is such a common occurance,
I wonder
>> > > whether J2EE/EJB can provide some utilty to make it (semi-)automatic?
Maybe
>> > > JAAS/PAM will help to some extend. I think at least standard API can
provide
>> > > methods to register custom authorizer object with the J2EE/EJB
>> > > framework (declaratively?) and specify the interface for AuthorisationData.
>> > > If application can provide a AuthorisationData object at runtime (declarativly
>> > > or programmaticly), The framework will run those registered
>> > > Authoriser against the AuthorisationData object. Most of the time the
Authoriser
>> > > only need to say true/false or throw a SecurityException. Therefore I
think
>> > > this approach is very achievable - after all it is just like those templates
>> > > in STL/RogueWave for those who use C++.
===========================================================================
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".
