| Previous Contents Index DocHome Next |
| iPlanet Application Server Programmer's Guide (Java) |
Chapter 12 Writing Secure Applications
This chapter describes how to write a secure J2EE application for the iPlanet Application Server (iAS) with components that perform user authentication and authorization for access to servlets and EJB business logic.The following sections are included in this chapter:
iAS Security Goals
iAS Specific Security Features
Overview of Security Responsibilities
User Authentication by Servlets
User Authorization by Servlets
User Authentication for Single Sign-on
iAS Security Goals
In an enterprise computing environment, there are many security risks. The goal of iAS is to provide highly secure, interoperable distributed, component computing based on the J2EE security model. The security goals for iAS include:
Full compliance with the J2EE v1.2 security model (see the J2EE specification, v1.2 Chapter 3 Security)
Full compliance with the EJB v1.1 security model (see the Enterprise JaveBean specification v1.1 Chapter 15 Security Management). This includes EJB role based authorization.
Full compliance with the Java Servlet v2.2 security model (see the Java Servlet specification, v2.2 Chapter 11 Security). This includes Servlet role based authorization.
Support for single signon across all applications on iAS.
Security support for Rich Clients.
Use LDAP as the backend for security and allow administration of users during runtime.
Implement declarative iAS specific XML based role mapping information.
iAS specific XML files with declarative security will be created by the iAS Deployment Tool.
iAS Specific Security Features
iAS supports the J2EE v 1.2 security model, as well as the following features that are specific to iAS.
Single Signon across all applications on iAS.
iAS specific XML based role mapping information.
A GUI based deployment tool (iASDT) used to build the XML files that contain the security information.
iAS Security Model
Secure applications require the client to first be authenticated as a valid user of the application, and secondly to have the authorization to access the EJB business logic. iAS supports security for web clients and rich clients.Web clients use a browser and a web server to communicate using HTTP with servlets running on iAS. These clients require communication with servlets and JSPs to extend the functionality of the web server.
Applications with secure web containers and secure EJB containers may enforce the following security processes for web clients:
Rich clients, on the other hand, communicate over a bridge using RMI/IIOP to directly access EJBs running on iAS. Rich clients directly invokes bean methods.
Applications with secure EJB containers may enforce the following security processes for rich clients:
authorize the caller for access to the EJB business methods
The diagram below shows the iAS security model.
Web Client Authentication and URL Authorization
Secure web containers may have authentication and authorization properties. These containers support three types of authentication - basic, certificate and form based. When a web client requests the main application URL, the web server is responsible for collecting the user's authentication information (e.g. username and password) from the web client and passing it on to iAS.iAS consults the security policies (derived from the deployment descriptor) associated with the web resource to determine the security roles that are permitted access to the resource. The web container tests the user's credentials against each role to decide if it can map the user to the role. The Lightweight Directory Access Protocol (LDAP) server, an enterprise wide directory service for managing information about users, groups and roles, is used to get the user's credentials.
Web Client Invocation of Enterprise Bean Methods
Once the web client has been authenticated and authorized by the web container and the JSP performs a remote method call to the EJB, the user's credentials (gathered during the authentication process) are used to establish a secure association between the JSP and the bean. A secure EJB container has a deployment descriptor with authorization properties that are used to enforce access control on the bean method. The EJB container uses role information received from the LDAP server to decide whether it can map the caller to the role and allow access to the bean method.
Rich Client Invocation of Enterprise Bean Methods
For rich clients a secure EJB container will consult with it's security policies to determine if the caller has the authority to access the bean method. This process is the same for rich clients and web clients.
Overview of Security Responsibilities
A primary goal of the J2EE platform is to isolate the developer from the details of the security mechanisms and facilitate the secure deployment of an application in diverse environments. This goal is address by providing mechanisms for the specification of application security requirements declaratively and outside the application.
Application Developer
Programmatic security is supplied by the developer.
Specifies security levels.
Verifies security permission levels when secure operations are being accessed.
Application Assembler
The application assembler or application component provider must identify all the security dependencies embedded in a component including:
The names of all the role names used by the components to call isCallerInRole or isUserInRole.
References to all the external resources accessed by the components.
References to all inter-component calls made by the component.
Recommended that the assembler identifies which method calls of which components feature parameters and return values which should be protected for confidentiality and or integrity. The deployment descriptor is used for this purpose (9.4.3)
Application Deployer
The deployer takes the security view of the components, provided by the assembler, and uses them to secure in the application a particular enterprise environment. The deployer uses the iASDT to map the view provided by the assembler to the policies and mechanisms that are specific to the operational environment. The security mechanisms configured by the deployer are implemented by the containers on behalf of the components which are hosted in the containers.
Assigns groups of users to security levels
Refines the privileges required to access the methods of components, and to define the correspondence between the security attributes presented by the callers and the container privileges.
Common Security Terminology
Authentication
Authentication is the process that verifies that the user is who the user claims to be. For example, the user may enter her username and password in a Web browser, and if those credentials match the her permanent profile stored in the LDAP server then she is authenticated. She is now associated with a security identity for the remainder of the session.
Authorization
Authorization is the process of permitting a user to perform desired operations, after he has been authenticated. For instance, a human resources application may authorize managers to view personal employee information for all employees, but allow employees to only view their own personal information.
Role Mapping
A client may be defined in terms of a security role. For example, a company might use its employee database to generate both a company-wide phone book application, and to generate payroll information. Obviously, while all employees might have access to phone numbers and email addresses, only some employees would have access to salary information. Employees with the right to view or change salaries might be defined as having a special security role.A role is different from a user group in that a role defines a function in an application, while a group is a set of users that are related in some way. For example, members of the groups astronauts, scientists, and (occasionally) politicians all fit into the role of SpaceShuttlePassenger.
The EJB security model describes roles (as distinguished from user groups) as being described by an application developer and independent of any particular domain. Groups, by contrast, are specific to a deployment domain. The role of the deployer is to map roles into one or more groups.
In iAS, roles correspond to user groups configured in the Directory Server. LDAP groups can contain both users and other groups. Future versions of iAS will provide specific support for roles.
Container Security
The component containers are responsible for providing security for the J2EE application. There are two forms of security provided by the container:
Programmatic Security
Programmatic security is when an EJB or servlet uses method calls to the security API, specified by the J2EE security model, to make business logic decisions based on the security role of the caller or remote user. Programmatic security should only be implemented when declarative security alone is insufficient in meeting the needs of the application's security model.The J2EE Specification, v1.2 defines programmatic security as consisting of two methods of the EJB EJBContext interface and two methods of the servlet HttpServletRequest interface. iAS supports these interfaces as specified by this specification. For further details on programmatic security see section 3.3.6 Programmatic Security, of the J2EE Specification,v1.2 .
Declarative Security
Declarative security is when the security mechanism for an application is declared and handled externally to the application. Deployment descriptors (DDs) are used by iAS to describe the J2EE application's security structure, including security roles, access control, and authentication requirements.The deployment descriptors for security aware applications, web-app containers, and EJB containers, have security elements in the form of XML tags to express the security characteristics of the application. Security characteristics include authentication and authorization.
iAS supports the Document Type Descriptors (DTDs) specified by J2EE v1.2, and has additional security elements included in the iAS deployment descriptors.
Declarative security is the responsibility of the application deployer. The XML DDs are generated by the iAS Deployment Tool. See the Administration and Deployment Guide for details.
Application Level Security
The application XML DD contains authorization descriptors for all the roles a user can have when accessing the application's servlets and EJBs. On the application level, all roles used by any of the application's containers must be listed in this file. These roles are described by the role-name element in the application's XML DD file. These role names are scoped to the EJB XML DDs (ejb-jar files) and to the servlet XML DDs (web-war files).
Servlet Level Security
A secure web container needs to authenticate web client users and to authorize their access to the servlet. Once the user has been authenticated and authorized the servlet passes on user credentials to an EJB to establish a secure association with the bean.
EJB Level Security
The EJB container is responsible for authorizing access to a bean method by using the security policy laid out in the EJB XML deployment descriptor.
User Authentication by Servlets
The three web based login mechanisms required by J2EE Specification, v1.2 are supported by iAS. These three mechanisms include: HTTP basic authentication, SSL mutual authentication, and form-based login.The web application deployment descriptor login-config element, describes the authentication method to be used, the realm name to be used for this application by the HTTP basic authentication, and the attributes that are needed by the form login mechanism.
The syntax for the login-config element is as follows:
<!ELEMENT login-config (auth-method?,realm-name?,from-login-config?)>
For further details regarding web application deployment descriptor elements, refer to Chapter 13 Deployment Descriptor of the Java Servlet Specification, v2.2.
HTTP Basic Authentication
HTTP basic authentication (RFC2068) is supported by iAS. HTTP basic authentication protocol indicates the HTTP realm for which access is being negotiated. Because passwords are sent with base64 encoding, this type of authentication is not very secure.
SSL Mutual Authentication
Secure Socket Layer (SSL) 3.0 and the means to perform mutual ( client & server) certificate based authentication is a requirement of the J2EE Specification, v1.2. This security mechanism provides end user authentication using HTTPS (HTTP over SSL).The iAS SSL mutual authentication mechanism (also known as HTTPS authentication) supports the following cipher suites:
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
Form Based Login
The look and feel of the login screen cannot be controlled with the HTTP browser's built in mechanisms. J2EE introduces the ability to package a standard HTML or Servlet/JSP based form for logging in. The login form is associated with a web protection domain ( an HTTP realm) and is used to authenticate previously unauthenticated users.In order for the authentication to proceed appropriately, the action of the login form must always be "j_security_check".
The following is an HTML sample showing how the form should be coded into the HTML pages:
<form method="POST" action="j_security_check">
<input type="text" name="j_user_name">
<input type="password" name="j_password">
</form>
User Authorization by Servlets
Servlets can be configured to only permit access to user's with the appropriate level of authorization. This is done by using the iAS Deployment Tool to generate deployment descriptors (DD) for the application Ear file and servlet War files.
Defining Roles
All role names for the entire application are declared in the application XML DD. The security-role and role-name elements in the application XML DD will declare all role names permitted by this application.These security roles are scoped to the J2EE web application deployment descriptor.The security-role element is a sub element of the application element in the application XML DD. The syntax for the security-role element is as follows:
The security-role element defines a security role which is global to the application. There are two sub elements; the first is a description of the security role, and the second is the name of the security role.
<!ELEMENT security-role (description?, role-name)>
The role-name element contains the name of a role.
<!ELEMENT role-name (#PCDATA)>
Referencing Security Roles
For each servlet, the web application DD will declare all roles authorized to have access to it. The security-rol-ref and role-link elements in the web-app XML DD will link the authorized roles to the role name on the application level.The application assembler is responsible for linking all the security role references declared in the security-role-ref elements to the security roles defined in the security-role elements.
The application assembler links each security role reference to a security role using the role-link element. The value of role-link element must be the name of one of the security roles defined in a security-role element.
The following deployment descriptor example shows how to link the Sudety role reference named payroll to the security role named payroll-department.
<!ELEMENT security-role-ref (description?, role-name, role-link)>
<!ELEMENT role-link (#PCDATA)>
Defining Method Permissions
On the servlet level define method permissions using the auth-constraint element of the web-app XML DD.The auth-constraint element on the resource collection must be used to indicate the user roles that should be permitted to this resource collection. The role used here must appear in a security-role-ref element.
<!ELEMENT auth-constraint (description?, role-name*)>
Sample web application DD
The security section of a sample web application deployment descriptor might look as follows:<web-app>
<display-name>A Secure Application</display-name>
<security-role>
<role-name>manager</role-name>
</security-role><servlet>
<servlet-name>catalog</servlet-name>
<servlet-class>com.mycorp.CatalogServlet</servlet-class>
<init-param>
<param-name>catalog</param-name> <param-value>Spring</param-value>
</init-param>
<security-role-ref>
<role-name>MGR</role-name> <!-- role name used in code -->
<role-link>manager</role-link>
</security-role-ref>
</servlet><servlet-mapping>
<servlet-name>catalog</servlet-name> <url-pattern>/catalog/*</url-pattern>
</servlet-mapping>
<web-resource-collection> <web-resource-name>SalesInfo</web-resource-name> <urlpattern>/salesinfo/*</urlpattern> <http-method>GET</http-method>
<http-method>POST</http-method>
<user-data-constraint> <transport-guarantee>SECURE</transport-guarantee> </user-data-constraint>
<auth-constraint>
<role-name>manager</role-name>
</auth-constraint>
</web-resource-collection>
</web-app>
User Authorization by EJBs
EJBs can be configured to only permit access to user's with the appropriate level of authorization. This is done by using the iAS Deployment Tool to generate deployment descriptors (DD) for the application Ear file and EJB jar files.
Defining roles
The application assembler can define one or more roles in the deployment descriptor. The application assembler then assigns groups of methods of the enterprise bean's home and remote interfaces to the security roles to define the security view of the application.The deployer assigns the user groups and user accounts defined in the operational environment to security roles defines by the application assembler.
The application assembler is responsible for the following:
Define each security role using a security-role element
The Security roles defined by the security-role elements are scoped to the ejb-jar file level and apply to all the enterprise beans in the ejb-jar files. ( The J2EE specification does not say anyway to define global roles, which are global to container).Use the role-name element to define the name of the security role
Optionally use the description element to provide a description of a security role
The following is an example of security role definition in a deployment descriptor:
This role includes the employees of the enterprise who are allowed to access the employee self service application. This role is allowed to access only her/his information
</desciption> <role-name>employee<role-name>
</security-role>
<security-role>
<description>
This role should be assigned to the personnel authorized to perform administrative functions for the employee self service application. This role does not have direct access to sensitive employee and payroll information </desciption> <role-name>admin<role-name>
<security-role>Done by iASDT. Need to provide APIs for adding roles and role members.
The application assembler defines the method permissions relation in the deployment descriptor using the method permission elements as follows:
Each method-permission element includes a list of one or more security roles and a list of one or more methods. All the listed security roles are allowed to invoke all the listed methods. Each security role in the list is identified by the role-name element, and each method (or a set of methods, as described below) is identified by the method element. An optional description can be associated with a method-permission element using the description element.
The method permissions relation is defines as the union of the all method permissions defined in the individual method permission elements.
A security role or a method may appear in multiple method-permission elements.
The following example illustrates how security roles are assigned method permissions in the deployment descriptor.
<method-permission>
<role-name>employee</role-name>
<method>
<ejb-name>EmployeeService</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>
<method-permission>
<role-name>employee</role-name>
<method>
<ejb-name>AardvarkPayroll</ejb-name>
<method-name>findByPrimaryKey</method-name>
</method>
<method>
<ejb-name>AardvarkPayroll</ejb-name>
<method-name>getEmployeeInfo</method-name>
</method>
<method>
<ejb-name>AardvarkPayroll</ejb-name>
<method-name>updateEmployeeInfo</method-name>No interaction here, iASDT will convert these into security elements.
Security role references:
The Bean provider is responsible for declaring in the security-rol-ref elements of the deployment descriptor all the security role names used in the enterprise bean code.Application assembler is responsible for linking all the security role references declared in the security-role-ref elements to the security roles defined in the security-role elements.
The application assembler links each security role reference to a security role using the role-link element.
The value of role-link element must be the name of one of the security roles defined in a security-role element.
The following deployment descriptor example shows how to link the Sudety role reference named payroll to the security role named payroll-department.
<ejb-name>AardvarkPayroll</ejb-name>
<ejb-class>com.aardvark.payroll.PayrollBean</ejb-class>
This role should be assigned to the employees of the payroll department. Members of this role have access to anyone's payroll record. The role has been linked to the payroll-department role.
Realm
An application can specify that it wants to use for authentication and authorization.
User Authentication for Single Sign-on
The single sign-on across applications on iAS is supported by the iAS servlets and JSPs. This feature allows multiple applications that require the same user sign-on information, to share this information between them, rather than have the user sign-on separately for each application. These applications are created to authenticate the user one time, and when needed this authentication information is propagated to all other involved applications.An example 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. Once the user signs on to the consolidated booking service, her user information can be used by each of the individual airline sites without requiring her to sign on again.
How to Configure for Single Sign-on
The iAS specific deployment descriptor (DD) for the web container has an element, called session-info, that has fields to specify the authentication for the servlets and JSPs within the container. The DD is created by the iAS Deployment Tool (iASDT). This section concentrates on how the security fields for the session-info element in the DD work together to perform the single sign-on authentication. For details on how to create an iAS specific web container DD, see the Administration and Deployment Guide. For a complete description of all the session-info fields, refer to Chapter 10 "Packaging for Deployment".The session-info element has the following fields that are involved with the authentication process:
Single Sign-on Example
Consider two applications hosted on iAS named AirlineSearch and AirlineBooking. Both are part of the myairlines.com domain and require the user to be authenticated to access resources within these two applications. AirlineSearch allows the user to search on different airlines available in her part of the country, and AirlineBooking allows her to make bookings using her special preferences such as for seating among other things.The ias-web.xml for both AirlineService and AirlineBooking will contain the following:
<session-info>
<path>/iASApp</path>
<scope>AirlineSignon</scope>
</session-info>Now the user first accesses the services provided by the AirlineService application by saying:
http://www.myairlines.com/iASApp/AirlineService/showFlights
showFlights could be a servlet that shows all flights at the time the user requested. This requires the user to log in. Once the user has seen all the flights, she decides to book tickets and accesses:
http://www.myairlines.com/iASApp/AirlineService/bookFlights
This provides the service to book flights based on the user's preferences, which could already be available from the previous accesses and from the sign-on information provided to the previous AirlineService application.
Since both these applications are within the same domain, the domain field is not set in this example. But it is easy to see how this can be extended to share sign-on information between multiple domains.
User Authentication for Rich Client
Security on the Rich Client path is integrated with iAS' security infrastructure. The CXS uses iAS' security manager to authenticate clients with user information stored in LDAP. Client credentials are passed from the client, through the bridge to EJBs. A client side callback initiates client login (with username and password). The type of the object to be instantiated to obtain this information is specified through an environment setting on the client. In case of authentication failure, the client-side is setup to retry the login process. The number of retries is currently hard-coded to three.For more information on elements in the Rich Client deployment descriptor see section "Rich Client XML DTD," in Chapter 10, "Packaging for Deployment".
Guide to Security Information
Each of the following types of information is shown with a short description, the location where the information resides, how to create the information, how to access the information, and where to look for further information.
User Information
User name, password, etc.
How to Create:
Create using Mission Console, or programmatically using the LDAP SDK. See the Administration and Deployment Guide for more details.
Security Roles
Role that defines a function in an application, made up of a number of users and/or groups. LDAP groups function as roles in iAS.
How to Create:
Use the iAS Deployment Tool (iASDT).
How To Access:
Test for a user's membership in a role using isCallerInRole().
Previous Contents Index DocHome Next
Copyright © 2000 Sun Microsystems, Inc. Some preexisting portions Copyright © 2000 Netscape Communications Corp. All rights reserved.
Last Updated June 25, 2000