Security challenges for Enterprise Java in an e-business … · 2019. 3. 22. · manage authentication and authorization with Java Authentication and Authorization Service (JAAS)

Security challengesfor Enterprise Javain an e-businessenvironment

by L. KovedA. NadalinN. NagaratnamM. PistoiaT. Shrader

As e-business matures, companies requireenterprise-scalable functionality for theircorporate Internet and intranet environments.To support the expansion of their computingboundaries, businesses have embraced Webapplication servers. These servers supportservlets, JavaServer PagesTM, and EnterpriseJavaBeansTM technologies, providing simplifieddevelopment and flexible deployment of Web-based applications. However, securing thismalleable model presents a challenge.Successful companies recognize that theirsecurity infrastructures need to address thee-business challenge. They are aware of thetypes of attacks that malevolent entities canlaunch against their servers and can planappropriate defenses.

The Java** technology has established itself inthe enterprise realm, both for the ease with

which developers can create component software andfor the platform-independence of the language. TheJava 2 Platform, Standard Edition (J2SE**) intro-duced a fine-grained, policy-based security modelthat is customizable and configurable into numer-ous protection domains, which are well-suited tocomponent-based software. To provide security fore-business, the Java platform builds upon a core setof technologies.

Enterprise security requires authentication to iden-tify a principal user based on the enterprise user reg-istry, authorization to enforce the enterprise secur-ity policies, encryption to keep informationconfidential, and pliable management of informa-tion. In the Java environment, these technologiesmanifest themselves through the J2SE security archi-tecture, Java Authentication and Authorization Ser-vice (JAAS), Java Cryptography Architecture (JCA),

Java Cryptography Extension (JCE), Java SecureSocket Extension (JSSE), Public-Key CryptographyStandards (PKCS), and support for the Public KeyInfrastructure (PKI).

This paper describes the infrastructure and the se-curity considerations that companies deploying aWeb application server (WAS) must consider. Wedelve into the set of Java security technologies thatcan be applied. In addition, this paper discusses thecurrent J2SE security architecture and security for theWAS environment, focusing on the challenges thatlie ahead as these architectures evolve to address en-terprise e-business needs.

Web application servers

Web application servers have recently come of age,supplementing and often surpassing traditional Webservers in their use and functionality in enterpriseenvironments. A WAS differs from a traditional Webserver because it provides a robust and flexible foun-dation for dynamic transactions and objects. Tradi-tional Web servers are constrained to servicing stan-dard HTTP (HyperText Transfer Protocol) requests,returning the contents of static HTML (HyperTextMarkup Language) pages and images or the outputfrom executed CGI (Common Gateway Interface)scripts. Some Web servers have tried to extend theirfunctionality by including Java servlet1 support. Serv-

rCopyright 2001 by International Business Machines Corpora-tion. Copying in printed form for private use is permitted with-out payment of royalty provided that (1) each reproduction is donewithout alteration and (2) the Journal reference and IBM copy-right notice are included on the first page. The title and abstract,but no other portions, of this paper may be copied or distributedroyalty free without further permission by computer-based andother information-service systems. Permission to republish anyother portion of this paper must be obtained from the Editor.

KOVED ET AL. 0018-8670/01/$5.00 © 2001 IBM IBM SYSTEMS JOURNAL, VOL 40, NO 1, 2001130

lets allow Java applications to be executed on theserver side and return dynamically generated infor-mation, in much the same way that a CGI script candynamically generate information. However, graft-ing servlet support onto a Web server does not pro-vide a complete solution to meet e-business require-ments.

A WAS provides a more scalable environment formodeling enterprise solutions, partly through the ex-ploitation of Java technology. A WAS supports Javaobjects in their simple and compound manifestations.Servlet support plays an important role, but a WASalso supports Enterprise JavaBeans** (EJB) andJavaServer Pages** (JSP) technologies.2 EJB technol-ogy provides an architecture for distributed trans-action-based objects, allowing developers to concen-trate on business logic, rather than its interaction withinfrastructure. Similarly, JSP technology provides de-velopers and administrators with a convenient wayto generate HTML or XML (Extensible Markup Lan-guage) via Java programming to generate dynamicinformation.

A WAS supports other functionality, but the blendof EJB, servlets, and JSP provides the foundation forrepresenting a model-view-controller (MVC)3,4 archi-tecture to developers. The modularity and focus ofpurpose in EJB represents the model. JSP and serv-lets represent the view through their ability to dynam-ically generate information (e.g., HTML, XML). Theclient system represents the controller.

WAS security environment

A WAS is more than just a grouping of Java objects.In the multiuser enterprise environment, a WAS alsoprovides integrated authentication and authorizationsupport for user transactions, whether they originatefrom Web browsers, client applications, or anotherWAS. This complex environment of both friendly andpotentially malicious entities requires answers to anumber of questions:

● How can users be authenticated to a WAS?● After authentication, to which objects and actions

are the users authorized?● How can the details of users’ transactions remain

hidden from unauthorized entities?

These questions fundamentally deal with the secur-ity issues of authentication, authorization, and en-cryption.

Objects that play a major role in the WAS environ-ment are client objects and server objects. Clientobjects include Web clients and application clients.Server objects include Web servers, WASs, securityservers, and user registry servers.

The physical WAS executing the supported Java ob-jects plays an important role, but it is just one mem-ber of the entire ensemble of processes that com-plete the WAS environment. Note the distinctionbetween the WAS and the WAS environment. The WASrepresents the server that handles requests for EJBobjects, servlets, and JSP pages. The WAS environ-ment encompasses all of the client and server ob-jects that have a direct or indirect interaction withthe WAS, including the WAS itself.

Clients to a WAS include Web browsers, Java clientapplications or applets, and pervasive devices, suchas mobile appliances. Client objects can originatefrom many different sources, but they can be cate-gorized into those from traditional Web browsers andthose from stand-alone applications.

A WAS typically does not directly service client re-quests. Web servers respond to HTTP requests forHTML pages or to execute CGI scripts. For more com-plex tasks, such as the manipulation of EJB objects,Web servers pass the service requests to the WAS.

Playing a quiet but essential role in the WAS envi-ronment, the security server maintains a consistentsecurity schema. It arbitrates user authentication andauthorization access to objects. To authenticateusers, as well as obtain the user’s authorization at-tributes and digital certificate information, the se-curity server obtains the information from an enter-prise user registry (e.g., LDAP server, OS/390* RACF*,and SecureWay* Policy Director).5

Security in the WAS environment is not limited toauthentication and authorization. Between the dif-ferent server and client objects, security also comesinto play through the use of encryption technologies.

Role of Java security technologies in a WASenterprise environment

This paper describes a set of Java security technol-ogies and how each of them plays a vital role in se-curing a WAS environment. This section describes thegeneral flows within the WAS environment. Later sec-tions discuss the role of security technologies withinthese flows in further detail.

IBM SYSTEMS JOURNAL, VOL 40, NO 1, 2001 KOVED ET AL. 131

Invoking a secure servlet from a Web client. In a typ-ical scenario, the user submits a request to a Webresource, such as a Java servlet, by specifying the uni-form resource locator (URL) corresponding to thatresource. Since it does not internally process serv-lets, the target Web server receives the request andforwards it on to the WAS (see Figure 1). The WASdetermines that the requested resource is protectedand the security collaborator must authenticate theuser. The security collaborator resides at the serv-er’s entry point to help broker requests with the se-curity server, based on security policies. If the policyrequires a user ID (identifier) and password, the Webserver may issue an HTTP basic challenge or post anHTML form to request authentication data from theuser. Tighter security policies may dictate a PKI-basedauthentication, where the user is required to presenta client digital certificate.

An administrator may configure a WAS with policiesbased on security specifications for Java servlets andmanage authentication and authorization with JavaAuthentication and Authorization Service (JAAS)modules. An authentication and authorization ser-vice may be written in Java code or interface to anexisting authentication or authorization infrastruc-ture. For a cryptography-based security infrastruc-

ture, the security server may exploit the Java Cryp-tography Architecture (JCA) and Java CryptographyExtension (JCE). To present the user with a usableinteraction with the WAS environment, the Webserver may employ a form of “single sign-on” to avoidredundant authentication requests. A single sign-onpreserves user authentication across multiple HTTPrequests so that the user is not prompted many timesfor authentication data (i.e., user ID and password).

Invoking a secure EJB object from a Java client. Javaclient applications may invoke EJB methods by sub-mitting a request to the WAS that hosts an EJB con-tainer. As with Web clients, Java security technol-ogies can play a role in the security decisions madeduring this request flow from a client application (seeFigure 2).

Based on the security policies, JAAS may be employedto handle the authentication process with the iden-tity of the Java client. After successful authentica-tion, the WAS security collaborator consults with thesecurity server. Based on the result of the authen-tication process and EJB security policies, the secur-ity collaborator will make an EJB authorization de-cision. If the authorization succeeds, the collaboratorwill enforce the delegation policy associated with that

Figure 1 Secure servlet invocation scenario

SERVLET ENGINE

WEB APPLICATION SERVER (WAS)

(JAVA SERVLET SECURITY, JAAS, JSSE)

(JCA/JCE, JAAS)

SECURITY CHECKS

PLUG-IN CONNECTIONS

SERVLET REQUEST

WEB SERVER

(SINGLE SIGN-ON, JSSE)

AUTHENTICATIONAND AUTHORIZATION

AUTHENTICATION CHALLENGE

j_username, j_password

WEB SERVERPLUG-IN

SECURESERVLET

SECURITYCOLLABORATOR

SECURITYSERVER

KOVED ET AL. IBM SYSTEMS JOURNAL, VOL 40, NO 1, 2001132

method. For example, if the delegation policy on amethod on SecureBean is set to enforce imperson-ation, when that method invokes a downstreamNextIncBean method, the method call will be per-formed under the client’s identity.

