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

[jszczepankiewicz]

Hmm, I am little confused about the answers / explanations number 1 and 5.
The explanation for numer 1 suggests that if we use @RunAs then if we use getCallerPrincipal(), then we will receive the principal associated with the role (that may be declared i.e. in glassfish using the sun-ejb-jar.xml descriptor) NOT the original principal. But the answer number 5 states that using getCallerPrincipal will return the original principal NOT the principal mapped to the role used in @RunAs. I think the first explanation should be modified because the explanation for the first answer: "(...) and will be visible as the caller principal in the callee." is not true, there is probably no way to retrieve programatically (using methods from specification, not vendor specific) the security principal that is used by container if we use @RunAs(...).

[admin]

On Page 484 of the 3.1 spec, it says:

The security principal under which a method invocation is performed is typically that of the component’s caller. By specifying a run-as identity, however, it is possible to specify that a different principal be substituted for the execution of the methods of the bean’s business interface, no-interface view, home interface, component interface, and/or web service endpoint and any methods of other enterprise beans that the bean may call.
This determines whether the caller principal is propagated from the caller to the callee—that is, whether the called enterprise bean will see the same returned value of the EJBContext.getCallerPrincipal as the calling enterprise bean—or whether a security principal that has been assigned to the specified security role will be used for the execution of the bean’s methods and will be visible as the caller principal in the bean’s callee.

And on page 487, it says:

The purpose of the getCallerPrincipal method is to allow the enterprise bean methods to obtain the current caller principal’s name. The methods might, for example, use the name as a key to information in a database.
An enterprise bean can invoke the getCallerPrincipal method to obtain a java.security.Principal interface representing the current caller. The enterprise bean can then obtain the distinguished name of the caller principal using the getName method of the java.security.Principal interface. If the security identity has not been established, getCallerPrincipal returns the container’s representation of the unauthenticated identity.
Note that getCallerPrincipal returns the principal that represents the caller of the enterprise bean, not the principal that corresponds to the run-as security identity for the bean, if any.

They do seem contradictory so I am not really sure what to make out of this

[admin]

The given options are correct though.

[sanju.ait@gmail.com]

Why option 4 ("The value returned by Principal.getName() is same as the username used for authentication of the caller.")
is wrong?

Is it because role-link/role-name will change the Principal.getName() value?

[admin]

No, this is explained in option 2:

As per section 17.2.5.1:
An enterprise may have a complex security infrastructure that includes multiple security domains. The security infrastructure may perform one or more mapping of principals on the path from an EJB caller to the EJB object. For example, an employee accessing his or her company over the Internet may be identified by a userid and password (basic authentication), and the security infrastructure may authenticate the principal and then map the principal to a Kerberos principal that is used on the enterprise’s intranet before delivering the method invocation to the EJB object. If the security infrastructure performs principal mapping, the getCallerPrincipal method returns the principal that is the result of the mapping, not the original caller principal. (In the previous example, getCallerPrincipalwould return the Kerberos principal.)

So it is not necessary that getPrincipal will return the name used while logging in.

HTH,
Paul.

[PMiglani]

I am still not clear why the Option 5 is incorrect. Please explain why getCallerPrincipal will not return the Principal corresponding to run-as security identity.

[n4noman]

I think that specs is not contradicting.

Consider the scenario:

Code: Select all

                              
                              @RunAs("admin")     
Servlet ---calls----> SecureBean1  ---calls---> SecureBean2

getCallerPrincipal() in SecureBean1 will return the principal used to call SecureBean1 (as described on page 487). But due to presence of @RunAs annotation on SecureBean1, the principal "admin" will be propagated to SecureBean2. So if you call getCallerPrincipal() in a method of SecureBean2, you will get the "admin" principal and not the original principal (this confirms to page 484 of specs quoted by admin).
Do you agree admin?

[admin]

Yes, what you are saying makes sense.
Paul.