About Question enthuware.oce-ejbd.v6.2.615 :

[fjwalraven]

I have read this question several times and I still have problems understanding it. Let me try to explain my problem with it:

"You have a EJB 3.x session bean that uses some security roles."
Ok, this means I have a EJB with a @DeclareRoles or some <security-role>s in the dd

"However, your environment only supports Users without any role"
So does this mean that I can't assign a security-role to a Principal? Then you won't be able to use the EJB, will you?

"In other words, your environment does not allow you to group users into roles"
If I am not allowed to group users into roles then I can't say Principal "A" is mapped to security-role "A". Or do you mean that the environment does not allow mapping security-roles to User groups (as opposed to mapping security-roles to Users, Principals)?

Regards,
Frits

[admin]

The question says that the environment doesn't support grouping users into roles. So you can't map the logical roles used in the EJBs to actual roles in the environment (because it doesn't have the concept of roles, as per the problem statement.).

As explained in the explanation, the specification provides for this situation and suggests that you can use the names used as logical roles in your EJBs and create users by those names in your deployment environment.

Hope this is clearer now.
-Paul.

[fjwalraven]

Hi Paul!

Ok, I guess I am now getting it, let me try to say it in my words

"However, your environment only supports Users without any role"
So does this mean that I can't assign a security-role to a Principal? Then you won't be able to use the EJB, will you?

Answering my own question: Yes, you can't (and won't) assign a Principal to a security-role. However when the name of the User(Principal) or User Group (Principal group) is the same as the logical role-name used in the application: you won't have to. As this coupling is implicitly done by the container, right?

The key thing here is that I have to "create" Users(Principals) with corresponding names.

Thanks for the clarification!
Regards,
Frits

[Guest]

Just to check my own understanding of this question, please allow me to try to explain.

Here, the "environment" is the actual operating system security module - some LDAP or such. Now, suppose you want to grant read/write access to your files for some users. Normally, you would create a usergroup "myFileUsers", grant read/write access for this group and include your users into this group. The same goes for a EJB access: your EJB requires some "myBeanReadWrite" logical role, so you would create a usergroup "myBeanUsers" in your LDAP, link the myBeanReadWrite role to this group and include various users into this group when they ask for it.

Now, the question tells us that your LDAP has no usergroups. No problem - you just link the myBeanReadWrite to every user individually, when they ask for it. The amount of work is even the same.

[himaiMinh]

Regarding to option 2:
"You can use this bean and the bean can call isCallerInRole() as usual."

Does it mean the user should be mapped to a role first in the vendor-specific deployment descriptor before
isCallerInRole () can be called?

Like option 4 says "All roles defined by the bean can be mapped to the users in the environment."

So, option 4 has to be done before option 2?

If the caller does not have a role mapped, isCallerInRole("") will return an empty string, which is meaningless.

[admin]

Regarding to option 2:
"You can use this bean and the bean can call isCallerInRole() as usual."

Does it mean the user should be mapped to a role first in the vendor-specific deployment descriptor before
isCallerInRole () can be called?

Like option 4 says "All roles defined by the bean can be mapped to the users in the environment."

So, option 4 has to be done before option 2?

If the caller does not have a role mapped, isCallerInRole("") will return an empty string, which is meaningless.

Yes, of course, all the mapping and setting up of users has to be done before the execution of the application. If the caller does not have a role mapped, then isCallerInRole will return false for that role. Why do you think it will return an empty string? It has to return a boolean.

HTH,
Paul.

[himaiMinh]

Hi Paul,
I tried to run an example invoking isCallerInRole(""). And the principal is called "Bob" with no role specified in GlassFish's security file realm.

I did not specify any role for Bob in sun-ejb-jar.xml.

The isCallerInRole("") returns an exception since the role with empty string is not found in the operational environment.

[admin]

Not sure why you are trying with empty string. If the environment doesn't support mapping user names to roles, you can configure the role names used in the bean as users in the environment. The value in isCallerInRole would be still be the same role name. Please read the explanation given with the question carefully.

[himaiMinh]

In the explanation: "if there are no roles in the environment, the role names given in the bean are assumed to be "users"."

I think it can be clarified in this way : "If the bean provider or assembler define a logical role "users" and the deployer does not assign "user" to any principal/principal group in the operational environment, then the principal group "user" in the environment is assumed to be the same as the logical role "users".

Reference :

session 17.4.2 If the deployer does not assign the logical security role defined by the application to groups in the operational environment, it must be assumed that a logical role maps to a principal or principal group of the same name.