Mike,
Although your solutions works great in EJB 1.0 it doesn't work in EJB 1.1.
In EJB 1.0 roles are not declared in the DD; they are defined by the
administrator using, presumably, an ACL. In EJB 1.0 your solution works
elegantly.
In EJB 1.1 any roles that are tested in the bean must be logical roles that
are explicitly identified by the application assembler in the DD.
EJB 1.1 Paragraph 15.2.5.3
"Declare the name of the security role using the role-name element. The name
must be the security role name that is used as a parameter to the
isCallerInRole(String role-Name)method."
In other words, any role name you use in the method isCallerInRole(String
roleName) must be declared in the XML DD within the security-role-ref tag.
This means that role names are static definitions and can not be derived at
run time.
I think this may be a fairly serious problem in the new specification.
Vlada or Mark: Can you comment on this?
Richard
-----Original Message-----
From: Mike Porter
To: [EMAIL PROTECTED]
Sent: 5/25/99 7:38 PM
Subject: Re: Instance level authorization
Richard,
You wrote:
>I was disappointed to see that instance level authorization is not
covered
>in EJB 1.1.
>
>How, for example, does an EJB system allow "Jill Jones" to access
account
>records 1, 33, 77, 199 but not any other accounts? What if the list of
>accounts accessible by Jill and other users changes daily?
>
As you have discovered the EJB spec does not inherently support this
type of
functionality. However, I can think of a solution that may help you
.
The security API that your EJB Container uses to perform security
authorizations is available to you. You could use the ACL API and code
this
specific security functionality yourself. Obviously if you do this you
will
need to have an attribute of the account that would indicate the
security
permissions allowed for this specific Account(s)(#'s 1, 33, 77, 199 in
your
example). You would then be able to interrogate this attribute and
determine if the user is a member of a group that can access this type
of
Account.
>What if the list of accounts accessible by Jill and other users changes
daily?
This would inherently be supported with my above mentioned solution.
Your
security level attribute on the Account could easily be changed in a
runtime
environment. Your security checks would recognize these and constrain or
grant access accordingly.
Hope this helps.
</Mike>
************************************************
Mike Porter
Director of Technology
eSage, llc
(206) 264-5541 (Voice & Fax)
[EMAIL PROTECTED]
www.esage.net
----- Original Message -----
From: Richard Monson-Haefel <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 25, 1999 11:18 AM
Subject: Instance level authorization
>I was disappointed to see that instance level authorization is not
covered
>in EJB 1.1.
>
>It would be nice if specific principles in the operational environment
could
>be given permissions on specific entity primary keys. An administrator
>would do this.
>
>How, for example, does an EJB system allow "Jill Jones" to access
account
>records 1, 33, 77, 199 but not any other accounts? What if the list of
>accounts accessible by Jill and other users changes daily?
>
>=======================================================================
====
>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".
===========================================================================
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".
