Christopher Ferris - Enterprise Architect - EMA wrote:
>
> 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.
>
I wanted to say "roles as they are defined in EJB spec"
in my first statement.
I suggest to explicitly split roles and permissions
in EJB spec. I suggest to have method that checks
permissions which could be named like:
EJBContext.hasCallerPermission(String permissionName);
which checks for specific permission that should be declared
in DD and maybe remove isCallerRole() from EJBContext.
> 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?
>
Which security framework do you mean? If current EJB framework then
I do not sees way how to change instance permissions in standard way.
BTW Ejipt-like approach (we used the same approach) i.e exporting
users, groups and permissions as entity beans can be used as basis
for EJB oriented permission API.
Constantine
===========================================================================
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".