The WAS environment must ensure the confidenti-ality of information exchanged between the clientand the environment, as well as between servers, bymaintaining a mutually authenticated, secure com-munications channel for information flow. JSSE canbe used to establish these secure channels. EJB ob-jects can additionally exploit various security tech-nologies, such as those available with JCA, JCE, PKCS,and S/MIME (Secure Multipurpose Internet Mail Ex-tensions).

The environment and security flows just describedare relevant to any enterprise. It is left to the im-plementation of such an environment to enforce var-ious security policies at relevant checkpointsthroughout the flow. The rest of this paper will de-scribe these security technologies and how they canbe used individually or combined to present a se-

cure Java environment for the WAS enterprise. Inparticular, this paper will cover the following tech-nologies:

● Enterprise JavaBeans (EJB)● Java Authentication and Authorization Service

(JAAS)● Servlet security● Java Cryptography Architecture (JCA) and Java

Cryptography Extension (JCE)● Java Secure Socket Extension (JSSE)● Public-Key Cryptography Standards (PKCS) and

Secure/Multipurpose Internet Mail Extensions(S/MIME)

Enterprise JavaBeans

Although they can service many heterogeneous ob-jects, WASs specialize in providing EJB containers. Ase-business applications progress from small-scale en-deavors to the demands of enterprise-wide solutions,most incorporate EJB objects to model the business.This section introduces the EJB security model and

Figure 2 Secure EJB invocation scenario

WEB APPLICATION SERVER

SECURITY CHECKS

EJB METHODINVOCATIONAUTHENTICATIONAND AUTHORIZATION

NEXTINCBEAN

DELEGATION

AUTHORIZATION

JAVA CLIENTAPPLICATION

(JCA/JCE, JAAS)

(EJB SECURITY JSSE, JAAS)

SECURITYCOLLABORATOR

SECURITYSERVER

SECUREBEAN


its support for authentication, authorization, and del-egation.

EJB is a server-side component-programming modelfor distributed transaction processing.6,7 The EJB 1.1specification6 prescribes a number of roles, includ-ing enterprise bean provider, application assembler, de-ployer, system administrator, EJB server provider, andEJB container provider. Each of these roles takes onspecific responsibilities in managing and implement-ing security.

As shown in Figure 3, the EJB component program-ming model aggregates multiple EJB objects to cre-ate functionality for applications requiring transac-tion-oriented characteristics. Written by enterprisebean providers, these components are aggregated byapplication assemblers who associate transactional,security, and other properties with the components.These aggregated components are stored in an EJBJava archive (JAR) file. Included in the EJB JAR fileis a deployment descriptor that describes the variousproperties of the EJB objects stored in the JAR file.

To execute an EJB object, an EJB JAR must be de-ployed. An EJB container provider is an organizationthat supplies an implementation of an EJB run-timeenvironment (e.g., middleware). The EJB container

provider is also responsible for providing tools thatallow the deployer to:

● Process an EJB JAR file● Configure an EJB server to install and execute an

EJB object● Configure the network environment to contain the

Remote Method Invocation (RMI) stubs neededby the client to communicate with the EJB objectvia the EJB container

● Provide directory services, such as Java Namingand Directory Interface (JNDI)8 to locate the de-ployed EJB bean

In addition, the EJB container provider supplies toolsfor security management at deployment time, as wellas for the system administrator for ongoing securityadministration of the EJB object and container run-time environment.

Another key element of the EJB programming andrun-time model is that it is a distributed program-ming model. In fact, the only architected means forcommunicating with an EJB object is through itsHomeInterface object via an RMI call. That is, the EJBprogramming model is a distributed programmingmodel where components and applications commu-nicate with each other via remote method calls. The

Figure 3 Relationship of EJB providers, application assembler, deployer, and system administrator

ENTERPRISE BEANPROVIDERS

APPLICATIONASSEMBLER

DEPLOYER/SYSTEMADMINISTRATOR


EJB container mediates all communication betweenan EJB client and the EJB instance (see Figure 4).

Authentication. The EJB specification does not di-rectly address the issue of authentication and the au-thentication process. Most of the specification dealswith authenticated principals and the actions theycan perform, such as invoking methods specified inan EJB HomeInterface or RemoteInterface object.In most respects, the execution model follows a sim-plified version of the Common Object Request Bro-ker Architecture** (CORBA**) security model.9,10

Authentication is the responsibility of the EJB con-tainer and could be implemented using JAAS.

In the Object Request Broker (ORB) authenticationmodel, an ORB, such as RMI over Internet Inter-OrbProtocol (RMI-IIOP),11,12 receives a method invoca-tion request and examines the security attributes ofthe request prior to method dispatch.13 If the prin-cipal(s) are authenticated, then the process moveson to the authorization phase.

Aside from the authentication process, the result ofauthentication appears in several places. In partic-ular, EJB includes a notion of a security role. The se-curity role is a grouping of principals to make it eas-ier for the deployer and system administrator toadminister authorization. When a principal is au-

thenticated, the principal is logically assigned to zeroor more security roles defined by the application (asconfigured by the deployer). Further details of se-curity roles are covered later, in the subsection onauthorization.

For the enterprise bean provider, authenticated userinformation is available in two methods in theEJBContext class. The first is the getCallerPrinci-pal¼ method, which returns a Principal object rep-resenting the authenticated principal on whose be-half the EJB object is executing. The result ofgetCallerPrincipal¼ is implementation-specific andwill be discussed later in the subsection on delega-tion. The second method containing user informa-tion is the method isCallerInRole¼, which acceptsa String object as an argument. After the requestingprincipal is authenticated and authorized, an EJBmethod is invoked. During the execution of the EJBmethod, the application code can determine if thecalling principal possesses a specific EJB security role.The role name passed in the isCallerInRole¼method call is compared to the security roles assignedto the authenticated user. If that name is one of theroles, the method returns true, otherwise, false.

From an authentication perspective, the EJB con-tainer provider is responsible for supplying tools andrun-time support for:

Figure 4 The EJB programming and run-time model as a distributed run-time environment

EJB SERVER

HOMEINTERFACE

CLIENT

HOMESTUB

REMOTEINTERFACE

EJB OBJECTSTUB

HOMEINTERFACE

EJBHOME

REMOTEINTERFACE

EJB OBJECT

BEANCLASS

EJB CONTAINER


● The javax.ejb.EJBContext methods getCallerPrin-cipal¼ and isCallerInRole¼

● Security role name mappings as defined in the EJBdeployment descriptor

● Tools for the deployer and system administratorto perform security administration, including se-curity role mapping and assignment of roles toprincipals or user groups

● Principal authentication and delegation support inthe ORB

Authorization. Much of EJB security is concernedwith authorization. As previously noted, EJB autho-rization is based on a simplified CORBA securitymodel, which asks whether an authenticated prin-cipal (or group of principals) is authorized to invokea method accessible via the ORB. Also, EJB securityis about the process of deploying an application sothat it can be secure. As such, EJB authorization willbe discussed from the perspective of each EJB secur-ity role.

Enterprise bean provider. An enterprise bean providerwrites business logic in Java code. The intent of theEJB architecture is to allow these providers to writeapplication code without having to understand or beinvolved in security. Aside from the javax.ejb.EJB-Context methods described above, there are no othermethods or operations that an EJB object can use toinfluence EJB security.

However, if the EJB uses the isCallerInRole¼method call, then the EJB deployment descriptor willneed to contain entries that enumerate the securityrole names used in these method calls.

Application assembler. An EJB JAR file delivered toa deployer may contain EJB objects from multipleenterprise bean providers. It is the responsibility ofthe application assembler to aggregate objects andcreate the deployment descriptor that goes into thisEJB JAR file. A deployment descriptor is written inXML and provides the road map for deploying theobjects in an EJB JAR file. In particular, the appli-cation assembler defines security role names that ap-ply to all EJB objects in the EJB JAR. Since the se-curity role names used in each of the EJB objects maynot be the same as those defined for the EJB JAR file,the application assembler must provide a mappingof the EJB object-specific security role names to thesecurity role names used for the entire EJB JAR. Thesecurity role names defined by the application as-sembler will be the security role names that will bevisible to the deployer.

The application assembler is also responsible for as-sociating the EJB JAR security role names with eachEJB method that is to be made accessible via the ORB.Each method can be assigned individually to a se-curity role, or all methods in a class can be assignedto a security role. Also, methods can be associatedwith multiple security roles. This allows an authen-ticated principal associated with any of the assignedsecurity roles to invoke the method. The method se-curity role assignments are intended to be a hint tothe deployer. It is the responsibility of the deployerto either accept the security role mappings or mod-ify them as appropriate for the deployment environ-ment.

Deployer and EJB container provider tools. A deployerreceives an EJB JAR file from an application assem-bler and uses tools provided by the EJB container pro-vider to process the deployment descriptor, includ-ing the security attributes (e.g., role names andmappings). Also, the deployment tools allow the de-ployer to modify any of the default method or se-curity role mappings found in the EJB JAR file, andto assign enterprise-specific principals the EJBsecurity roles. In addition, the deployer may adjustany method and security role mappings to suit thetarget environment.

The ability to modify mappings of roles to methodsis required to adhere to the organization structureand security policies of the environment into whichthe beans are deployed. For example, teller and cash-ier may be two declared roles in an EJB JAR file. Theorganizational structure of the financial organizationin which they are deployed may have one role, fi-nance assistant, responsible for performing both theteller and the cashier tasks. In this case, the deploy-ment tool should allow the deployer to modify boththe role names, teller and cashier, to become financeassistant. As a result of this modification, all themethods related to teller and cashier will be asso-ciated with finance assistant.

EJB container provider. A WAS is responsible for en-forcing the authorization constraints specified by thedeployer on an EJB container. This includes the se-curity role name mappings, method authorization,etc. Note that if any method in a deployed EJB JARfile is not associated with a security role, or if a se-curity role is not associated with any principals inthe deployed system, the WAS will prohibit access tothe method. The implementation of an authoriza-tion mechanism is outside the scope of the EJB spec-ification and will vary depending on the implemen-


