dev@glassfish.java.net

Re: Anonymous Role Definition

From: Ron Monzillo <Ronald.Monzillo_at_Sun.COM>
Date: Wed, 28 Jan 2009 17:10:35 -0500

Ron Monzillo wrote:
> burak sevindi wrote:
>
>> Hello,
>>
>> I have a question about security configuration. I am using LDAP realm
>> and I want to define an anonymous role to enable unauthorized access
>> to some EJB methods. According to the "Sun Java System Application
>> Server Platform Edition 9 Administration Guide" I must set the value
>> of the "Anonymous Role" setting which is located in the Configuration
>> > Security in the admin console. But there isn't such setting in the
>> security configuration page. BTW, my AS version is 9.1 and I cannot
>> find an admin guide for this version.

http://docs.sun.com/app/docs/doc/819-3671/gelvk?a=view

>> Thanks in advance.
>
>
> burak,
>
> I am not 100% sure, but I believe the anonymous role was used to achieve
> an effect simialr to that achieved via assign.groups (which is defined
> as a property of each realm).
>
> Assign groups is used to define the one or more group principals that
> are assigned by the realm to every authenticated user. A mapping of any
> such group principal to a role, will allow the role to be used to
> distinguish any authenticated user, from all unauthenticated users
> (based on its mapping to the role).
>
> that said, I am not sure I understand your use case, but its sounds like
> you want to define a role that is assigned to all unauthenticated users,
> so that you can define method-permissions or @RolesAllowed annotations
> wrt to that role. AFAIK, this is not supported in 9.1.
>
> Assuming that you don't have a use case where authenticated users must
> receive a lesser degree of privilege than unauthenticated users, then
> you could declare the correesponding resources as "unchecked" or
> annotate them with a @PermitAll annotation.
>
> This will allow access independent of authentication.
>
> Ron
>
> ps: there is a problem wrt to ejb's which feature protected and
> unprotected methods (wrt to authorization), in that the info in the
> object reference that tells the client whether or not it must
> authenticate to access the resource, is per ejb. If the ejb has both
> protected an unprotected methods the policy in the object reference must
> (generally) require client authentication, as otherwise, the client will
> not authenticate as necessary to satisfy the authentication requirements
> of the protected methods. This means that the client will also
> authenticate when it attempts to access unprotected methods of the ejb
> (which would not otherwise be necessary).
>