GlassFish Server Open Source Edition 3.1 - Security One Pager
GlassFish Server Open Source Edition 3.1 Security 1.2. Name(s) and e-mail address of Document Author(s)/Supplier:Kumar Jayanti (vbkumar.jayanti@sun.com) 1.3. Date of This Document:05/21/2010 2. Project Summary |
| Element Name | Effort Level (low/medium/high/unknown) | Priority | Glassfish Corresponding Element (if applicable) | Comments | |
|---|---|---|---|---|---|
| security-role-assignment:role-name | low | P3 | security-role-mapping:role-name in sun-web.xml | SECURITY | |
| security-role-assignment:principal-name | low | P3 | security-role-mapping:principal-name in sun-web.xml | SECURITY | |
| security-permission | medium | P3 | SECURITY | ||
| servlet-descriptor | low | P3 | We will implement run-as-principal-name. But not init-as-principal-name, destroy-as-principal-name as we do not distinguish run-as for init and destroy. SECURITY. The dispatch-policy is a deprecated element in weblogic.xml |
The security-permission feature in weblogic.xml allows Applications to bundle a single Java Policy grant {...} statement without any codebase and codesigner. The GlassFish Policy processing code would need to be enhanced to pick this additional grant. We may or maynot be able to support the security-permission element in GlassFish 3.1 since it requires enhancements and we were planning a more advanced feature here on the same lines (see SEC-009), but have marked it as P3 (would be taken up based on availability of time and resources).
The Weblogic servlet-descriptor element has the notions of principal names for init() and destroy() methods of the servlet. We plan to support only the run-as-principal-name and not the init-as-principal-name and destroy-as-principal-name.
1. CR :6913736
2. 11995
3. 11996
More Bugs and RFE's for all the tasks to be Filed.
The full set of New Security Features are being tracked in the V3.1Security Wiki. However the features SEC-003, SEC-009 to SEC-012, SEC-014 which are P3/P4 in nature will be taken up if the team gets time to work on them (before the SCF). Otherwise these features would be deferred to a later release.
Interfaces may be commands, files, directory structure, ports,
DTD/Schema, tools, APIs, CLIs, etc.
Note: In lieu of listing the interfaces in the one pager, providing
a link to another specification which defines the interfaces
is acceptable.
This list of Exported and Imported Interfaces in V3.1 is the same as V3. There are a few additions in the list of exported interfaces/classes detailed in sections 4.1.5.3 and 4.1.5.4 above.
The list of Private Interfaces in V3.1 are the same as those in V3
The following Interfaces/methods have been deprecated in V3.1 and new counterparts have been added for them. This is primarily done to deal with the issue that the original methods used Strings for storing Passwords whose values can only be removed by GarbageCollector. The new methods accept a char[] to facilitate clearing of collected password values; other than as a result of GC.
1. trunk/v3/security/core/src/main/java/com/iplanet/ias/security/auth/login/PasswordLoginModule.java
Deprecated:
public final AuthenticationStatus commitAuthentication(String username,
String password,
Realm theRealm,
String[] groups)
Newly added:
public final AuthenticationStatus commitAuthentication(String username,
char[] password,
Realm theRealm,
String[] groups)
2. trunk/v3/security/core/src/main/java/com/sun/appserv/security/AppservPasswordLoginModule.java
Deprecated:
protected String _password;
public String getPassword()
Newly added:
private char[] _passwd;
protected char[] getPasswordChar()
3. trunk/v3/security/core/src/main/java/com/sun/appserv/security/AppservRealm.java
Deprecated:
public void addUser(String name, String password, String[] groupList)
public void updateUser(String name, String newName, String password,
String[] groups)
Newly added:
public void addUser(String name, char[] password, String[] groupList)
public void updateUser(String name, String newName, char[] password,
String[] groups)
4. trunk/v3/security/core/src/main/java/com/sun/appserv/security/ProgrammaticLogin.java
Deprecated:
public Boolean login(final String user, final String password,
final String realm, boolean errors)
public Boolean login(final String user, final String password)
public Boolean login(final String user, final String password,
final String realm,
final HttpServletRequest request,
final HttpServletResponse response, boolean errors)
public Boolean login(final String user, final String password,
final HttpServletRequest request,
final HttpServletResponse response)
Newly added:
public Boolean login(final String user, final char[] password,
final String realm, boolean errors)
public Boolean login(final String user, final char[] password)
public Boolean login(final String user, final char[] password,
final String realm,
final HttpServletRequest request,
final HttpServletResponse response, boolean errors)
public Boolean login(final String user, final char[] password,
final HttpServletRequest request,
final HttpServletResponse response)
5. trunk/v3/security/core/src/main/java/com/sun/enterprise/security/auth/login/PasswordLoginModule.java
Deprecated:
public abstract class PasswordLoginModule extends AppservPasswordLoginModule
public final void commitAuthentication(String username,
String password,
Realm theRealm,
Newly added:
public final void commitAuthentication(String username,
char[] password,
Realm theRealm,
String[] groups)
6. trunk/v3/security/core/src/main/java/com/sun/enterprise/security/web/integration/WebPrincipal.java
Deprecated:
public WebPrincipal(String user, String password,
SecurityContext context)
Newly added:
public WebPrincipal(String user, char[] password,
SecurityContext context)
There is a desire to change the protected access to member(s)
protected String _username; protected String _password;
in AppservPasswordLoginModule to private access and introduce getter and setter methods. In addition the type of the _password should be changed to char[] instead of String. Doing this would break backward-compatibility of Custom-Realms defined by End-Users and it also likely to cause failures in SQE tests.
Currently we have just deprecated them and introduced new variants that just use getter and setter with private char[] for storing the password.
The other alternative is to introduce a new alternative base class which can serve as a replacement for AppservPasswordLoginModule where we have the correct access modifiers and data types. We could then deprecate AppservPasswordLoginModule class and make sure all the internal implementations of Realms in GlassFish make use of the new class.
The default-principal-password attribute in security-service is a legacy attribute which is unused in V3. Only the default-principal-name is used to initialize the Default Principal for the SecurityContext. This password attribute appears in the admin-gui and needs to be removed.
All the Proposed new features would need to be documented in the Glassfish Documentation Security Chapter. The Non-Standard API's which have been deprecated and their new variants/alternatives would also need to be documented See section for the list of deprecated API's and their replacements. Since no new Standard API's are being Exported there should be no impact to JavaEE 6 JavaDocs.
There is however one proposal sent to Servlet Expert Group which could result in a change to the JavaEE 6 Javadocs.
we should deprecate: public void login(String username, String password) throws ServletException; in favor of public void login(String username, char[] password) throws ServletException; to facilitate clearing of collected password values; other than as a result of GC.
There is text in "asadmin create-auth-realm --help" which talks about support for a non-existent property "clientAuth" for the CertificateRealm to enable client authentication for all apps. This needs to be removed if it is also present in the Docs (see 4.7 below).
Admin GUI/CLI support will be required for the following :
1. LoginModule configuration for CertificateRealm
2. PAMRealm and PAMLoginModule configuration in GUI and CLI
3. The OAM integration work would produce a SAM (JSR-196 Server Authentication Module) that should be configurable at Global-Instance-Level and individual Application-Level. We may endup levaraging the existing message-security-config element under security-service (for which Admin GUI/CLI support exists today). But a little bit more investigation is needed to say what new support is required (if any)
4. CLI support in the form of an admin command to synchronize server.policy and login.conf from DAS to instances would be required. More details are here
5. The defaul-principal-password field appears under Admin GUI security-service. This should be removed as it is an unused filed (see section 4.5.3.1.1 above).
Bugs filed for the admin work are here. The buglist is not complete and will be completed soon.
6. There is text in "asadmin create-auth-realm --help" which talks about support for a non-existent property "clientAuth" for the CertificateRealm to enable client authentication for all apps. This needs to be removed. It is actually controlled by having an attribute "client-auth-enabled" set on the ssl child element of the protocol elements.
This requirement was communicated by the Admin GUI team to the security team.
1. Need to list out which group a user belongs to. This is getGroupNames (String realmName, String userName) method.
2. Need to know if a realm supports user management. This is supportsUserManagement(String realmName) method.
3. Get the list of predefined auth realm class. This is the getPredefinedAuthRealmClassNames() method.
4. There doesn't seem to be a way of using CLI to change a user password. The current CLI
Usage: asadmin [asadmin-utility-options] update-file-user [--groups <groups>]
[--authrealmname <authrealmname>] [--target <target>]
[-?|--help[=<help(default:false)>]] username
doesn't allow change of password.
However, the man page says: This subcommand updates an existing entry in the keyfile using the specified user name, password and groups.
There is no HA impact of this proposal. The Clustering Impact is discussed above
None
The only new external dependency that this project introduces is libpam4j.
None.
There are no new requirements imposed on upgrade tool and migration tool other than those in V3. There is one small item for the upgrade tool which is that the server.policy file in V3.1 may be a little cleaned up w.r.t grants given to applications and untrusted code. See section above
This proposal does rely on the Java Policy framework, but does not add any additional requirements than what is already part of Glassfish V2.
Incompatible changes to interfaces that others expect to be stable may cause other parts of application server or
other dependent products to break.
Discuss changes to the imported or exported interfaces.Describe how an older version of the interface would
be handled.
An internal dependency is a dependency on a project, module,
component or product that is within the GlassFish project.
An external dependency is a dependency on a project, component
or product that resides outside of the GlassFish project.
The Security Module in GlassFish V3.1 depends on the following internal modules.
<groupId>org.glassfish.admin</groupId>
<artifactId>config-api</artifactId>
<version>${project.version}</version>
<groupId>org.glassfish.deployment</groupId>
<artifactId>dol</artifactId>
<version>${project.version}</version>
<groupId>org.glassfish.common</groupId>
<artifactId>common-util</artifactId>
<version>${project.version}</version>
<groupId>org.glassfish.deployment</groupId>
<artifactId>deployment-common</artifactId>
<version>${project.version}</version>
<groupId>org.glassfish.common</groupId>
<artifactId>internal-api</artifactId>
<version>${project.version}</version>
<groupId>org.glassfish</groupId>
<artifactId>javax.servlet</artifactId>
<version>${project.version}</version>
<groupId>org.glassfish.common</groupId>
<artifactId>glassfish-api</artifactId>
<version>${project.version}</version>
<groupId>org.glassfish</groupId>
<artifactId>javax.ejb</artifactId>
<version>${project.version}</version>
<groupId>org.glassfish.ejb</groupId>
<artifactId>ejb-internal-api</artifactId>
<version>${project.version}</version>
<groupId>org.glassfish.connectors</groupId>
<artifactId>connectors-internal-api</artifactId>
<version>${project.version}</version>
<groupId>org.glassfish.orb</groupId>
<artifactId>orb-iiop</artifactId>
<version>${project.version}</version>
<groupId>org.glassfish.orb</groupId>
<artifactId>orb-connector</artifactId>
<version>${project.version}</version>
<groupId>org.glassfish.core</groupId>
<artifactId>kernel</artifactId>
<version>${project.version}</version>
<groupId>org.glassfish.deployment</groupId>
<artifactId>deployment-common</artifactId>
<version>${project.version}</version>
<groupId>org.glassfish.web</groupId>
<artifactId>web-glue</artifactId>
<version>${project.version}</version>
<groupId>org.glassfish.webservices</groupId
<artifactId>jsr109-impl</artifactId>
<version>${project.version}</version>
<groupId>org.glassfish.appclient</groupId>
<artifactId>acc-config</artifactId>
<version>${project.version}</version>
<groupId>org.glassfish.web</groupId>
<artifactId>web-core</artifactId>
<version>${project.version}</version>
<groupId>org.glassfish.web</groupId>
<artifactId>war-util</artifactId>
<version>${project.version}</version>
<groupId>com.sun.grizzly</groupId>
<artifactId>grizzly-utils</artifactId>
The External Dependencies in GlassFish V3.1 Security Module are the same as in GlassFish V3, with one new addition. The PAMRealm support requires a new external dependency on libpam4j. The libpam4j is a java.net OpenSource project that uses MIT License.
The external dependencies in GlassFish V3 Security Module included HK2, the LDAP Booster Pack (ldapbp-repackaged.jar) from the JDK JNDI team, the libsolsparcauth.so and libsolx86auth.so files required by SolarisRealm which are produced from native code which is present in the V3 workspace, the management-api and GMBAL API, the following ORB API's
<groupId>com.sun.corba</groupId>
<artifactId>glassfish-corba-csiv2-idl</artifactId>
<groupId>com.sun.corba</groupId>
<artifactId>glassfish-corba-omgapi</artifactId>
<groupId>com.sun.corba</groupId>
<artifactId>glassfish-corba-orb</artifactId>
and the following Metro (WebServices) API :
<groupId>com.sun.xml.ws</groupId>
<artifactId>webservices-osgi</artifactId>
<groupId>javax.xml</groupId>
<artifactId>webservices-api-osgi</artifactId>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-osgi</artifactId>tId>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api-osgi</artifactId>
These external dependencies, along with instructions on how to do source build for them are being tracked here.
New Tests will need to be written for all features which have been marked for QA hand-off. The development team would write Automated DevTests which will be used for the QA-HandOff procedure.
1. JSR 196 : http://jcp.org/en/jsr/detail-196
2. JSR 115 : http://jcp.org/aboutJava/communityprocess/maintenance/jsr115/index5.html
3. JSR 250 : http://jcp.org/en/jsr/detail-250
4. JSR 315 : http://jcp.org/en/jsr/detail-315
5. JSR 316 : http://jcp.org/en/jsr/detail-316
6. Security OnePager for GlassFish V3.0
The Milestone assignment and QA-Handoff dates are being tracked here.