tation of the WAS, EJB container, and RMI ORB.Implementations typically exploit existing infrastruc-ture, such as OS/390 RACF, SecureWay Directory, orthe Windows NT** Active Directory.

Delegation. Delegation is the process of forwardinga principal’s credentials along with associated tasksthat the principal originated or is having performedon its behalf.14 The EJB specification does not de-fine how delegation is to be handled since it is tiedto a specific container implementation. In fact, thereis nothing in the EJB JAR deployment descriptor tohelp a deployer manage delegation. Largely, dele-gation is an issue for the WAS environment and ad-ministration.

When a deployer configures an EJB object for a con-tainer, the container tools provide any necessary in-terfaces to configure delegation. One notable prob-lem with delegation is that the javax.ejb.EJBCon-text.getCallerPrincipal¼ method is ill-defined. Ingeneral, the enterprise bean provider cannot knowthe delegation configuration in the deployment envi-ronment. Also, the EJB specification does not indi-cate who the “caller principal” really is—it couldbe the client that initiated the original call to theWAS, or it could be the immediate caller to theEJB instance. If delegation is enabled, the result ofgetCallerPrincipal¼ may not be the principal thatthe enterprise bean provider expected.

If administrators enable delegation,15,16 they mustconfigure their delegation policies so that the WASenvironment conforms to security policies of the en-terprise. Therefore, the identity of the initiator ofthe call is often closer to the desired semantics of thegetCallerPrincipal¼ method than that of the imme-diate caller to the EJB instance.

Along with authentication, it is the responsibilityof the EJB container implementation in a WAS toenforce the policies defined and supported withinthe environment. The WAS environment can use theJAAS technology to implement delegation policies.As later described in the JAAS section, the Sub-ject.doAs¼ method can be used to execute a set ofactions under the identity of the specified principal.Because this is not a part of the EJB specification,one cannot expect the same behavior when the EJBobjects are deployed in different WAS environments,since they may have different authentication mech-anisms and delegation support.

Security considerations. While not specifically a se-curity consideration, the EJB programming modelconstrains an EJB object to a limited set of resources.Specifically, in a J2SE environment, an EJB object isprohibited from using many Java resources as a re-

sult of the EJB isolation architecture. This architec-ture scales well in a multiprocess and multithreadedWAS environment. Each EJB object is designed to runby itself and not interfere with other EJB objects. Forexample, EJB objects cannot include native methodcalls since the native code may not be portable andcould adversely affect other EJB objects. Note thatsince the EJB container is middleware and acts as abroker, it can make these native calls or use restrictedJava resources.

Given the isolation architecture of EJB components,each EJB object needs to interact with other EJB ob-jects using remote method calls. Because the inter-action will be location-independent and may crossmachine boundaries, it is important to define andenforce a secure association mechanism between EJBcomponents. The channel of communication shouldprovide data confidentiality and integrity. Using SSL(secure sockets layer) communication between theEJB containers may address these requirements. Itis also important that the security context associatedwith the invoking EJB object be passed on to the tar-get EJB object, so that the identity of invocation getspropagated. A mechanism that achieves secure as-sociation between the source and target EJB com-ponents needs to address the quality of the servicerequirements. Some of these issues are addressedin the Java 2 Platform, Enterprise Edition (J2EE**)specification.2

Java Authentication and AuthorizationService

The WAS environment authentication requirementscan be fairly complex. In a given deployment envi-ronment all applications or solutions may not orig-inate from the same vendor. In addition, these ap-

It is important to defineand enforce a secure

association mechanismbetween EJB components.


plications may run on different operating systems.Java is the language of choice for portability betweenplatforms, but it needs to marry its security featureswith those of the containing environment. This sec-tion describes how JAAS accomplishes this union, andhow it can be exploited in the WAS environment.

Authentication and authorization are key elementsin any secure information handling system. Since theinception of Java technology, much of the authen-tication and authorization issues have been with re-spect to downloadable code running in Web brows-ers. In many ways, this had been the correct set ofissues to address, since the client’s system needs tobe protected from mobile code obtained from ar-bitrary sites on the Internet. As Java technologymoved from a client-centric Web technology to aserver-side scripting and integration technology, itrequired additional authentication and authorizationtechnologies.

Traditional computing systems perform authentica-tion on a principal or accountable entity, typicallythrough some sort of challenge-response mechanism.The most salient of these is a user ID and passwordcombination that is often used for server or Web re-sources, such as HTTP basic authentication. However,the challenge may be more complex, including theencryption of information, the possession of a spe-cific physical token (e.g., a key for a physical lockingmechanism), or possession of specific information(e.g., mother’s maiden name or value from a one-time keypad). The response must be valid based onthe type of the challenge.

Similarly, most computing systems base authoriza-tion on an authenticated principal and a list of re-sources authorized for use by the principal. Most of-ten, the authenticated principal is associated with anoperating system process or thread of execution.When protected resources are accessed, the autho-rization mechanism verifies whether the currently ex-ecuting principal is authorized for the resource.

Before JAAS, existing Java mechanisms did not pro-vide the structure needed to support traditional au-thentication and authorization. Security in J2SE wasbased on the use of public key cryptography (digitalsignatures) on the code executing in the Java virtualmachine (Jvm), not the principal making a requestfor computing or data resources. Similarly, autho-rization was based on the code attempting to use thecomputing or data resources.17,18 JAAS was designed

to address these shortcomings in a manner consis-tent with the existing J2SE infrastructure.

JAAS is divided into two major components: authen-tication and authorization. The authentication partis based on Pluggable Authentication Modules(PAMs),19 with a framework designed to be used bothon clients and servers. The authorization aspectswere designed to be an extension of the authoriza-tion mechanisms already found in J2SE.

Authentication: LoginModule objects. The kind ofproof required for authentication may depend on thesecurity requirements of a particular resource andenterprise security policies. To provide such flexi-bility, the JAAS authentication framework is basedon the concept of configurable authenticators. Thisarchitecture allows system administrators to config-ure, or plug in, the appropriate authenticators to meetthe security requirements of the deployed applica-tion. The JAAS architecture also allows applicationsto remain independent from underlying authentica-tion mechanisms. So, as new authenticators becomeavailable or as current authentication services areupdated, system administrators can easily replace au-thenticators without having to modify or recompileexisting applications.

The JAAS LoginContext class represents a Java im-plementation of an enhanced PAM framework. ALoginContext object consults a configuration tableto determine the authenticators, or LoginModule ob-jects, that are to be employed by an application.

JAAS, like the PAM framework, supports the notionof stacked authenticators. The JAAS authenticationframework ensures that either all log-in modules suc-ceed or none succeed. It is the responsibility of theLoginContext object performing the authenticationto ensure this “all or nothing” behavior. This isachieved in two phases:

1. In the first phase of authentication, or the log-inphase, the LoginContext object invokes the spec-ified log-in modules and instructs each to attempt,but not commit, the authentication. If all the re-quired log-in modules successfully pass the firstphase, the LoginContext object then can proceedto the second phase.

2. In the second phase, each configured LoginMod-ule object is instructed to formally commit to theauthentication process. During this phase, eachLoginModule object associates the appropriate


authenticated Principal and Credential objectswith the Subject object.

If either phase fails, the LoginContext object instructsthe configured LoginModule object to abort the en-tire authentication process. Each LoginModule ob-ject is then required to clean up (e.g., discard) anystate that had been associated with the attemptedauthentication.

An important feature in JAAS is the mechanism bywhich an authenticated context is established. Or-dinarily, authentication is not part of the normal Javamethod dispatch path. Thus, if a Java program wishesto request authentication, it should construct a Log-inContext object and call its login¼ method. Thelogin¼ method will construct and annotate a Sub-ject object with appropriate authenticated Principaland Credential objects. Subsequently, to assume theidentity of that Subject object, the program calls theSubject.doAs(Subject, PrivilegedAction) method.This method call runs the specified PrivilegedActionobject’s run¼ method with the security attributes ofthe specified Subject object. After the PrivilegedAction.run¼ method terminates, the program returns to thesecurity state in effect prior to the Subject.doAs¼call. When the program no longer needs the authen-ticated identities, it can simply call the LoginCon-text object’s logout¼ method.

To allow selection of an appropriate set of Login-Context objects, a java.lang.String object is passedto the LoginContext constructor. This string is usedas an index into the configuration file, which selectsthe appropriate log-in module(s) to be used for au-thentication. Naming conventions for this index areentirely up to the Java program.

An important feature of JAAS is that it can be con-figured to support a wide variety of authenticationmechanisms and the arguments that they might take.For example, authentication could require:

● An account name (or user name) and a password● A distinguished name (DN) and the ability to prove

identity through a digital signature● A fingerprint or a retinal scan

Since one of the goals of JAAS is to have a pluggableauthentication mechanism, the framework methodsare generic enough to allow all authentication mech-anisms to work, and simple enough to avoid com-plexity for authentication mechanism providers. Thisis handled by having the four authentication meth-

ods visible at the LoginModule application program-ming interface (API). The login¼, commit¼, abort¼,and logout¼ methods have no parameters, and aJava return type of boolean (true if the methodsucceeded, false if the log-in module should be ig-nored). This approach does not require authentica-tion providers to add constraints to their current in-terfaces, but still leaves unresolved the issue of howto provide the additional configuration informationwhen needed.

The mechanism for providing additional informa-tion is to have an initialize¼ method in each Log-inModule object, where an optional CallbackHan-dler object can be specified. When employed, theseobjects can provide implementation- and environ-ment-specific information needed to satisfy a par-ticular LoginModule object. So, if a LoginModuleobject needs environment information to authenti-cate the user, it can examine the array of instanti-ated Callback objects to extract the necessary infor-mation. For example, if a user ID and password areneeded, the LoginModule object can examine thecallback array to see if it contains a NameCallbackobject and a PasswordCallback object. If so, it willuse them to obtain the necessary information.

