Ron Monzillo's Weblog

Do you have an opinion as to whether Compatible Servlet 3.0 containers should be required to support the Servlet Container Profile of JSR 196? Support for the profile would ensure common integration of portable authentication mechanism implementations with the security-constraint processing machinery of any compatible Servlet container.[Read More]

This entry describes how to define security constraints on content served by the default web module. [Read More]

The Servlet EG has tentatively agreed to a change to the Servlet 3.0 security constraint grammar that will allow security constraints to be targeted to all HTTP methods other than those specifically listed. This change will facilitate the mapping of the common security annotations to security constraints which will facilitate adoption, by Servlet 3.0, of the use of the common security annotations on Servlets.[Read More]

We made some enhancements in Prelude to improve JACC policy provider replacability, and we added a new portable in-memory JACC Policy provider that can be configured as an alternative to the file-based JACC Policy provider. The file-based provider is configured by default. To enable the in-memory provider, do the following:

• stop the application server (i.e., asadmin stop-domain)
• edit domain.xml and add or change the security-service element to define the attribute jacc="simple"
• restart the application server. (i.e, asadmin start-domain)

The in-memory provider was developed both to provide a simpler and more performant alternative, as well as to serve as a sample to help others develop their own providers. Portability was achieved by defining a JACCRoleMapper interface, and by defining the provider such that it can be trained (via a system property, i.e., com.sun.enterprise.security.jacc.provider.JACCRoleMapper) to use a system specific implementation of the JACCRoleMapper interface. The source of the in-memory provider is available in the project repository.

This entry describes the Servlet security constraint model and offers some recommendations intended to help ensure that your application is protected as you intend it to be. Thanks to Jeff Williams of Aspect security for making me aware of common practice, and for his suggestions for simplifying the Servlet constraint model.[Read More]

This entry defines a technique for using the standard interfaces provided by JACC to implement a utility that returns all the role memberships of the caller of a Servlet or EJB). This technique may be used to decouple the calling application from the set of declared roles.[Read More]

You can inject a new network authentication mechanism in the Glassfish Servlet container by:

• implementing a JSR 196 server authentication module (i.e., a SAM), and
• configuring the SAM as a message-security-provider via the Glassfish admin console, and
• binding the SAM for use by your application via sun-web.xml.

A SAM differs from a custom realm in that the SAM can control the HTTP authentication dialog, while a realm is typically used by a system controlling the dialog (such as a SAM) to validate or augment credentials extracted from the exchanged messages. JSR 196 is also used by (and available within) the client and server-side web service pipelines of the Glassfish METRO stack.[Read More]

An ANYONE role is a role that is granted to every authenticated user and only to authenticated users. Any Glassfish realm may be configured such that it assigns one or more group principals as a side effect of any successful authentication at the realm. Any application role that is mapped to one of the assigned group principals can be used as an ANYONE role. An application defines an ANYONE role as follows:

• configure the "assign.groups" property of the Glassfish realm used for the application. This can be accomplished by using the admin console. Login to the console and navigate to the realm specific configuration screen found under configuration => security => realms. In the "Assign Group:" input box on that screen, specify the name of the group principal that you want to be assigned by the realm.
• declare a role either within the corresponding portable deployment descriptor, or by using either the @declareRoles or @rolesAllowed annotations.
• map the assigned group principal to the declared role, as described in Principal 2 role mapping and Glassfish. If the default mapping is employed to map the group principal to the role, the name of the role must be equivalent to that of the assigned group. Otherwise, the role may be given any name.

Glassfish uses Jacc for its container access decisions. The container access decisions are performed independent of whether a System SecurityManager is configured for the Glassish Server. You should not define an unqualified grant of AllPermission in server.policy, .java.policy, or in any of the policy files identified in jre/lib/security/java.security. JACC leverages the replacability afforded by the JRE to enable replacability of the container policy decision subsystem.[Read More]

When you deploy a portable application or module on Glassfish, you don't need to define an application specific principal to role mapping. Glassfish allows you to activate a default mapping that will be applied on behalf of all applications that are (subsequently) deployed without an application specific mapping. This feature of glassfish is described in more detail in: Roles, Principals, and Principal to Role Mapping. The default mapping is canonical in that it maps groups to same-named roles. For example group principal "user" is mapped to role "user". Applications or modules deployed before the default mapping is activated, are unaffected.