Enthuware

Hi,
Sorry to disturb you again. But although i re-read the spec about security or books, I can't understand the answer for this question :
correct answer is :
Create a role named administrator and map admin and superuser to this role then map user Bob to administrator role.
Isn't it a mistake ?
The user bob is an administrator in the environment system, and admin and superuser are logical security roles for the assembled application (as the as the assembler has assembled these two beans)
For me administrator is note a role (in term of logical security role but a group of users) in the environment
So shouldn't we read :
Create a group (in the operational environment -- deployer) named administrator and map admin and superuser to this group then map (assign) user Bob to administrator role.

I really don't have idea how we can map logical with logical role defined for the application.
I don't speak of course about security-role-ref(@DeclaresRole) and sub-element <role-link) which correspond to programmatic security.
Hope i was enough clear.

Regards,
Alex

The specification does not say anything about the concept of groups. Logical grouping of users is a functionality usually provided by the actual operational environment but it is not guaranteed.

The role names used in the bean code are anyway merely references to actual role that exists in the operational environment. Therefore, the assembler can map these roles to the actual role "administrator" using the role-ref/link elements that you mentioned. Indeed, section 17.3.3 says:

The Application Assembler links each security role reference to a security role using the role-link
element. The value of the role-link element must be the name of one of the security roles defined in
a security-role element or by means of the DeclareRoles annotations or RolesAllowed
annotations (as described in section 17.3.1), but need not be specified when the role-name used in
the code is the same as the name of the security-role (to be linked).

Therefore, I think the given answer is correct.

Thanks for you fast reply but.....I re-re-read the spec. and I don't understand your explanation.
So, lets try to explain what I think :
If I have well understood the the question, it asks how can a user who is an administrator invoke method on the 2 session beans
I deduct that :
Each bean provider has specified a logical security for each bean
Now that they are assembled the "application" define 2 logical roles.
So what can we do to permit our user to access method of thoses beans ?

1) If we want to define administrator as a role for this application(that is augment the roles specified), the assembler must use security-role and the sub-element role-name.
And it'all. I don't see how to map this logical role whith the 2 others roles admin and superuser. I don't know a standardized way with EJB 3.0.
2)For the sake of discussion, we assume we don't have specified the security-role administrator. If we specify on the session bean @DeclaresRole(name="administrator") or <security-role-ref><role-name>administrator<..., whe have declared a security role reference that we can use in the bean code to check if the caller's identity belongs to a certain role.
Since administrator is not a logical role specified for our application we must link it with a logical role by the use of the sub-element <role-link>. But we can link it only to a logical role defined in the application. By example admin or superuser.
Furthermore this is for programmatic security.
I think that in the 17.3.3 section : security role references are references declared with security-role-ref/@DeclaresRole which is concerning programmatic security.

The Application Assembler may explicitly link all the security role references declared in the DeclareRoles annotation or security-role-ref elements for a component to the security roles defined by the use of annotations (see section 17.3.1) and/or in the security-role elements.

The Application Assembler links each security role reference to a security role using the role-link element. The value of the role-link element must be the name of one of the security roles defined in a security-role element or by means of the DeclareRoles annotations or RolesAllowed annotations (as described in section 17.3.1), but need not be specified when the role-name used in the code is the same as the name of the security-role (to be linked).

So for me using role-link in security-role-ref don't permit to use declarative security.

As you says, the spec don't define the security policy of the environment but theys says few words about groups of principal mapping with logical security roles. by example :
p 474

The Deployer assigns principals and/or groups of principals (such as individual users or user groups) used for managing security in the operational environment to the security roles defined by means of the DeclareRoles and RolesAllowed metadata annotations and/or security-role elements of the deployment descriptor.

To conclude this long message (sorry), I think there is a difference between group and role even in the spec.
But as you explain, with this type of question we must maybe understand that the role "administrator" is a role/group of the operational environment

Hope i was enough clear (mmmmhhh...i'm not sure)

regards,
Alex

PS : if all goes well , you will be no more disturb with my questions for this certification in one week

What I want to say with this long message is that I agree that this is the correct answer but i thing that the term role is not well choosen and confusing : group administrator would be less confusing.

Alex wrote:Thanks for you fast reply but.....I re-re-read the spec. and I don't understand your explanation.
So, lets try to explain what I think :
If I have well understood the the question, it asks how can a user who is an administrator invoke method on the 2 session beans
I deduct that :
Each bean provider has specified a logical security for each bean
Now that they are assembled the "application" define 2 logical roles.
So what can we do to permit our user to access method of thoses beans ?

1) If we want to define administrator as a role for this application(that is augment the roles specified), the assembler must use security-role and the sub-element role-name.
And it'all. I don't see how to map this logical role whith the 2 others roles admin and superuser. I don't know a standardized way with EJB 3.0.
2)For the sake of discussion, we assume we don't have specified the security-role administrator. If we specify on the session bean @DeclaresRole(name="administrator") or <security-role-ref><role-name>administrator<..., whe have declared a security role reference that we can use in the bean code to check if the caller's identity belongs to a certain role.
Since administrator is not a logical role specified for our application we must link it with a logical role by the use of the sub-element <role-link>. But we can link it only to a logical role defined in the application. By example admin or superuser.
Furthermore this is for programmatic security.
I think that in the 17.3.3 section : security role references are references declared with security-role-ref/@DeclaresRole which is concerning programmatic security.