In addition to JAAS, the Generic Security ServicesApplication Programmer’s Interface (GSS-API)20 andSimple Authentication and Security Layer (SASL)Application Programmer’s Interface21 define frame-works that provide additional support for pluggableauthentication. Specifically, the GSS and SASL authen-tication frameworks were designed for network com-munication protocols.22 As such, they provideadditional support for securing network communi-cations after authentication has completed. WhileJAAS accommodates general network-based authen-tication protocols, it also addresses the need to sup-port pluggable authentication in stand-alone andnonconnection-oriented environments.

Authorization. J2SE authorization17,18 is based on thenotion of classes being members of protection do-mains, threads of execution each having an Access-ControlContext object, and an authorization policythat is enforced by an AccessController object.

The Jvm loads classes and associates each class witha CodeSource object, which contains the base URLfrom which the code was loaded and the array of cer-tificates associated with the entities that signed thecode. Each class is loaded into the Jvm via an in-stance of the SecureClassLoader class, or one of its


subclasses, and is assigned to a ProtectionDomainobject based on its CodeSource object. The Protec-tionDomain object contains a set of Permission ob-jects, and these objects indicate which resources theclass is authorized to use. These resources includefile and network access and the ability to print andexecute code outside of the Jvm.16,17

The AccessControlContext object is a snapshot ofall of the ProtectionDomain objects currently asso-ciated with a thread of execution (see Figure 5). Thatis, when a method is called, a new activation recordis placed on the Java run-time stack. Each newmethod call results in a new activation record beingplaced on the stack, and when the method returns,the activation record is removed. When AccessCon-troller.getContext¼ is called, a search is made of therun-time stack to locate the Java class for each ofthe activation records. Since each Java class is as-sociated with a ProtectionDomain object, a set is con-structed that contains all of the unique Protection-Domain objects associated with the classes in thecurrent thread of execution. The AccessControlCon-text object is this set of ProtectionDomain objects.

To determine whether a thread of execution is al-lowed to access a protected resource, a call is madeto AccessController.checkPermission¼, which

creates an instance of an AccessControlContext ob-ject based on the activation records in the currentthread. The AccessControlContext object is thengiven the Permission object passed to the Access-Controller.checkPermission¼ call and asked whetherall of the ProtectionDomain objects that it containsare authorized for the specified Permission object.If any ProtectionDomain in the AccessControlCon-text object fails to contain the specified Permissionobject, the authorization test fails. A successful testof the Permission object indicates that all of theclasses currently executing in the thread are autho-rized to use the resource.6,17

JAAS authorization. The challenge for JAAS design-ers was to add principal-based authorization to J2SEin a way that would not disturb the existing autho-rization mechanisms. They met the challenge by ex-tending the J2SE authorization mechanism, associ-ating a Subject object and its set of Principal objectswith a thread of execution and logically extendingthe ProtectionDomain objects of executing code toinclude associated Permission objects.

To associate a Subject object with a thread of ex-ecution, the Subject.doAs¼ method is called witha Subject object containing authenticated Principalobjects and a PrivilegedAction object containing the

Figure 5 Graphical representation of a ProtectionDomain object

Certificate 1

CodeBaseURL

Certificate 2

Certificate n

• • •

Permission 1

Permission 2

Permission m

PermissionCollectionCodeSource

Protection Domain

• • •


code to be executed with the Subject object’s Per-mission object(s). The PrivilegedAction interface isthe same as that used for passing privileged code toan AccessController.doPrivileged¼ call. 17,18

In J2SE version 1.3, the AccessControlContext ob-ject accepts a java.security.DomainCombiner object,which is called during the authorization process. Thepurpose of the DomainCombiner object is to mod-ify, in some suitable fashion, the ProtectionDomainobjects associated with the classes on the thread’sactivation stack. In the case of JAAS, a SubjectDo-mainCombiner object is used, which logically extendseach ProtectionDomain object found on the stackso that it includes the ProtectionDomain objects ofall of the Principal objects in the currently active Sub-ject object in the thread.23

Security considerations. Developers have exploitedJAAS in WAS environments to bridge their applica-tions to a native authentication and authorizationplatform, such as an operating system or databaseapplication. By allowing a user to log in as a par-ticular identity, JAAS can call upon its log-in mod-ules to ensure that the authentication informationis valid and thus use the Java security policy to de-termine for which resources the user’s principal isauthorized.23

In the Subject.doAs¼ method and SubjectDomain-Combiner class, the J2SE authorization mechanismwas extended, rather than replaced. Code that hadpreviously been written to work with J2SE securitycontinues to work, and new code designed to useJAAS can use the new authentication and authori-zation frameworks.

An EJB container can use JAAS for both authenti-cation and method-level authorization. By using theJAAS subject and principal structures, it is possibleto accommodate the EJB role-based authorizationscheme in a straightforward manner.

For example, when a client requests an action on anEJB object, the WAS receives the request and the EJBcontainer extracts principal identity information. Af-ter the EJB container performs a JAAS log in with thePrincipal object, the EJB container receives one ormore authenticated Subject objects’ Principal objectsand credentials. The EJB container issues a Subject.doAs¼ call to establish the credentials before in-voking the EJB object. Through the EJB object’sinternal actions (e.g., through the ORB), AccessCon-

troller.checkPermission¼ is called to determinewhether the caller is authorized for the method.

The Subject.doAs¼ method can execute a privilegedaction under a desired identity. This method, thoughuseful for delegation, should be used with caution

by enforcing a principle of “least privilege.” The ac-tions associated with the method should be limitedto the ones requiring the privilege of the associatedsubject and should not be extended to perform more.If the subject represents a privileged user (e.g., theroot), the action associated should be limited to thatrequiring the privileged authority.

Servlet security

Servlets have come of age as Java-based alternativesto CGIs and have become essential objects in the WASenvironment. Servlets provide the same functional-ity as CGIs, such as creating HTML layouts or servic-ing queries, but do so by exploiting Java technolo-gies. As servlets become more general-purpose,administrators must consider their security aspects.

Servlets are platform-independent Java classesloaded dynamically into and run by a Web server.24

Thus servlets interact with Web clients to provideaccess to enterprise back-end services. To secureback-end applications and enterprise data, it is es-sential to protect the entry point from security at-tacks. As servlet invocations are based on the HTTPrequest/response protocol, any security policy forprotecting Web resources (servlets, JSP pages, andHTML files) should consider the HTTP security infra-structure as well.

The servlet container determines which server to in-voke based on its internal configuration, calling theservlet with objects representing the request and re-sponse.24 Security can be handled either by the serv-let container or by the servlet itself. Declarativesecurity policies are handled by the servlet containerbased on the WAS security configuration. Servlet writ-

Servlets have comeof age as Java-based

alternatives to CGIsand are essential objects

in the WAS environment.


ers can handle application-level security using secur-ity APIs provided by the servlet run-time environment.

In a typical scenario, a Web client (e.g., a Webbrowser) accesses a Web server and makes an HTTPrequest. If the request is for a servlet, the Web serverdelegates the request to the servlet container to han-dle and to send back a response. The container de-termines the level of protection required, and invokesa servlet if the requesting user has the required per-missions to invoke the requested method. If the serv-let is protected, the container will manage the au-thentication process based on the authenticationpolicies. Once the user is authenticated, authoriza-tion policies are checked to verify that the user hasthe necessary privilege to invoke the requestedmethod.

Authentication. A Web client can authenticate a userto a Web server using HTTP (basic or digest), HTTPS,or form-based authentication.

HTTP basic authentication. HTTP basic authentica-tion is a widely used authentication mechanism. Theservlet container issues an HTTP “401” authentica-tion challenge and the user is prompted for a userID and password by the Web browser. The WAS con-siders the authentication to be successful if the userregistry confirms that the password is associated withthe user ID provided. For example, if an LDAP di-rectory is the user registry, then authentication suc-ceeds if an LDAP bind request to the directory usingthe user’s DN is successful and the password matches.

HTTP digest authentication. HTTP digest authentica-tion ensures that a clear text password does not flowwith the request. In this mode, a digest version (one-way hash) of the password is provided to the Webserver. The WAS must be able to obtain the originalpassword so that it can compute the hash and com-pare it with the digest. This may not always be pos-sible, because the user registry dictates whether theclear text password can be accessed.

HTTPS client authentication. This mechanism makesuse of the public key infrastructure in authenticat-ing a user. A Web server can be configured to re-quire mutual authentication when a request is issuedover HTTPS (secure HTTP). Not only will the Webserver provide its server-site digital certificate, butit can also require the Web client to present its cli-ent digital certificate. When such a session is estab-lished, it proves that the Web server trusts the cer-

tificate authority (CA) that issued the certificate andthat the client digital certificate belongs to the user.

It is left to the WAS to perform any mapping fromthe digital certificate contents to a user in its userregistry. WAS could utilize LDAP, an operating sys-tem registry, or another representation (such as aSecureWay directory) for its user registry. There aresome basic ways in which this mapping can be ac-complished:

1. The certificate can be compared to the one storedfor the user in the registry.

2. The contents of the certificate can be matchedagainst the attributes of the user entry in the reg-istry.

Form-based authentication. In the case of basic au-thentication, a Web browser prompts the user forID and password using a dialog window. However,for usability it is often desirable to present the userwith an HTML form where the authentication valuescan be entered and the request submitted. When theform is submitted, the WAS will extract these valuesand perform appropriate authentication.

The Java Servlet API Specification version 2.2 stan-dardizes this approach by specifying the names ofthe form fields and the associated action. The log-inform must contain fields for the user to specify username and password. These fields must be namedj_username and j_password , respectively.24 For theauthentication to proceed appropriately, the valueof the action field on the log-in form must always bej_security_check .

