Part I Development Tasks and Tools
1. Setting Up a Development Environment
Part II Developing Applications and Application Components
GlassFish Server Specific Security Features
Roles, Principals, and Principal to Role Mapping
How to Set a Realm for an Application or Module
Pluggable Audit Module Support
Changing Permissions for an Application
Enabling and Disabling the Security Manager
Configuring Message Security for Web Services
Message Security Responsibilities
Application Developer Responsibilities
Application Deployer Responsibilities
System Administrator Responsibilities
Application-Specific Message Protection
Using a Signature to Enable Message Protection for All Methods
Configuring Message Protection for a Specific Method Based on Digital Signatures
Understanding and Running the Sample Application
To Set Up the Sample Application
Programmatic Login Precautions
Granting Programmatic Login Permission
Adding Authentication Mechanisms to the Servlet Container
The GlassFish Server and JSR 196
Writing a Server Authentication Module
Sample Server Authentication Module
Compiling and Installing a Server Authentication Module
Configuring a Server Authentication Module
Binding a Server Authentication Module to Your Application
6. Using the Java Persistence API
7. Developing Web Applications
8. Using Enterprise JavaBeans Technology
9. Using Container-Managed Persistence
12. Developing Lifecycle Listeners
13. Developing OSGi-enabled Java EE Applications
Part III Using Services and APIs
14. Using the JDBC API for Database Access
15. Using the Transaction Service
16. Using the Java Naming and Directory Interface
The single sign-on feature of the GlassFish Server allows multiple web applications deployed to the same virtual server to share the user authentication state. With single sign-on enabled, users who log in to one web application become implicitly logged into other web applications on the same virtual server that require the same authentication information. Otherwise, users would have to log in separately to each web application whose protected resources they tried to access.
A sample application using the single sign-on scenario could be a consolidated airline booking service that searches all airlines and provides links to different airline web sites. After the user signs on to the consolidated booking service, the user information can be used by each individual airline site without requiring another sign-on.
Single sign-on operates according to the following rules:
Single sign-on applies to web applications configured for the same realm and virtual server. The realm is defined by the realm-name element in the web.xml file. For information about virtual servers, see Chapter 14, Administering Internet Connectivity, in Oracle GlassFish Server 3.1 Administration Guide.
As long as users access only unprotected resources in any of the web applications on a virtual server, they are not challenged to authenticate themselves.
As soon as a user accesses a protected resource in any web application associated with a virtual server, the user is challenged to authenticate himself or herself, using the login method defined for the web application currently being accessed.
After authentication, the roles associated with this user are used for access control decisions across all associated web applications, without challenging the user to authenticate to each application individually.
When the user logs out of one web application (for example, by invalidating the corresponding session), the user’s sessions in all web applications are invalidated. Any subsequent attempt to access a protected resource in any application requires the user to authenticate again.
The single sign-on feature utilizes HTTP cookies to transmit a token that associates each request with the saved user identity, so it can only be used in client environments that support cookies.
To configure single sign-on, set the following virtual server properties:
sso-enabled - If false, single sign-on is disabled for this virtual server, and users must authenticate separately to every application on the virtual server. The default is false.
sso-max-inactive-seconds - Specifies the time after which a user’s single sign-on record becomes eligible for purging if no client activity is received. Since single sign-on applies across several applications on the same virtual server, access to any of the applications keeps the single sign-on record active. The default value is 5 minutes (300 seconds). Higher values provide longer single sign-on persistence for the users at the expense of more memory use on the server.
sso-reap-interval-seconds - Specifies the interval between purges of expired single sign-on records. The default value is 60.
Here are example asadmin set commands with default values:
asadmin set server-config.http-service.virtual-server.vsrv1.property.sso-enabled="true" asadmin set server-config.http-service.virtual-server.vsrv1.property.sso-max-inactive-seconds="300" asadmin set server-config.http-service.virtual-server.vsrv1.property.sso-reap-interval-seconds="60"
For more information about the asadmin set command, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.