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.
>
> 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).