At the end of a successful authentication, the requestis associated with a user in the WAS user registry. TheWAS associates the user with the security context ofthe servlet invocation.

Authorization. After a successful authentication, theWAS consults security policies to determine if the userhas the required permissions to complete the re-quested action on the servlet. This policy can be en-forced using the WAS configuration (declarativesecurity) or by the servlet itself (programmaticsecurity), or a combination of both.

In the case of declarative security, the WAS will per-form an authorization check to determine if the userhas the permission to perform the requested actionon the servlet. This process takes into account theuser’s privilege attribute information, such as user


ID or group memberships. It will also take into ac-count any security policies declared from the servletcontainer, such as the role relationships and the per-missions granted to these roles. The authorizationpolicy may be defined at the granularity of the Webapplication of which the servlet is a part.

The J2EE authorization model is based on securityroles.2 A user or a user group is associated with oneor more roles in the application domain. The WASdetermines the authorization policy for a user basedon the authorization associated with a security roleand the association between the user and the secur-ity role.

In the case of programmatic security, a servlet canobtain information about the authenticated user us-ing the servlet APIs. The servlet can then make bus-iness decisions based on the user’s name or the as-sociated role. Programmatic security consists of thefollowing methods of the HttpServletRequest inter-face:24

● getRemoteUser¼. This method returns the au-thenticated user name, if the user is authenticat-ed; otherwise it returns the keyword anonymous . 25

● isUserInRole¼. This method queries the under-lying security mechanism of the container to de-termine if a particular user is in a given securityrole.

● getUserPrincipal¼. This method returns a java.security.Principal object.

Delegation. All method invocations “downstream”from a servlet are performed on behalf of the userinvoking the servlet. The WAS may provide a set ofprogrammatic APIs where the servlet can set up anidentity on the security context programmatically, sothat the downstream method requests can be per-formed under that identity. JAAS may be used to han-dle such delegation requirements if the downstreamcalls can be made using the Subject.doAs¼ method.

Security considerations. HTTP basic authenticationis a popular way to authenticate servlets. However,the user ID and password flows “over the wire” in(near) clear text. Anyone who can obtain the dataflowing over the wire can also obtain the passwordwith minimal effort by decoding the base64-encodeduser ID and password pair.26 Also, the target Webserver is not authenticated. Therefore, if basic au-thentication is the desired mechanism, access to theprotected resource should occur over HTTPS to en-sure that the target server is authenticated and that

no “man-in-the-middle” attacks will be able to ob-tain the confidential data flowing between thebrowser and the Web server.

Java Cryptography Architecture and JavaCryptography Extension

The public key infrastructure has solved many vex-ing problems for today’s enterprise environments,from authentication to the publication of user infor-mation. Just as with other successful standards, Javatechnology needed to incorporate public key tech-nologies into its functionality in a standard and ex-tendable way.

From the Java 2 Platform, Standard Edition, version1.2 onward, Java technology has provided general-purpose APIs for cryptographic functions, collectivelyknown as the Java Cryptography Architecture (JCA)and Java Cryptography Extension (JCE). This sec-tion introduces the JCA and JCE and shows how theselayers can be exploited at a higher level by JSSE, PKCS,and S/MIME in the WAS environment.

Java Cryptography Architecture framework. JCA isa framework for accessing and developing core cryp-tographic functionality for the Java platform. It en-compasses the parts of the J2SE security API relatedto cryptography. JCA was designed around two prin-ciples. The first principle is implementation indepen-dence and interoperability. The second principle isalgorithm independence and extensibility.

Implementation independence is achieved using a pro-vider-based architecture. For each cryptographic ser-vice, such as message digest and digital signature,JCA supplies a service provider interface (SPI) ab-stract class as part of the API. Examples of SPI classesare MessageDigestSpi and SignatureSpi. The termcryptographic service provider (CSP) refers to a pack-age or a set of packages that supply a concrete im-plementation of a subset of the SPI classes that arepart of the Java security API. In other words, thesepackages must implement one or more cryptogra-phy services. This allows providers to be updated orreplaced in a manner that is transparent to appli-cations. This allows faster or more secure versionsto be installed when they become available.

Implementation interoperability means that variousimplementations can work with each other, use eachother’s keys, or verify each other’s signatures. Thismeans, for example, that for the same algorithms,


a key generated by one provider is usable by another,and a signature generated by one provider is veri-fiable by another.

Algorithm independence is achieved by defining typesof cryptographic services and classes that provide thefunctionality of these cryptographic services. Suchclasses are called engine classes. Examples includethe MessageDigest, Signature, and KeyFactoryclasses. For each engine class, there is a correspond-ing SPI class.

Algorithm extensibility means that new algorithms thatfit in one of the supported engine classes can easilybe added.

The security-related classes of JCA shipped with J2SEprovide for only message digest and digital signature.This allows developers to provide their own classesfor public key pairs, certificates, and other primarysecurity objects. Developers can also perform reli-able authentication, which, in turn, can be used asa basis for implementing access controls that relaxrestrictions. However, J2SE does not provide the gen-eral-purpose encryption needed to send confiden-tial data.

JCE extends the cryptography-related classes shippedwith J2SE. The JCE package uses the same structureas JCA, with engine classes that expose the algorithmsin a generic way and SPI abstract classes that are sub-classed to provide a concrete implementation of thecryptographic service they represent. JCE providesengine classes for symmetric key encryption and forgenerating and manipulating the secret keys that suchalgorithms require.

Java cryptography standard API. JCE extends theJCA API to include classes for encryption, key ex-change, and message authentication code (MAC). To-gether, JCE and the cryptography aspects of J2SE pro-vide a platform-independent cryptography API.

Fundamentals of JCA. The JCA framework is basedon the concepts of engine, algorithm, and provider.

Engine is the term used to depict an abstract rep-resentation of a cryptographic service that does nothave a concrete implementation. A cryptographicservice is always associated with a particular algo-rithm or type, and it can have one of the followingfunctions:

● To provide cryptographic operations (like thosefor digital signatures or message digests)

● To generate or supply the cryptographic material(keys or parameters) required for cryptographicoperations

● To generate data objects (key stores or certificates)that encapsulate cryptographic keys (that can beused in a cryptographic operation) in a secure fash-ion

Message digests and signatures are examples of en-gines. JCA encompasses the cryptography-relatedclasses of the J2SE security package, including the en-gine classes. Users of the JCA API request and utilizeinstances of the engine classes to carry out corre-sponding operations.

An algorithm can be looked upon as an implemen-tation of an engine. For instance, the Message Di-gest 5 (MD5) algorithm is one of the implementa-tions of the message digest engine. The internalimplementation of the MD5 algorithm can differ de-pending on the vendor that provides the MD5 algo-rithm class.

Each set of algorithm classes from a particular source(a provider) is managed by an instance of the java.se-curity.Provider class. Installed providers are listedin the java.security properties file, which containsJava security configuration entries.17 A provider doesnot know the actual implementation of the crypto-graphic algorithms. Rather, a provider knows whichalgorithm class can provide a particular algorithmicimplementation.

Java Cryptography Extension. JCE has been providedas an extension to the Java platform. It supplies aframework and implementations for encryption, keygeneration, key agreement, and MAC to supplementthe interfaces and implementations of message di-gests and digital signatures provided by J2SE.

The provider architecture of JCA aims to allow al-gorithm independence. The design principles behindJCE share this philosophy of implementation and al-gorithm independence. In addition to making it pos-sible to use newer algorithms for generating keys,JCE also introduces new interfaces and classes thatfacilitate the implementation of these concepts.

JCE provides for symmetric bulk key encryptionthrough the use of secret keys. With a secret key,the sender and receiver share the same key to en-crypt as well as to decrypt data. Associated conceptsof MAC and key agreements support symmetric bulkencryption and symmetric stream encryption.


Security considerations. Within the WAS environ-ment, the security server is the primary user of JCAto validate signatures on transactions and certificates.However, all primary and secondary objects withinthe WAS environment can exploit the capabilities ofJCA and JCE. For example, an EJB object could signdata using a JCA Signature instance or encrypt datausing a JCE Cipher instance. The JSSE and PKCS sec-tions demonstrate how JCA and JCE functionality canbe combined to create more complex technologies.JCA plays a fundamental role to any Java applica-tion that implements public key security.

Export control restrictions by the United States Com-merce Department currently prohibit such a cryp-tography framework from being exported outside theUnited States or Canada, unless appropriate mech-anisms have been implemented in the frameworkthat allow the framework to control the type of en-cryption algorithms and their cryptographic strengthavailable to applications. The lack of exportabilityhas significantly affected the usability and deploy-ment of JCE.

Exportability has been accorded to the new version,JCE version 1.2.1, in which JCE, not its CSPs, enforcesexport restrictions. IBM’s distribution of J2SE containsan implementation of JCE with a suite of commonlyused cryptographic functions.27

Java Secure Socket Extension

Through the cryptographic APIs provided in J2SE andin the standard JCE package, developers can invokecryptographic functions from within Java code. How-ever, most developers and application designerswould prefer to use ready-built cryptographic pro-tocols, rather than having to create them from thebasic elements of encryption and digital signatures.Secure sockets layer (SSL) is the most widely used pro-tocol for implementing encrypted channels over theWeb.28 Almost all e-business Web sites use SSL toensure that their own or their clients’ personal in-formation, such as a credit card number, can flowsecurely over the unsecured Internet. This sectiondescribes SSL, its implementation in Java codethrough JSSE, and its use among objects and entitiesin the WAS environment.

What is SSL? SSL is a standard protocol proposedby Netscape Communications Corporation for en-abling secure transmission on the Web.29 The pri-mary goal of the SSL protocol is to provide privacyand integrity between two communicating parties.

