dev@glassfish.java.net

Re: javaee5 EAR security & sun-application.xml question

From: Peter Williams <Pete.Williams_at_Sun.COM>
Date: Tue, 11 Jul 2006 15:10:21 -0700

Shing Wai Chan wrote:

> Peter Williams wrote:
>
>> Hi,
>>
>> I'm not sure who to address this to, but presumably the person(s) who
>> are responsible for EAR and EJB level security for appserver.
>>
>> I'm looking at the "cart-secure" example in the javaee5 tutorial.
>>
>> This example is an EAR containing an EJB module and an App Client.
>> The sun-ejb-jar.xml file for the EJB module and sun-application.xml
>> file for the EAR define security-role-mapping entries for the
>> role-name "CartUser".
>>
>> The only place this role is defined is in an @RolesAllowed annotation
>> in the session EJB inside the EJB module. So I have a few questions --
>>
>> 1. Does this mean that sun-application.xml is allowed to define
>> security-role-mappings that refer to role names that are _only_
>> defined in contained modules? Or is it a bug and there should have
>> been "security-role" entries in application.xml to define this role
>> at the EAR level? If it's
>
> This is a feature, not a bug in Java EE 5.
> The @RolesAllowed (and also other annotations) will map to
> corresponding deployment descriptors during deployment time.

Where does the spec say or suggest that @RolesAllowed in a module can
map to a security role definition at the EAR level. Are there other
module level annotations that imply values for the EAR's standard
descriptor file?

What affect is this supposed to have on XPaths in the standard
descriptor as defined in JSR-88? If what you say is true, then the
expected model of DDBeans-DConfigBeans is no longer valid for EAR's, yet
there is no mention of this in the maintenance release for JSR-88.

>> not a bug, can someone point me to where in the spec it says EAR's do
>> this, because apparently I can't find it.
>>
>> 2. (a) Does this mean that @RolesAllowed replaces the "security-role"
>> entry from the standard descriptor ala J2EE 1.4? If so, does that
>> mean that a security-role entry in the standard descriptor would
>> override this?
>
> @RolesAllowed does much more than security-role. It has deal with
> method-permissions.
> One need to be careful when you want to override by descriptors.
> I am working on an article to explain more on security annotations.
> It is coming soon.

How soon?

>> (b) Does the server infer any other implicit descriptor values
>> from this annotation?
>
So it would appear the answer to this question is yes. What other
descriptor entries are implied? Does this affect annotations in web
modules as well as EJB modules? Are these mappings defined or discussed
(even implicitly) anywhere? JSR-250 is very light on detail.

Thanks
-Peter

>> (c) Where does @DeclareRoles fit into all this?
>
> it is for isUserInRole or isCallerInRole invocation.
>
>>
>> Thanks
>>
>> -Peter
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>