The Application Assembler may explicitly link all the security role references declared in the DeclareRoles annotation or security-role-ref elements for a component to the security roles defined by the use of annotations (see section 17.3.1) and/or in the security-role elements.

The Application Assembler links each security role reference to a security role using the role-link element. The value of the role-link element must be the name of one of the security roles defined in a security-role element or by means of the DeclareRoles annotations or RolesAllowed annotations (as described in section 17.3.1), but need not be specified when the role-name used in the code is the same as the name of the security-role (to be linked).

So for me using role-link in security-role-ref don't permit to use declarative security.

As you says, the spec don't define the security policy of the environment but theys says few words about groups of principal mapping with logical security roles. by example :
p 474

The Deployer assigns principals and/or groups of principals (such as individual users or user groups) used for managing security in the operational environment to the security roles defined by means of the DeclareRoles and RolesAllowed metadata annotations and/or security-role elements of the deployment descriptor.

To conclude this long message (sorry), I think there is a difference between group and role even in the spec.
But as you explain, with this type of question we must maybe understand that the role "administrator" is a role/group of the operational environment

Hope i was enough clear (mmmmhhh...i'm not sure)

regards,
Alex

PS : if all goes well , you will be no more disturb with my questions for this certification in one week

If we want to define administrator as a role for this application(that is augment the roles specified), the assembler must use security-role and the sub-element role-name.

I am not sure what you mean by augment the roles specified in the beans. The names that are used in the beans are not actual roles. Keeping aside the case where the operational environment has roles with the same names, the names used in the bean code must be mapped to the actual roles in the environment. This is fairly straightforward because the bean developer has no idea about the actual roles names that will exist in the operational environment.

In the actual environment, therefore, you can create an actual role administrator and link (using the security-role-ref and role-link elements) the names used in the bean code to this actual role.

Our user can then be assigned administrator role. Again, this is a functionality of the operation environment.

So I am sorry but I am not able to understand what is causing the confusion.

Hi,
you are right my explanation was not clear.
Lets simplify.
By administrator role do you mean a role in the operational environment ?
What confuses me in the question is the use of the role term for administrator.
For me administrator is a group in the op. environment and admin and superuser are (logical) roles in the assembled application.
Although the spec. don't describe the security policy of the environment (authentification mode), i get the impression that it makes difference between the terms group and role

spec. p 457
The Deployer is responsible for assigning principals, or groups of principals, which are defined in the
target operational environment, to the security roles defined by the Bean Provider or Application
Assembler.

Best Regards,
Alex

Yes, there is certainly a difference between group and roles. But this question has nothing to do with group. We are not grouping the roles into any role.

1. The role names used in the bean code (this includes the values in RolesAllowed i.e. superuser and admin) are just dummy names. The bean developer doesn't know what would be actual roles in the final environment. He has just used these two names - superuser and admin. They don't mean anything.

2. Now, in the actual environment there is a user named bob, who is an administrator. Here "administrator" just means that he is an administrator. It is like saying, Alex is our administrator and he must be able to access these two methods. There may or may not be a role named "administrator". The actual environment may have named it something else. It doesn't matter.

All we want to do is map the role names that are used in the bean code to some actual role and assign that role to bob.

So, one way to do is to create an actual role - you can name that role "administrator" or "xyz", it doesn't matter, and then using the role-ref/link elements map the role names used in the code to this actual role. The option asks to create a role named "administrator", which is fine because you can name it anything.

In other words, the question can be written as:

You have a user name Bob in your system, who has to be given access to both the beans. Which of the following approaches would you use?

Notice that I have removed the part, "...Bob in your system, who is an administrator, and who ...".

The answer would be same. Create some role, say XYZ in the operational environment and map the names used in bean code to this role. You may also name this role "administrator".

Does this make sense?

Alex wrote:For me administrator is a group in the op. environment and admin and superuser are (logical) roles in the assembled application.

I don't think I agree with that statement. Administrator may or may not be a group. What if the target server doesn't have any group concept? To me, administrator is just a role.

admin and superuser are not necessarily logical roles. They are just dummy words used in the code. Actual logical role in the assembled app may be something else.

Hi,
first : thank you for your patience.
I agree with you about a lot of thing. If i have well understood what you say, I have first to create an administrator role in the assembled application like this (by example)
<security-role>
<role-name>administrator</role-name>
</security-role>

Now my application has 3 roles defined "administrator", "admin" and "superuser"
core EJB 3.0 :

The set of security roles used by the application is taken to be the aggregation of the security roles defined by the security role names used in the DeclareRoles and RolesAllowed annotations. The Bean Provider may augment the set of security roles defined for the application by annotations in this way by means of the security-role deployment descriptor element.

Now I map /link superuser to administrator :
...<session>
<ejb-name>XBean</ejb-name>
<security-role-ref>
<role-name>superuser</role-name>
<role-link>administrator</role-link>
</security-role-ref>
</session>...

If I run test, I can't access the Xbean's method with an user assigned to administrator, which not surprises me because <security-role-ref> (@DeclareRoles) is used to call EJBContext.isCallerInRole("superuser"). That is, as there is no principal assigned to "superuser" I can't access the methods of the XBean

The Bean Provider declares the security roles referenced in the code using the DeclareRoles metadata annotation. When declaring the name of a role used as a parameter to the isCallerInRole(String roleName) method, the declared name must be the same as the parameter value.

For me, role-link is about programmatic security. that is, if I have in a method body a EJBContext.IsCallerInRole("SecurityRoleReference") check, I have to declare this reference with @DeclareRoles or security-role-ref. If This reference doesn't correspond to a role in the application, I link this reference with role-link.

With your explanations , i thought that this role linking would have permit an "administrator" role to access to the Xbean annoted with @RolesAllowed("superuser") in the case of declarative security. But, it seems that it is not the case.

Maybe if you know where I can find a sample, it would be welcome

Thank you,
Regards,
Alex

Hi Alex,
I will try to make sample application and see what is going on. May be you are right

thank you,
Paul.

Hi Paul,
If it can help you I can send you my sample projet constructed with NetBeans for Glassfish V2.
Regards,
Alex

Thanks, Alex. But that will not be necessary. I already have a sample app working with glassfish. I am playing around with the role settings. It seems one can map the roles used in the code to role-name in sun-ejb-jar.xml

Still trying to make it work...

ok.
I mapped role with groups in glassfish like this :

<security-role-mapping>
<role-name>administrator</role-name>
<group-name>superseller</group-name> a group in the realm file
</security-role-mapping>

for authentication form
<enterprise-beans>
<ejb>
<ejb-name>TheBean</ejb-name>
<ior-security-config>
<as-context>
<auth-method>USERNAME_PASSWORD</auth-method>
<realm>security2</realm> my principal's realm file
<required>true</required>
</as-context>
<sas-context>
<caller-propagation>SUPPORTED</caller-propagation>
</sas-context>
</ior-security-config>
</ejb>
</enterprise-beans>

For information, If i don't mistake,In glassfish we have to map group of principals with a role. Except for un runas role, for which we must assign a principal

regards,
Alex

Ok, I have something working now...

1. I have a bean with the following two methods: 2. In ejb-jar.xml, 3. Now, in the app server, I do not have author1 and author2 defined anywhere. I have a group named "editor". A user bob is added to this group. So in sun-ejb-jar.xml, I have: 4. I have a web app with a servlet named SecureServlet. It is configured in web.xml as follows: 5. The servlet code accesses both the methods: Upon accessing this servlet, I see that it is able to access both the methods of the bean.

Conclusion
1. As you said, I couldn't map roles used in the bean code to "roles". I was only able to map them to group. Apparentely, Glassfish deals with groups of users.

But my contention is what if the app server does not have a concept of group? What if an app server uses roles and allows any user to have a role. Isn't that what the specification imagines? Specification doesn't talk about groups. It only talks about roles. The bean developer doesn't know the actual roles in the actual deployment environment. So there has to be a way to map the role names used in the bean code to the actual role names. Glassfish, for some reason, calls it groups.

So finally, I think I have to agree that it is more convincing to write "group" instead of role in the question. But I still believe that that would be logically incorrect.


thanks a lot for your patience in making me understand your position. I sincerely appreciate your efforts.

-Paul.

BTW, the following line in bean method code throws an exception saysing Role author2 is unmapped. Not sure why.

Hi,
First it's me who thank you for all the job you.

Regarding your exception, I think that you call EJBContext.isCallerInRole("author2") whithout specifying on the bean @DeclareRoles("author2") or by using <security-role-ref><role-name>author2</...

best regards,
Alex