As the name suggests, SSL provides a secure formof the standard TCP/IP (Transmission ControlProtocol/Internet Protocol) sockets protocol. In fact,SSL is not a drop-in replacement because the appli-cation has to specify additional cryptographic infor-mation. Nonetheless, it is not a large step for an ap-plication that uses regular sockets to convert to SSL.Although the most common implementation of SSLis for HTTP, several other application protocols havealso been adapted.

SSL has two security aims:

1. To authenticate the server and the client usingpublic key signatures and digital certificates as re-quired

2. To provide an encrypted connection for the cli-ent and server to exchange messages securely

The SSL connection is private and reliable, using en-cryption after an initial handshake to define a secretkey. The SSL connection also maintains message in-tegrity checks. Note that in SSL, symmetric cryptog-raphy is used for data encryption, while asymmetricor public key cryptography is used to authenticatethe identities of the communicating parties and en-crypt the shared encryption key when an SSL sessionis established. This way, the shared encryption keycan be exchanged in a secure manner, and client andserver can be sure that only they know the sharedsecret key. In addition, the client and server havethe advantage of encrypting and decrypting the com-munication flow with a single encryption key, whichis much faster than using asymmetric encryption.

In this way, SSL is able to provide:

● Privacy. The connection is made private by encrypt-ing the data to be exchanged between the clientand the server. In other words, only they can de-crypt and make sense of the data. This allows forsecure transfer of private information such as creditcard numbers, passwords, secret contracts, and thelike.

● Data integrity. The SSL connection is reliable. Themessage transport includes a message integritycheck based on a secure hash function. There ispractically no possibility of data corruption with-out detection.

● Authentication. Optionally, the client can authen-ticate the server and an authenticated server canauthenticate the client. This means that, whenauthentication is required, the information is guar-anteed to be exchanged only between the intended


parties. The authentication mechanism is based onthe exchange of digital certificates.

● Nonrepudiation. Digital signatures and certificatestogether imply nonrepudiation. This establishes ac-countability of information about a particular eventor action to its originating entity, and the commu-nications between the parties can be proved later.

The SSL protocol can use different digital signaturealgorithms for authenticating the communicatingparties. SSL provides various key exchange mecha-nisms that allow the sharing of secret keys used toencrypt the communicated data. Furthermore, SSLcan make use of a variety of algorithms for encryp-tion and hashing. SSL cipher suites describe the cryp-tographic options defined by SSL and whether or notthe cipher strength can be exported outside theUnited States or imported to other countries.

JSSE package. Fetching data using the URL tech-nique is a very simple approach, but it limits the Javaprogram capabilities, because client/server commu-nications can exploit only the capabilities offered byCGI (or another, similar, server interface). Even ifthis is adequate for the function, it imposes someperformance overhead. A direct SSL socket connec-tion between client and server allows more sophis-ticated and responsive applets to be created. Thiscan be done by using a package that provides SSLfunction.

Java Secure Socket Extension (JSSE) is a standardextension to the Java platform. It consists of a setof packages that enable secure Internet communi-cations. JSSE implements a Java version of SSL andTransport Layer Security (TLS) protocols and in-cludes functionality for data encryption, server au-thentication, message integrity, and optional clientauthentication. Using JSSE, developers can providefor the secure passage of data between a client anda server running any application protocol (such asHTTP, Telnet, NNTP [Network News Transfer Pro-tocol] and FTP [File Transfer Protocol]) over TCP/IP.

Once an extension providing SSL support, such asJSSE, has been installed on a Java system, anSSL-protected client/server communication can beimplemented in Java code using the SSL protocol withthe SSL Java APIs.17

JSSE in a WAS environment. In the WAS environ-ment, JSSE has an immediate application—to pro-vide enhanced authentication. For example, if a dig-ital certificate is the authentication data and if the

user can establish an SSL connection between theWeb client and Web server, the WAS trusts that thecertificate belongs to the user. The user informationpresent in the certificate (for example, the distin-guished name) is then mapped onto the user reg-istry to find a matching user entry. The certificatechallenge implies that the Web server is configuredto perform mutual authentication over SSL.30,31 Inother words, both the client and the server mustpresent a certificate to establish the connection. Inother circumstances, the authentication policy caninclude a secure channel constraint. In other words,an SSL session may be required along with a chal-lenge mechanism to provide data confidentiality andintegrity for the information flowing between theserver and a client.32

SSL may also be used when single sign-on is required.A way to implement single sign-on in a WAS envi-ronment is by setting a “cookie” on the client sys-tem.33 The safest approach in this case is to ensurethat an SSL connection is established every time thecookie is created and stored in the browser. An SSLconnection prevents anyone from acquiring thecookie from the network flow.

The SSL API provided by the JSSE standard extensionallows the creation of a direct SSL socket connectionbetween a Java client and a Java server.17 This way,client and server applications do not need to rely onthe support of a Web browser and a Web server toexploit the advantages offered by SSL in terms of se-curity. In particular, SSL support is useful when theclient application is the WAS itself. Many times, twoapplication servers need to exchange confidential in-formation. For example, there may be clustered WASssharing the same Web contents and “load balanced”by a dispatcher machine, as shown in Figure 6.34–36

In this case, client session information needs to beshared across the nodes or authentication informa-tion will be lost. To obtain data confidentiality andintegrity on untrusted networks, SSL can be turnedon.30,31

Security considerations. The history of the WorldWide Web is based on pragmatism. For example, noone would argue that sending uncompressed ASCII(American National Standard Code for InformationInterchange) text data on sessions that are set upand torn down for every single transaction is effi-cient in any way. However, this is what HTTP does,and it is very successful. The reason for its successis that it is simple enough to allow many differentsystems to interoperate without problems of differ-


ing syntax. The cost of simplicity is in network over-head and a limited transaction model.

Using cryptography in Java code offers a similar di-lemma. It is possible to write secure applications us-ing a toolkit of basic functions. Such an applicationcan be very sophisticated, but it will also be com-plex. Alternatively, SSL URL connections offer a wayto simplify the application, but at the cost of appli-cation function. SSL Java packages, such as JSSE, pro-vide a middle way, retaining simplicity but allowingmore flexible application design for applications inthe WAS environment.

When using JSSE and cookies to implement a singlesign-on solution, the WAS administrator should spec-ify a time period after which the user should be re-quired to reauthenticate. This restricted time periodprevents replay attacks using the cookie. To ensurethat cookies are not persistent, so that off-line at-tacks can be prevented, the cookie should be set toexpire at the end of the browser’s session. A WASshould also provide a mechanism by which the sin-gle sign-on cookie can expire programmatically sothat in a kiosk scenario a user leaving a terminal canexplicitly log out and not worry about the session be-

ing used by subsequent users. Indicating that a cookieshould be stored only for the session also eliminatesthe security risk of having the cookie values storedon a hard drive, for example.

To prevent replay attacks that retrieve the cookiefrom the network flow, developers should restrict thecookie to flow only over HTTPS protocol. Setting the“secure” field of the cookie ensures that the cookiewill flow only over SSL connections, which are usedby HTTPS.

PKCS and S/MIME

Just as JSSE leveraged JCA and JCE to create andmaintain secure connections between entities, theremust also be a way for developers to represent ob-jects that use public key technologies in a standardfashion. The industry has adopted PKCS and S/MIMEas the standard techniques through which these typesof security objects can be created, packaged, and de-livered.37 Many Java implementations of these stan-dards have emerged, but what are they, and how canthey address the security needs of the WAS environ-ment? This section introduces those elements of the

Figure 6 Using SSL to exchange private information in a load-balancing scenario

CLIENT NETWORKDISPATCHER

ENTERPRISEFILE SYSTEMSERVER(S)

WEB SERVERS

APPLICATION SERVERS

ENTERPRISE FILE SYSTEM CLIENTS

INTERNET


standards that can be exploited by objects in the WASenvironment.

First developed by RSA Data Security, Inc. and a con-sortium of companies in 1991, PKCS has evolved toencompass a wide set of functionality from encryp-tion to the use of smart cards and object packaging.At the core of the standards is the use of public keytechnologies, whether these technologies are explic-itly used in signing data or implicitly used in the bun-dling of certificate information within a token, forexample.

