users@glassfish.java.net

RE: Re: _at_RunAs doesn't forward security principal?

From: Markus Karg <karg_at_quipsy.de>
Date: Tue, 22 Jul 2008 13:46:48 +0200

>So how does glassfish know which realm to look for ?. Where did you
>configure file-realm or any other realm in your application ?.

We did not explicitly specify a realm because filerealm is the default.

Will it work if we declare a realm manually for our application (how to do that)?

>Also no
>authentication really takes place in this scenario since a run-as
>principal has been specified. Normally if there was a Realm
>Authentication then the groups would also get assigned. The
>authorization system then tries to see if the principal is in an allowed
>role.

Still I do not get the point, because:

<ejb>
   <ejb-name>ComplaintServiceBean</ejb-name>
   <principal>
    <name>cde</name>
   </principal>
</ejb>

with the above statement GlassFish knows the principal to use, and with the default realm it knows the realm to use, and in that realm it will find that "cde" is in group "User_Group", and from

<security-role-mapping>
  <role-name>User</role-name>
  <group-name>QUIPSY_User</group-name>
</security-role-mapping>
</sun-application>

GlassFish knows that group "User_Group" obtains the role "User".

And "User" is what you must have to fulfil @RolesAllowed("User").

So all information IS GIVEN. No authentication is needed. Just a simple lookup in the default realm.

So why, from a conceptual aspect, does GlassFish not just look into that default realm to learn about the roles but instead forces admins to add the principal additionally to security-role-mapping? I just want to understand why the designers of GlassFish decided NOT to look into the realm to learn about the roles but to force people to give an ADDITIONAL (from my view: redundant) mapping.

That is what I just do not understand.

Maybe I am just blind, but I do not see the reason.

Thanks
Markus