Re: Instance level authorization

[Christopher Ferris - Enterprise Architect - EMA]

My point is that roles are merely an administrative "tool" to
facilitate the management of permissions. I have no problem if
the permissions must be explicitly identified in the DD. However,
it should be up to the application assembler, the security policy
administrator, or the owner of the business process to determine
which permissions are grouped into which roles (collections really)
and granted to which users (or other entities).

I could envisage a bean providor _suggesting_ a
logical grouping of permissions based upon their domain
expertise.

This allows far more granularity of control over who can
do, or access, what.

As to Rainer's point regarding instance level authorization,
in certain regards I agree that it is possibly more appropriately
the domain of the business logic. However, why couldn't the same
security framework be leveraged in the enforcement?

Chris

Rainer Kerth wrote:
>
> Richard Monson-Haefel wrote:
> > The EJB 1.1 spec needs to be changed so that roles used in bean code are
> not
> > staticly defined in the DD. (Chris may want all roles to be removed, I'll
> be
> > happy if the security-role-ref ones are removed.)
>
> But Vlada's point remains valid: how would you map logical security roles
> to "real life" roles if they are
> not declared in the DD?
>
> IMHO  instance level authorization is more an issue of business logic than
> of security administration.
> Thus, it should be implemented by means of EJBs and not with the Security
> API. In your bank scenario,
> what happens if you have to change some roles due to some major business
> process reengineering
> effort in your company? You would have to modify all your persistent trust
> fund data and possibly
> the code of your beans to reflect the changes. Hmmm..... I'd rather try to
> gather this part of the business
> logic in some object that can easily (well, more easily) be exchanged.
>
> <vendor>
> The San Francisco Framework solves this problem by defining "Controller"
> objects that manage
> collections and that can expose or hide certain instances inside these
> collections. The decision to do so
> can be based on runtime criteria. Furthermore, it allows you to combine
> these Controllers in a Chain of
> Responsibility inside a Company hierarchy. Thus, you can have a Controller
> at a Division level and
> another one at a Department level. If the Department Controller does not
> have enough information to decide
> whether the caller is allowed to access an instance, it can chose to turn
> around and ask its Division
> Controller.
> Reorganising a company is then a matter of rewriting the Controllers (and
> maybe the Company
> hierarchy if they are *really* serious about reorganization ;-)).
> </vendor>
>
> Rainer
>
> ---------------------------------------------------------------------------
> --
> Rainer  Kerth, [EMAIL PROTECTED]
> IBM Somers, WebSphere Architecture
>
> ===========================================================================
> 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".

--
    _/_/_/_/ _/    _/ _/    _/ Chris Ferris - Enterprise Architect - EMA
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: [EMAIL PROTECTED]
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903

===========================================================================
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".