| Previous Contents Index Next |
| iPlanet Application Server Developer's Guide |
Chapter 13 Writing Secure Applications
This chapter describes how to write a secure J2EE application for the iPlanet Application Server with components that perform user authentication, and access authorization to servlets and EJB business logic.This chapter contains the following sections:
iPlanet Application Server Security Goals
iPlanet Application Server Specific Security Features
iPlanet Application Server Security Model
Security Responsibilities Overview
User Authentication by Servlets
User Authorization by Servlets
User Authentication for Single Sign-on
iPlanet Application Server Security Goals
In an enterprise computing environment there are many security risks. The iPlanet Application Server's goal is to provide highly secure, interoperable, and distributed component computing based on the J2EE security model. The security goals for the iPlanet Application Server include:
Full compliance with the J2EE v1.2 security model (for more information, see the J2EE specification, v1.2 Chapter 3 Security)
Full compliance with the EJB v1.1 security model (for more information, see the Enterprise JavaBean specification v1.1 Chapter 15 Security Management). This includes EJB role-based authorization.
Full compliance with the Java Servlet v2.2 security model (for more information, see the Java Servlet specification, v2.2 Chapter 11 Security). This includes servlet role-based authorization.
Support for single signon across all iPlanet Application Server applications.
Security support for RMI/IIOP Clients.
Use of LDAP as the backend for security and allows user administration during runtime.
Implements declarative iPlanet Application Server specific XML-based role mapping information.
The iPlanet Application Server specific XML files with declarative security created by the iPlanet Application Server Deployment Tool.
iPlanet Application Server Specific Security Features
The iPlanet Application Server supports the J2EE v1.2 security model, as well as the following features which are specific to the iPlanet Application Server:
Single signon across all iPlanet Application Server applications.
Security for RMI/IIOP Clients.
iPlanet Application Server specific XML-based role mapping information.
The GUI-based Deployment Tool is used to build XML files containing the security information.
iPlanet Application Server Security Model
Secure applications require a client to be authenticated as a valid application user and have authorization to access the EJB business logic. The iPlanet Application Server supports security for both web and RMI/IIOP clients.Web clients use a browser and a web server to communicate using HTTP with servlets running on the iPlanet Application Server. These clients require communication with servlets and JSPs to extend the web server functionality.
Applications with secure web and EJB containers may enforce the following security processes for web clients:
RMI/IIOP clients communicate over a bridge using RMI/IIOP to directly access EJBs running on the iPlanet Application Server. RMI/IIOP clients directly invokes bean methods.
Applications with secure EJB containers may enforce the following security processes for RMI/IIOP clients:
authorize the caller for access to the EJB business methods
The following diagram shows the iPlanet Application Server security model.
Web Client and URL Authorizations
Secure web containers may have authentication and authorization properties. The 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 authentication information (for example. username and password) from the web client and passing it to the iPlanet Application Server.The iPlanet Application Server consults the security policies (derived from the Deployment Descriptor (DD)) associated with the web resource to determine the security roles used to permit resource access. The web container tests the user credentials against each role to determine if it can map the user to the role. The LDAP server, an enterprise-wide directory service for managing information about users, groups and roles, obtains the user 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 DD with authorization properties which 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.
RMI/IIOP Client Invocation of Enterprise Bean Methods
For RMI/IIOP clients, a secure EJB container consults it's security policies to determine if the caller has the authority to access the bean method. This process is the same for both web and RMI/IIOP clients.
Security Responsibilities Overview
A J2EE platform's primary goal is to isolate the developer from the security mechanism details and facilitate a secure application deployment in diverse environments. This goal is addressed by providing mechanisms for the application security specification requirements declaratively and outside the application.
Application Developer
The application developer supplies the programmatic security including:
Specifying security levels.
Verifies the security permission levels when secure operations are being accessed.
Application Assembler
The application assembler or application component provider must identify all security dependencies embedded in a component including:
All role names used by the components that call isCallerInRole or isUserInRole.
References to all external resources accessed by the components.
References to all intercomponent calls made by the component.
Recommended that the assembler identify all method calls of each component's feature parameters and return values are to be protected for confidentiality and/or integrity. The Deployment Descriptor (DD) is used for this purpose.
Application Deployer
The iPlanet Application Server Deployment Tool is used to map the views provided by the assembler to the policies and mechanisms specific to the operational environment. The security mechanisms configured by the application deployer are implemented by the containers on behalf of the components hosted in the containers.The application deployer takes all component security views provided by the assembler and uses them to secure a particular enterprise environment in the application, including:
Assigning user groups to security levels.
Refines the privileges required to access component methods and defines the correspondence between the security attributes presented by the callers and the container privileges.
Common Security Terminology
The most common security processes are authentication, authorization, and roll mapping, the following sections define their terminology.
Authentication
Authentication verifies the user. For example, the user may enter a username and password in a web browser and if those credentials match the permanent profile stored in the LDAP server then the user is authenticated. The user is associated with a security identity for the remainder of the session.
Authorization
Authorization permits a user to perform the desired operations, after being authenticated. For example, 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 the 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 who 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 are specific to a deployment domain. The deployer's role is to map roles into one or more groups.
In the iPlanet Application Server, roles correspond to user groups configured in the directory server. LDAP groups can contain both users and other groups.
Container Security
The component containers are responsible for providing J2EE application security. There are two security forms provided by the container:
Programmatic Security
Programmatic security is when an EJB or servlet uses method calls to the security API, as specified by the J2EE security model, to make business logic decisions based on the caller or remote user's security role. Programmatic security should only be used when declarative security alone is insufficient to meet 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. The iPlanet Application Server supports these interfaces as specified in the specification. For more information on programmatic security, see section 3.3.6 Programmatic Security, in the J2EE Specification,v1.2, and ""Programmatic Login."
Declarative Security
Declarative security is when the security mechanism for an application is declared and handled externally to the application. DDs are used by the iPlanet Application Server to describe the J2EE application's security structure, including security roles, access control, and authentication requirements.The DDs for security aware applications, web-app containers, and EJB containers, have XML tags as security elements to express the application's security characteristics. Security characteristics include authentication and authorization.
The iPlanet Application Server supports the DTDs specified by J2EE v1.2 and has additional security elements included in the DDs.
Declarative security is the application deployer's responsibility. The XML DDs are generated by the iPlanet Application Server Deployment Tool. For more information, see the iPlanet Application Server Deployment Tool and the Administrator's Guide.
Application Level Security
The application XML DD contains authorization descriptors for all user roles when accessing the application's servlets and EJBs. On the application level, all roles used by any application container must be listed in this file. These roles are described by the role-name element in the application XML DD file. The 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 authenticates users and authorizes 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 DD.
User Authentication by Servlets
The three web-based login mechanisms required by the J2EE Specification, v1.2 are supported by the iPlanet Application Server. These three mechanisms include:
HTTP Basic Authentication
The web application DD login-config element describes the authentication method used, the application's realm name used by the HTTP basic authentication, and the form login mechanism's attributes.The login-config element syntax is as follows:
<!ELEMENT login-config (auth-method?,realm-name?,from-login-config?)>
For more information regarding web application DD elements, see Chapter 13, Deployment Descriptor of the Java Servlet Specification, v2.2.
HTTP Basic Authentication
HTTP basic authentication (RFC2068) is supported by the iPlanet Application Server. The HTTP basic authentication protocol indicates the HTTP realm by which access is being negotiated. Because passwords are sent with base64 encoding, this authentication type is not very secure.
Secure Socket Layer Mutual Authentication
Secure Socket Layer (SSL) 3.0 and the means to perform mutual (client/server) certificate-based authentication is a J2EE Specification, v1.2 requirement. This security mechanism provides user authentication using HTTPS (HTTP over SSL).The iPlanet Application Server 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 login screen's look and feel 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 login form action must always be j_security_check.
The following is an HTML sample showing how to program the form in an HTML page:
<form method="POST" action="j_security_check">
<input type="text" name="j_username">
<input type="password" name="j_password">
</form>
Programmatic Login
Programmatic login enables a user to log in programmatically in both the web container and the EJB container. Programmatic login is useful for these reasons:
It provides user authentication flexibility
It requires fewer method calls than other types of Authentication, for example form-based, which uses an intermediate servlet
It provides a common interface across the web and EJB containers
Form-Based vs. Programmatic Login
Suppose a web resource is deployed with security constraints using form-based authentication. To access any of these resources, the web connector must call FormAuthServlet, which checks if the user is already logged in. If the user is not, the login page is displayed to enable authentication.For programmatic login, web resources are deployed without security constraints. When a user accesses a web resource, FormAuthServlet is not called. Instead, the IProgrammaticLogin.login method is called, which authenticates the user explicitly. If this method fails, an AuthenticationException is thrown, otherwise, the user is logged in.
The IProgrammaticLogin Interface
The com.iplanet.ias.security.IProgrammaticLogin interface enables a user in web or EJB container to perform login programmatically. This interface provides the following methods:The interface is implemented by two java classes:
The WebProgrammaticLogin Class
Although you can create your own class that implements IProgrammaticLogin, this is not recommended. The provided classes save you from having to deal with the login API directly.
The WebProgrammaticLogin Class
The com.iplanet.ias.security.WebProgrammaticLogin class initializes the data members for programmatic login using the web container. You can use this class as is or create a subclass. Its signature is as follows:public class WebProgrammaticLogin extends java.lang.Object implements IProgrammaticLogin
Its one constructor is as follows:
public WebProgrammaticLogin(
javax.servlet.ServletContext p_ServletContext,
javax.servlet.http.HttpServletRequest p_HttpServletRequest,
javax.servlet.http.HttpServletResponse p_HttpServletResponse)
throws NullValueExceptionA com.iplanet.ias.security.NullValueException is thrown if any of the required WebProgrammaticLogin input parameters are null. Its signature is as follows:
public class NullValueException extends java.lang.Exception
Its one constructor is as follows:
public NullValueException(java.lang.String Msg)
WebProgrammaticLogin methods are described in the following sections.
The login Method
The login method allows a user to log in programmatically. Its signature is as follows:public void login(java.lang.String UserName, java.lang.String Password) throws ProgAuthenticationException, NullValueException
makes sure the user name and password are not null
A com.iplanet.ias.security.NullValueException is thrown if any of the required login input parameters are null.checks if another user is logged in
checks if ServletContext, HttpRequest, or HttpResponse are null
A com.iplanet.ias.security.ProgAuthenticationException is thrown if the authentication is unsuccessful. Its signature is as follows:
public class ProgAuthenticationException extends com.netscape.server.servlet.servletrunner.AuthenticationException
Its one constructor is as follows:
public ProgAuthenticationException(java.lang.String Msg)
The logout Method
The logout method allows a user to log out. Its signature is as follows:public void logout(boolean flag)
What logout does depends on the setting of flag:
If flag is false, removes the principal attribute from the session (soft logout)
The isLoggedIn Method
The isLoggedIn method returns true if a user is already logged in. Its signature is as follows:
The loggedUserName Method
The loggedUserName method returns the principal name of the logged user, or null if no user is logged in. Its signature is as follows:public java.lang.String loggedUserName()
The EjbProgrammaticLogin Class
The com.iplanet.ias.security.EjbProgrammaticLogin class initializes the data members for programmatic login using the EJB container. You can use this class as is or create a subclass. Its signature is as follows:public class EjbProgrammaticLogin extends java.lang.Object implements IProgrammaticLogin
Its one constructor is as follows:
public EjbProgrammaticLogin() throws NullValueException
A com.iplanet.ias.security.NullValueException is thrown if the SecurityContext member variable is null when creation of an EjbProgrammaticLogin instance is attempted. Its signature is as follows:
public class NullValueException extends java.lang.Exception
Its one constructor is as follows:
public NullValueException(java.lang.String Msg)
EjbProgrammaticLogin methods are described in the following sections.
The login Method
The login method allows a user to log in programmatically. Its signature is as follows:public void login(java.lang.String userName, java.lang.String password) throws ProgAuthenticationException, NullValueException
makes sure the user name and password are not null
A com.iplanet.ias.security.NullValueException is thrown if any of the required login input parameters are null.checks if another user is logged in
A com.iplanet.ias.security.ProgAuthenticationException is thrown if the authentication is unsuccessful. Its signature is as follows:
public class ProgAuthenticationException extends com.netscape.server.servlet.servletrunner.AuthenticationException
Its one constructor is as follows:
public ProgAuthenticationException(java.lang.String Msg)
The logout Method
The logout method allows a user to log out. Its signature is as follows:public void logout(boolean flag)
For the EJB container, this method removes the principal name of the logged user from the SecurityContext regardless of the flag value.
The isLoggedIn Method
The isLoggedIn method returns true if a user is already logged in. Its signature is as follows:
The loggedUserName Method
The loggedUserName method returns the principal name of the logged user, or null if no user is logged in. Its signature is as follows:public java.lang.String loggedUserName()
User Authorization by Servlets
Servlets can be configured to only permit access to user's with the appropriate authorization level. This is done by using the iPlanet Application Server Deployment Tool to generate DDs for the application .ear 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 declare all role names permitted by the application. These security roles are scoped to the J2EE web application DD.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 declares all roles authorized to have access. The security-rol-ref and role-link elements in the web-app XML DD links the authorized roles to the application level role name.The application assembler is responsible for linking all 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 role-link value element must be one of the security role names defined in a security-role element.
The following DD example shows how to link the security role reference to the security role.
<!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 permitted to the 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 DD 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 users with the appropriate authorization level. This is done by using the iPlanet Application Server Deployment Tool to generate the DD for the application .ear and EJB .jar files.EJBs can use programmatic login just as servlets do. For more information, see "Programmatic Login."
Defining Roles
The deployer assigns the user groups and user accounts defined in the operational environment, to security roles defined by the application assembler.The application assembler defines one or more roles in the DD. The application assembler then assigns the enterprise bean's home and remote interfaces method groups to the security roles to define the application's security view.
The application assembler is responsible for defining the following:
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 enterprise beans in the ejb-jar files. (The J2EE specification does not say a way to define global roles, that is those roles global to the container).Uses the role-name element to define the security role name
Optionally, can use the description element to provide a security role description
The following is an example of a security role definition in a DD:
...
<assembly-descriptor>
<security-role>
<description>
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>
... <assembly-descriptor>
Defining Method Permissions
The application assembler defines the method permissions relation in the DD 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 listed security roles are allowed to invoke all 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 defined as the union of 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 DD.
...
<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>
</method
</method-permission>
...There is no interaction here. The Deployment Tool converts these into security elements.
Security Role References
The bean provider is responsible for declaring in the security-rol-ref elements of the DD all security role names used in the enterprise bean.The application assembler is responsible for linking all 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 role-link element value must be one of the security role names defined in a security-role element.
The following DD example shows how to link the Sudety role reference named payroll to the security role named payroll-department.
...
<enterprise-beans>
...
<entity>
<ejb-name>AardvarkPayroll</ejb-name>
<ejb-class>com.aardvark.payroll.PayrollBean</ejb-class>
...
<security-role-ref>
<description>This role should be assigned to the payroll department's employees. Members of this role have access to anyone's payroll record. The role has been linked to the payroll-department role.
</description>
</security-role-ref>
....
</entity>
...
</enterprise-bean>
User Authentication for Single Sign-on
The single sign-on across applications on the iPlanet Application Server is supported by the iPlanet Application Server servlets and JSPs. This feature allows multiple applications that require the same user sign-on information, to share this information between them, rather than having 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 the user information can be used by each individual airline site without requiring another sign on.
How to Configure for Single Sign-on
The iPlanet Application Server specific 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 Deployment Tool. This section concentrates on how the session-info element's security fields in the DD work together to perform the single sign-on authentication. For details on how to create an the iPlanet Application Server specific web container DD, see the iPlanet Application Server Deployment Tool and the Administrator's Guide. For a complete description of all the session-info fields, refer to Chapter 11 "Packaging for Deployment."Table 13-1 shows the session-info element fields used in the authentication process:
Single Sign-on Example
Consider two applications hosted on the iPlanet Application Server named AirlineSearch and AirlineBooking. Both are part of myairlines.com domain and require users to be authenticated to access resources within these two applications. AirlineSearch allows the user to search different airlines available and AirlineBooking allows users to make bookings using the user's special preferences, for example, seating, menu, departure times, and so on.The ias-web.xml for both AirlineSearch and AirlineBooking contains the following:
<session-info>
<path>/iASApp</path>
<scope>AirlineSignon</scope>
</session-info>Now the user first accesses the services provided by the AirlineSearch application using the following URL:
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 flights and 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 applications are within the same domain, the domain field is not set in this example. But this can be extended to share sign-on information among multiple domains.
User Authentication for RMI/IIOP Clients
Security on a RMI/IIOP client path is integrated into the iPlanet Application Server security infrastructure. The CXS uses the iPlanet Application Server 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 object type 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 hardcoded to three (3).For more information on elements in the RMI/IIOP client DD, see "RMI/IIOP Client XML DTD."
Guide to Security Information
Each information type below 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, and so on.
How to Create:
Create using Mission Console or programmatically using the LDAP SDK. For more information, see the iPlanet Application Server Deployment Tool Help and the Administrator's Guide.
Security Roles
Role that defines an application function, made up of a number of users and/or groups. LDAP groups function as roles in the iPlanet Application Server.
How to Create:
Use the iPlanet Application Server Deployment Tool.
How To Access:
Use isCallerInRole() to test for a user's role membership.
Web Server to Application Server Component Security
Beginning with iPlanet Application Server 6.0 SP2, developers can selectively encrypt the traffic between the web servers and the KXS per component. The encryption is done using 128 bit keys and RSA Bsafe3.0 library. It is recommended that developers turn on encryption judiciously for those components (servlets/JSPs) that require high security, such as credit card information gathering servlets, login servlets, and so on.To enable encryption of the traffic between these components, you must enable the application server itself to support encryption. The steps required are:
Set CCS0\\SECURITY\\EnableEncryption=D (for Domestic 128 bit, data type String).
For every component that needs encryption enabled, follow these steps:Create an entry or value CCS0\\SECURITY\\LogEncryption=1 (data type integer). If you want to verify the encryption log messages in the KXS logs.
Create a key CCS0\\EXTENSIONS\\CRYPTEXT\\CRYPTSVC\\ENGINES\\0.
Register the application using j2eeappreg, webappreg, or iasdeploy (recommended).
To verify that encryption is enabled and working fine, open the KXS logs and search for messages similar toSet <encrypt>true</encrypt> in the ias-web.xml file for the component (servlet/JSP) that you wish to encrypt.
[11/Jan/2001 19:58:43:0] info: CRYPT-003: Encrypting 2309 bytes, keysize = 128 bits
[11/Jan/2001 19:58:43:5] info: NSAPICLI-012: plugin reqstart, tickct: 1903570535
[11/Jan/2001 19:58:43:5] info: NSAPICLI-009: plugin reqexit: 0s+.12995s. (198114 0537)
[11/Jan/2001 19:58:52:2] info: CRYPT-004: Decrypting 1897 bytes, keysize = 128 bits
Previous Contents Index Next
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.
Last Updated March 06, 2002