By overlaying PKCS over the WAS environment, theCryptographic Message Syntax Standard (PKCS #7)consolidates the transactions and objects used byWAS and its associated servers. RFC 2315 containsinformation about PKCS #7 version 1.538 with en-hancements to the standard detailed in RFC 2630.39

Earlier sections of this paper have identified the im-portance of signing and encryption for transactionsfrom objects, such as EJB objects within the WAS, andbetween client and server entities in a WAS environ-ment, such as a Java client and a Java server usingJSSE. Recipients of a signed message or transactioncan verify the contents and gain assurance that themessage was not changed in transit and that it ac-tually originated from the sender. Encryption helpsprotect the message from prying eyes and ensuresthat only the intended recipient can unlock its con-tents. Signing and encrypting can be used alone orin combination to provide a transaction hardenedagainst security threats.

When using JCA and JCE objects, developers are com-pelled to maintain different initialization attributesand objects to accomplish their tasks, such as the sig-nature algorithm, the contents to be signed, and sig-nature bytes. These objects can become scattered anddo not lend themselves to a free and standard ex-change across a heterogeneous environment. PKCS#7 defines how objects, such as SignedData objects,should be packaged so that the creator of the objectincludes all of the subobjects and attributes that areneeded for the recipient to verify, decrypt, or per-form some other action upon the aggregate object.

The PKCS standards use the Abstract Syntax Nota-tion (ASN.1)40 to formally describe the objects, forexample, whether or not an attribute is optional orif it should consist of a set of other objects. ASN.1 isan international standard for specifying data usedin communication protocols. It is a powerful and

complex language—its features are designed to de-scribe accurately and efficiently communications be-tween homogeneous or heterogeneous systems.Since Java PKCS implementations model objects thatrepresent the ASN.1 notation, these objects need to

be encoded in a standard form that senders and re-cipients agree upon. For PKCS, encoding is performedusing the Distinguished Encoding Rules (DER), asubset of the Basic Encoding Rules (BER) describedin ASN.1.

Two classes of objects in PKCS #7 play an active rolein WAS environments, SignedData and Envel-opedData. As the name suggests, SignedData ob-jects represent a signed message and consist of anumber of essential objects, including the signaturealgorithm, signer’s certificate, encapsulated contents,and signer information, such as the signature bytesand the time the signer generated the signature. Sig-nature algorithms include MD5withRSA andSHA1withDSA.41 PKCS cleverly represents Signed-Data objects; the object definition allows only a sin-gle instance of the encapsulated contents to be in-cluded, whereas the contents can have many signerswith information for each signer stored as a sepa-rate subobject.

The EnvelopedData object hides the specified con-tents by introducing encryption into the mix. JavaPKCS implementations first generate a secret key forthe designated cipher algorithm as part of construct-ing an EnvelopedData object. Cipher algorithms in-clude RC2, DES, and TripleDES.41 Both the contentsto be encrypted and the secret key are passed intothe cipher object, which calculates and returns theencrypted bytes. Since the secret key cannot be sent“in the clear” with the encrypted contents, the En-velopedData object goes one step further, encrypt-ing the secret key with the public key of each recip-ient. It uniquely encrypts the secret key for eachrecipient, since each recipient’s public key is dif-ferent. When each recipient receives the Envel-

Signing and encryptingcan be used, alone or

in combination, toharden a transaction

against security threats.


opedData object, the private key is used to decryptthe secret key and the decrypted secret key is usedto decipher the encrypted message.

The introduction and progression of the S/MIME42

standards helps marry the benefits of encapsulatedPKCS objects with a popular mechanism for repre-senting different content types across the Internet.For example, MIME messages with a content type oftext/plain are a popular way for users to send generalmessages to each other. Since these messages travelacross an unsecured network—the Internet—MIMEmessages lacked uniform security until the incorpo-ration of S/MIME. The S/MIME standards bring toMIME the security benefits of PKCS—protecting mes-sage integrity, authenticating the originator of mes-sages, and enciphering the content of messages. Allof the popular e-mail applications support S/MIME,ensuring that users can send messages securely withall the benefits of authentication, integrity, and en-cryption.

S/MIME allows senders to encode PKCS #7 Signed-Data and EnvelopedData objects within the mes-sage.43 Since DER-encoded binary data cannot besent in their raw form, the binary data are base64encoded, which results in 7-bit US-ASCII text44 thatcan be sent in an Internet message. S/MIME recip-ients take the message and work backward, decod-ing the base64 message, decoding the DER-encodedmessage, and instantiating the encoded object. Inaddition to the PKCS #7 SignedData and Envel-opedData objects, S/MIME also supports PKCS #10CertificationRequest objects, which allow entities torequest a certificate from a CA. The SignedData ob-ject is versatile enough that CAs can respond to a PKCS#10 request by sending back the issued certificatein a SignedData object contained within a S/MIMEmessage.

PKCS and S/MIME in the WAS environment. PKCSand S/MIME play a key role in guaranteeing the au-thenticity of a message and hiding sensitive contentsbetween client and server and between server andserver entities within the WAS environment. As partof the authentication architecture, every entity hasa certificate associated with it, whether a client whosecertificate was retrieved by the security server fromthe LDAP database or a Web server with an embed-ded certificate. This certificate forms the foundationfor sending and receiving secure messages or trans-actions.

Transactions within the WAS environment can be di-vided into two levels, primary and secondary. Primary-level transactions occur between the major entities,such as between client and server or server andserver. Security between the major entities can in-volve the security server and could be initiated bya security plug-in in a Web browser or security col-laborator in a WAS. JSSE is a major component ofsecurity at the primary level. Transactions at the sec-ondary level occur within a major entity, such aswithin an EJB object that is invoked by a WAS. Thesecondary objects still interact with the security serverfor authentication and authorization, but they areable to invoke the security requests at their level.PKCS can play roles at either level, but it is especiallyimportant within the secondary level.

Consider a secondary security example. A WAS Javaapplication client sends a request to the WAS to in-voke an EJB object. The security collaborator withinthe WAS ensures that the client has the authoriza-tion to utilize the EJB object. In this example, theEJB object requires secondary security to add to theuser registry the set of certificates that were passedby the client to the EJB object.

Signing transactions with PKCS. The EJB object en-capsulates the request as part of a PKCS #7 Signed-Data object. To create the object, the EJB object con-structs a SignedData object with the EJB object’scertificate, private key, signature algorithm, and theattributes of the request as input. The resultingSignedData object contains the contents, the EJB ob-ject’s certificate, and signer information containingthe signature. (The signature algorithm requires theprivate key to compute the signature bytes, but theSignedData object never bundles the private key aspart of its attributes.) With a socket to the securityserver, the EJB object can DER-encode the Signed-Data object and send it to the security server as partof the request.

Upon receipt, the security server decodes theDER-encoded SignedData object to prepare for ver-ification. Before the verification method can becalled, however, the security server must first ensurethat the signing certificate can be trusted. The se-curity server performs this check by tracing the EJBobject’s certificate to a trusted root CA, stored withinthe user registry. Assuming the certificate path holdstrue and the signing certificate is still valid, the se-curity server provides the signing certificate as an in-put to the verification method. The original con-tents—the set of certificates to add—need not be


passed to the method since they are already part ofthe SignedData object.

In reply, the verification method returns a Booleanresponse. A positive response gives the securityserver the confidence that the message was notchanged in transit from the EJB object and that ittruly originated from that object. The security servercan now add each of the content certificates withinthe SignedData object to the user registry.

Encrypting transactions with PKCS. In the scenariojust described, it would have been just as easy forthe EJB object to encrypt the message. In this case,the EJB object would require access to the securityserver’s certificate. To construct an EnvelopedDataobject, the EJB object would use the message aloneor the SignedData object along with the security serv-er’s certificate and the encryption parameters. Theencryption parameters would include the algorithmand the key size so that construction of the Envel-opedData object would automatically generate thesecret key “under the covers.” As described earlier,the secret key is encrypted with the public key fromthe security server’s certificate. The EJB object wouldsend the created EnvelopedData object through thesame routes that were described earlier for theSignedData object.

The security server receives the EnvelopedData ob-ject and decodes it. The security server passes its cer-tificate and private key to the decrypt method of theEnvelopedData object. The decrypt method uses thesecurity server certificate to determine which en-crypted secret key should be decrypted, since the En-velopedData object may contain many uniquely en-crypted secret keys, one for each recipient. Thedecrypt method uses the private key associated withthe security server certificate to unlock the encryptedsecret key associated with the certificate. Next, themethod uses the secret key to decrypt the cipher textof the message.

Note that inclusion of the SignedData object withinthe EnvelopedData object provides the additionalbenefit of signing the primary contents, which areencapsulated within the SignedData object. After de-crypting the message, the security server could ver-ify the contents of the message using this compoundobject. Thus with an EnvelopedData object wrappedaround a SignedData object, the sender and receivergain the benefits of three main security facets—in-tegrity, authentication, and encryption.

Asynchronous transactions with S/MIME. Instead ofsending the request and the DER-encoded PKCS #7object as binary data across a socket, S/MIME pro-vides a standard way for these objects to be sent us-ing a universal format. As a standard extension tothe Java run-time environment (JRE), the JavaMail45

package could be extended to provide security toMIME messages. With S/MIME, clients and servers,as well as secondary objects (like EJB objects) withinthe WAS environment can readily send and queueup asynchronous requests.

Security considerations. As they have matured overthe years, the PKCS and S/MIME standards have beenexamined for completeness and security. Althoughpowerful, they do not address authorization, an im-portant part of security. Entities that hide privatekeys are the only ones with authorization to the key,and this controlled access provides an explicit au-thorization to decrypt an encrypted message. How-ever, PKCS does not address who can receive a signedmessage, for example, or who can act upon the con-tents of a signed message. A WAS or a secondary en-tity, using responses from the security server, mustdetermine whether or not the client has authoriza-tion to perform the signed action, and authorizationtypically stems from a policy established by a phys-ical entity, such as an administrator. Additionally,administrators and developers must determine theappropriate type of cryptography for their WAS envi-ronment.46

The blend of JCA and JCE technologies gives rise tokey agreement algorithms within the SSL protocol.Within the Java environment, the JSSE implementsSSL and allows two parties to authenticate and sendsecure transactions to each other. As discussed ear-lier, JSSE provides a sanctioned and secure commu-nication link between two entities, and this technol-ogy is the fundamental way in which signed andencrypted communication can occur synchronouslybetween primary entities in the WAS environment.However, if the overhead of SSL is not needed andif communication can occur asynchronously, PKCSand its companion S/MIME can readily fill the secu-rity needs of a WAS environment. The encapsulationof PKCS objects allows these objects to be easily storedand retrieved for later evaluation or processing.

Conclusion

The WAS environment pulls together many differ-ent technologies to service the enterprise. Becauseof the heterogeneous nature of the client and server


entities, Java technology is a natural choice for ad-ministrators and developers. However, to service thediverse security needs of these entities and theirtasks, many Java security technologies must be used,not only at a primary level between client and serverentities, but also at a secondary level, from servedobjects, such as EJB objects. By using a synergisticmix of the various Java security technologies, admin-istrators and developers can make not only their Webapplication servers, but their WAS environments se-cure as well.

*Trademark or registered trademark of International BusinessMachines Corporation.

**Trademark or registered trademark of Sun Microsystems, Inc.,Object Management Group, or Microsoft Corporation.

Cited references and notes

1. J. Hunter and W. Crawford, Java Servlet Programming,O’Reilly & Associates, Sebastapol, CA (1998).

2. B. Shannon, M. Hapner, V. Matena, J. Davidson, E. Pelegri-Llopart, and L. Cable, Java 2 Platform, Enterprise Edition: Plat-form and Component Specifications, Addison-Wesley Publish-ing Co., Reading, MA (2000).

3. A. Goldberg and D. Robson, Smalltalk-80: The Language andIts Implementation, Addison-Wesley Publishing Co., Read-ing, MA (1983).

4. G. Krasner, Smalltalk-80: Bits of History, Words of Advice, Ad-dison-Wesley Publishing Co., Reading, MA (1983).

5. Acronym definitions: LDAP is Lightweight Directory AccessProtocol; RACF is Resource Access Control Facility.

6. EJB 1.1 specification, http://java.sun.com/ejb.7. R. Monson-Haefel, Enterprise JavaBeans, O’Reilly & Asso-

ciates, Sebastapol, CA (1999).8. Java Naming and Directory Interface specifications, http://

java.sun.com/products/jndi/.9. CORBA security specification, http://www.omg.org.

10. B. Blakley, CORBA Security: An Introduction to Safe Com-puting with Objects, Addison-Wesley Publishing Co., Read-ing, MA (1999).

11. Java language mapping to Object Management Group’s In-terface Definition Language, http://www.omg.org/technology/documents/formal/java_language_mapping_to_omg_idl.htm.

12. RMI over IIOP, http://java.sun.com/products/rmi-iiop/.13. OMG Common Secure Interoperability, version 2 specifica-

tions, http://www.omg.org/.14. WebSpheresecurityoverview,http://www-4.ibm.com/software/

webservers/appserv/security.pdf.15. N. Nagaratnam and D. Lea, “Secure Delegation for Distrib-

uted Object Environments,” Proceedings, USENIX Confer-ence on Object-Oriented Technologies and Systems, Santa Fe,NM (April 27–30, 1998), pp. 101–116.

16. N. Nagaratnam, Practical Delegation for Secure Distributed Ob-ject Environments, Ph.D. dissertation, computer engineeringdegree program, Syracuse University (April 1998).

17. M. Pistoia, D. F. Reller, D. Gupta, M. Nagnur, and A. K.Ramani, Java 2 Network Security, Prentice Hall, EnglewoodCliffs, NJ (2000).

18. L. Gong, Inside Java 2 Platform Security: Architecture, API De-sign, and Implementation, Addison-Wesley Publishing Co.,Reading, MA (1999).

19. V. Samar and C. Lai, “Making Login Services Independentof Authentication Technologies,” http://java.sun.com/security/jaas/doc/pam.html/.

20. GSS-API Security Attribute and Delegation Extensions, TheOpen Group.

21. RFC 2222, Simple Authentication and Security Layer (SASL).22. N. Nagaratnam, B. Maso, and A. Srinivasan, Java Network-

ing and AWT API SuperBible: The Comprehensive Referencefor the Java Programming Language, Macmillan USA, Indi-anapolis, IN (1996).

23. B. Rich, A. Nadalin, and T. Shrader, “All that JAAS: An Over-view of the Java Authentication and Authorization Services,”IBM Developer Connection (March 2000); http://www.developer.ibm.com/devcon/mag.htm.

24. Java Servlet API Specification version 2.2, http://java.sun.com/products/servlet.

25. IBM WebSphere Standard/Advanced 3.02 Security Overview,http://www-4.ibm.com/software/webservers/appserv/security.pdf.

26. MIME (Multipurpose Internet Mail Extensions), http://www.ietf.org/rfc/rfc1521.txt?number51521.

27. IBM J2SE specifications, http://www.ibm.com/java/.28. A. O. Freier, P. Karlton, and P. C. Kocher, SSL 3.0 Spec-

ification, Technical Report, Netscape Communications Cor-poration (November 1996); available at http://home.netscape.com/eng/ssl3/index.html.

29. SSL 3.0 Specifications, http://home.netscape.com/eng/ssl3/.30. B. Nusbaum, M. Pistoia, G. Rochester, and T. Liu, Network

Computing Framework Component Guide, SG24-2119-00,IBM Corporation (1997).

31. B. Nusbaum, M. Pistoia, G. Rochester, and T. Liu, IBM Net-work Computing Framework for e-business Guide, SG24-5296-00, IBM Corporation (1998).

32. M. Pistoia, K. Kojima, and N. Raghu, Internet Security in theNetwork Computing Framework, SG24-5220-00, IBM Corpo-ration (1998).

33. RFC 2109, HTTP State Management Mechanism, http://www.ietf.org/rfc/rfc2109.txt?number52109.

34. M. Pistoia and C. Letilley, IBM WebSphere Performance Pack:Load Balancing with IBM SecureWay Network Dispatcher,SG24-5858-00, IBM Corporation (1999).

35. M. Pistoia, T. Menner, C. Milligan, and B. G. Pham, IBMWebSphere Performance Pack: Web Content Management withIBM AFS Enterprise File System, SG24-5857-00, IBM Corpo-ration (1999).

36. M. Pistoia, V. Iovine, and S. Pischedda, IBM WebSphere Per-formance Pack Usage and Administration, SG24-5233-00, IBMCorporation (1998).

37. T. Shrader, B. Rich, and A. Nadalin, Java and Internet Se-curity, iUniverse, http://www.iuniverse.com (2000).

38. RFC 2315, PKCS #7: Cryptographic Message Syntax Ver-sion 1.5, ftp://ftp.isi.edu/in-notes/rfc2315.txt.

39. RFC 2630, Cryptographic Message Syntax, ftp://ftp.isi.edu/in-notes/rfc2630.txt.

40. B. S. Kaliski, Jr., A Layman’s Guide to a Subset of ASN.1, BER,and DER, RSA Laboratories (November 1993).

41. B. Schneier, Applied Cryptography: Protocols, Algorithms, andSource Code in C, 2nd Edition, John Wiley & Sons, Inc., NewYork (1995).

42. RFC 2311, S/MIME Version 2 Message Specification, ftp://ftp.isi.edu/in-notes/rfc2311.txt.

43. T. Shrader, A. Nadalin, and B. Rich, “Understanding Cryp-tographic Messages in e-business,” IBM DeveloperToolboxTechnical Magazine (March 2000); http://www.developer.ibm.com/devcon/mag.htm.

44. ASCII was first defined by the American National Standards


Institute (ANSI) in ANSI Standard X3.4 in 1968. The ASCIIcode is also described in ISO 636 (1973) and CCITT V.2,which calls the standard IA5 (International Alphabet #5).ASCII is a 7-bit code, resulting in a maximum of 128 char-acters.

45. JavaMail version 1.1.3 specifications, http://www.javasoft.com/products/javamail/index.html.

46. T. Shrader, “Choosing the Right Cryptography for Your e-business Application,” IBM DeveloperToolbox Technical Mag-azine, on-line edition at http://www.developer.ibm.com/devcon/mag.htm.

General references

For information on the Pluggable Authentication Module, seehttp://java.sun.com/products/jaas/.RFC 1510, The Kerberos Authentication System, http://info.internet.isi.edu/in-notes/rfc/files/rfc1510.txt.C. Neuman and T. Ts’o, “Kerberos: An Authentication Servicefor Computer Networks,” IEEE Communications 32, Number 9,33–38 (September 1994).

Accepted for publication October 10, 2000.

Larry Koved IBM Research Division, Thomas J. Watson ResearchCenter, P.O. Box 218, Yorktown Heights, New York 10598 (elec-tronic mail: [email protected]). Mr. Koved is a research staffmember in the Network Security and Cryptography departmentand a Java security architect for IBM. His primary interests arethe security of mobile code, component software, and object-ori-ented languages. He is a member of ACM’s SIGSAC and SIG-CHI and of the IEEE Computer Society.

Anthony Nadalin Tivoli SecureWay Business Unit, 9442 Capitalof Texas Highway North, Arboretum Plaza One, Suite 500, Austin,Texas 78759 (electronic mail: [email protected]). Mr. Nada-lin is the lead architect for the IBM Java Security project. As sen-ior architect, he is responsible for infrastructure design and de-velopment across IBM. He serves as the primary security liaisonto Sun Microsystems’ JavaSoft Division for Java security designand development collaboration.

Nataraj Nagaratnam IBM Application & Integration MiddlewareDivision, P.O. Box 12195, 3039 Cornwallis Drive, Research TrianglePark, North Carolina 27709-2195 (electronic mail: [email protected]). Dr. Nagaratnam is the technical lead for the IBMWebSphereTM security team. He received his Ph.D. degree fromSyracuse University; his thesis addresses secure delegation in dis-tributed object environments. He has authored and edited bookson Java networking and JavaBeansTM and has published in nu-merous journals and conferences.

Marco Pistoia IBM Research Division, Thomas J. Watson Re-search Center, P.O. Box 218, Yorktown Heights, New York 10598(electronic mail: [email protected]). Mr. Pistoia is an advisoryJava security specialist in the Network Security and Cryptogra-phy department. He has written nine books and taught classesworldwide on all areas of Java, WebSphere, and e-business se-curity. His latest book, Java 2 Network Security, was published byPrentice-Hall. Mr. Pistoia’s interests are in mobile code securityand object-oriented technology.

Theodore Shrader IBM Software Group, 11400 Burnet Road,Austin, Texas 78758 (electronic mail: [email protected]). Mr.Shrader was a feature lead on the IBM Java Security project andcurrently is the Editor-in-Chief of the IBM DeveloperToolbox mag-azine. He has written numerous patents and technical articles deal-ing with Internet and Java development, distributed computing,object-oriented design, database architecture, and Web design.He also is a coauthor of an operating systems programming guidepublished by John Wiley & Sons and the lead author of the Javaand Internet Security book published by iUniverse and cited inthis paper.


Documents

Security challenges for Enterprise Java in an e-business … · 2019. 3. 22. · manage authentication and authorization with Java Authentication and Authorization Service (JAAS)