GlassFish - World's first Java EE 7 Application Server


GlassFish V3 Security One Pager

[

Unknown macro: {TableOfContents title=' '}

|(TableOfContentstitle='')]

1. Introduction

1.1. Project/Component Working Name:

Name of the Project or Component

1.2. Name(s) and e-mail address of Document Author(s)/Supplier:

Name: Kumar Jayanti (vbkumar.jayanti@sun.com)

1.3. Date of This Document:

12/15/08

2. Project Summary

2.1. Project Description:

This document describes the proposed enhancements to security service in V3.

See below for a longer, more detailed technical description.

2.2. Risks and Assumptions:

  1. Assumption: Same level of Security support as in V2 (Feature Compatibility with Glassfish V2). All security features that worked in V2 will work in V3 in a backward compatible manner, including binary backward compatibility for proprietary : Realm and Audit Module SPI's.

3. Problem Summary

This document describes the set of enhancements to security service in Glassfish v3. The set of enhancements fall under two categories :

  1. Enhancements and/or compliance requirements as defined in JavaEE 6 specification.
  2. Product specific enhancements.

3.1. Problem Area:

  1. Ensure full support for entire JSR 196 SPI (Java EE6 may mandate only the servlet profile of the SPI)
  2. Support for all Security related proposals in Servlet 3.0/JavaEE 6
  3. Update JACC Provider and Container security service implementation to be JSR 115 MR 1.3 compatible
  4. Support For HTTP Digest Authentication (http://www.ietf.org/rfc/rfc2617.txt) with Enhanced JDBC Realm
  5. Support alternative InMemory Implementation of JACC Provider which does not depend on Policy Files
  6. Support Custom Realms implemented as OSGI/HK2 Modules
  7. Enhance Realm interface to allow Admin to perform User Management of any Realm (not just Realms that extend the FileRealm as in V2)
  8. Convert GlassFish Security Pipes into Tubes

3.2. Justification:

Security is an integral part of Java EE platform and the problems described herein are primarily driven by platform compliance requirements for JavaEE 6 and Product differentiation.

4. Technical Description:

4.1. Details:

This section has the details of the stated Problem Area's.

4.1.1 Ensure full support for entire JSR 196 SPI.

The version of JSR 196 to be included in JavaEE 6 is likely MR 1.1. GlassFish V2 has support for Version 1.0 of the specfication. The Java EE 6 specification may only mandate the Servlet Profile of the specification but GlassFish V3 would have full support for all the profiles (Servlet, SOAP and optionally Login Bridge Profile) of the SPI.

4.1.2 Support for Security related proposals in JavaEE6(Servlet 3.0)

A few Security related proposals which may end up in the JavaEE6/Servlet 3.0 specification would be supported to ensure compliance.

4.1.3 Update JACC Provider and Container security service implementation to be JSR 115 MR 1.3 compatible.

Glassfish V2 supported version 1.1 of the JSR 115 specification. There has since been an MR 1.2 and it is now supported in V3 prelude and has been ported to V2.1.

There will likely be another MR 1.3 in connection with one of the proposals in Servlet 3.0 which would require changes to the containers constraint translation handling.

4.1.4 Support For HTTP Digest Authentication (http://www.ietf.org/rfc/rfc2617.txt) with Enhanced JDBC Realm

GlassFish V3 would support HTTP Digest Authentication with Enhanced JDBC Realm. This feature is already in V3-Prelude and has also been backported to V2.1

4.1.5 Support an alternative InMemory implementation of JACC Provider which does not depend on Policy Files. Provide an easy way of configuring it in V3.

Glassfish V3 would support an alternative InMemory implementation of the JSR 115 Provider. This would be available to glassfish users as an alternate provider that can be easily configured as the default via the Admin GUI. When configured this provider would be used for all deployed applications.

The advantage of this provider is that it would not generate static policy files like the current (default) provider in GlassFish V2. Instead it would process the security constraint information of an application at load time and create in memory policy. This would provide simplifications in a clustered scenario where synchronization of static policy files is used currently in GlassFish V2. The downside ofcourse is the need to digest the web.xml security constraints everytime the application is loaded.

This JACC Provider would also provide a way to plugin an application sepcific RoleMapper which has been a requirement from some of the users.

V3-Prelude already includes this provider as a configurable provider in domain.xml. However the Admin GUI support is incomplete, this provider has also not been used to test CTS and TCK compliance of GlassFish V3, these are planned for the V3 Final Release.

4.1.6 Support Custom Realms implemented as OSGI/HK2 Modules

Support Custom Realms implemented as OSGI/HK2 Modules. Also included with this is the added ability to load such Realms without requiring a server restart. The Metadata for such realms would still need to be in domain.xml for now.

Currently with Glassfish V2 a restart of the server is required after placing the custom realm jars (non-OSGI enabled) inside glassfish. There was also a need to update classpath-prefix in V2 for loading custom realms, but this will not be required in V3 (for non-OSGI enabled realms). The custom realm jars can be dropped into domains/domainx/lib. The

4.1.7 Enhance Realm interface to allow Admin to perform User Management of any Realm (not just Realms that extend the FileRealm as in V2)

The Realm Interface should allow user management of any realm (add, remove user) and not just Realms that are an instanceof FileRealm. The Adming GUI needs to be updated to allow Realms to be managed Via the Admin GUI. A Realm would also indicate whether it supports User Management thereby allowing the Admin GUI to manage only those Realms which support user management.

Part of the work has been done for V3-Prelude, but it needs to be take to completion (which includes documentation updates and testing).

4.1.8 Convert GlassFish Security Pipes into Tubes

The Tube abstraction in JAXWS supports Asnychrony whereas the use of Pipe abstraction leads to threads being held for the rest of the Pipeline to complete before it relinquishes the thread. This can cause scalability problems. Currently GlassFish V2 has two security pipes (ClientSecurityPipe and CommonServerSecurityPipe) which would need to converted to Tubes.

4.2. Bug/RFE Number(s):

4.3. In Scope:

When we mention Feature Compatibility with Glassfish V2, it refers to Glassfish V2 and its Update releases.

4.4. Out of Scope:

The security features specific to SGCS (Glassfish V2.1), those that pertain to the communication server aspect are out of scope of this release.

4.5. Interfaces:

4.5.1 Exported Interfaces

  • Interface: sun-domain_x_x.dtd, sun-web-app_2_x.dtd, sun-ejb-jar_x_x.dtd, sun-application_x_x.dtd, sun-application-client_x_x.dtd
  • Stability: Evolving
  • Former Stability (if changing):
  • Comments: Various piecies of information required by the Security Service can be specified under elements defined in these descriptors. The Glassfish security-service itself is configured using information in domain.xml (instance of sun-domain_*.dtd)

4.5.2 Imported interfaces

  • Interface: javax.security.jacc
  • Stability: Standard
  • Exporting Project: JSR 115

(http://javadoc.glassfish.org/javaee6/apidoc/javax/security/jacc/package-frame.html)

  • Comments: The JACC API implemented by the JACC Provider(s) in Security Module
  • Interface: javax.security.auth.message
  • Stability: Standard
  • Exporting Project: JSR 196

(http://javadoc.glassfish.org/javaee6/apidoc/javax/security/auth/message/package-frame.html)

  • Comments: The JSR 196 API implemented by the 196 Provider in Security Module
  • Interface: javax.security.*
  • Stability: Standard
  • Exporting Project: J2SE
  • Comments:
  • Interface: com.sun.xml.ws.api.*
  • Stability: Evolving
  • Exporting Project: JAXWS

(https://jax-ws-architecture-document.java.net/nonav/doc21)

  • Comments: Security Module implements the Pipe and Tube interfaces to perform security processing in the JAXWS Tubeline.
  • Interface: web_app_2_x.xsd, ejb_jar_x_x.xsd, application.xsd, application-client_x_x.xsd
  • Stability: Standard
  • Exporting Project: Java EE 6
  • Comments: Application Specific Security configuration information is obtained from instances of these schemas as applicable.

4.5.3 Other interfaces (Optional)

Any private interfaces that may be of interest?

  • Interface: com.sun.enterprise.security.auth.realm.Realm
  • Stability: Evolving
  • Former Stability (if changing):
  • Exporting Project : Security Service
  • Comments: Used by Admin and contains methods that Realm Implementations can Override
    • ''com.sun.enterprise.security.auth.realm.Realm : exposes user management functions that are used by the Admin and supplied by concrete Realm implementations.
  • Interface: com.sun.enterprise.security.auth.realm.RealmsManager, RealmConfig
  • Stability: Evolving
  • Former Stability (if changing):
  • Exporting Project : Security Service
  • Comments: Used by Admin/AMX and contains methods to manage creation, deletion and update of Realms. The Admin (CLI/GUI/AMX) currently seem to use multiple entry points into the Realm Infrastructure. There is a need to unify this and make RealmsManager the sole entry point which manages everything that Admin (CLI/GUI/AMX) would ever require (This is planned for a later release)
  • Interface: com.sun.enterprise.security.SecurityContext
  • Stability: Evolving
  • Former Stability (if changing):
  • Exporting Project : Security Service
  • Comments: Used in other modules such as connector-rutime
    • ''com.sun.enterprise.security.SecurityContext : Provides a way to set the current SecurityContext.

4.6. Doc Impact:

All the Proposed new features would need to be documented in the Glassfish Documentation Security Chapter. Since no new Non-Standard API's are being Exported there should be no impact to JavaDocs (other than upgrading to Java EE 6 JavaDocs).

4.7. Admin/Config Impact:

4.7.1 NetBeans Impact

At least one of the Security related proposals would require support from NetBeans

4.7.2 Adming GUI Impact

Items 4.1.5 and 4.1.7 will have admin impact, but part some work has already been done for V3 Prelude.

4.7.3 Config Impact

At least one of the Security related proposals would require addition to the web.xml schema.

4.8. HA Impact:

4.9. I18N/L10N Impact:

4.10. Packaging & Delivery:

Support for Solaris Realm and NSS Stores for Enterprise Profile would have some impact on Packaging. Methods of integrating Native Libraries in an OSGI world are currently being explored by the security team. The investigations would result in some changes/new addition to Packagaing and Delivery modules.

4.11. Security Impact:

This proposal does rely on the Java Policy framework, but does not add any additional requirements than what is already part of Glassfish V2.

4.12. Compatibility Impact

Glassfish V3 is a Modular system based on OSGI Principles. At the implementation level some of the exported interfaces in GlassFish V2 security service were Abstract classes that had dependencies on a lot of the rest of security infrastructure classes. We have encountered a situation where unrelated exported interfaces (which included abstract classes) were packaged in com.sun.appserv.security pacakge in Glassfish V2. Since Modularization is a major goal of V3, this packaging of unrelated exported interfaces in a single package has placed some restrictions on the Modularization goal. This problem was compounded by the fact the Modules in Glassfish V3 cannot have split packages.

So while favoring modularization the older version of the interface was retained by using a delagation mechanism. An interface was created to be used as a delegate in the original package. A service implementing the interface (potentially located in another module) was located using the service lookup mechanisms defined by HK2.

Since backward compatibility with V2 will be restored at any cost there will be no requirements on upgrade tool or migration tool.

4.13. Dependencies:

5. Reference Documents:

  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. Schedule:

6.1. Projected Availability:

Aligned to overall GlassFish V3 Final release schedules.