The reason that the roles tested by the bean code using the isCallerInRole method
must be declared in the security-role-ref element is to ensure that the Application
Assembler and Deployer are aware of all the role names used in the code. Otherwise,
it could be difficult to deploy the application since the deployer must assign user
groups
to the security roles, and he can do this only if he knows the set of roles.
The isCallerInRole method allows the bean provider to parametrize the business logic
based on the type of client. The line between what is a "security check" versus what is
"business logic" is somewhat blurry here.
Vlada
-----Original Message-----
From: Richard Monson-Haefel <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wednesday, May 26, 1999 6:19 AM
Subject: Re: Instance level authorization
>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".
>
>
===========================================================================
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".
