Wiley java security solutions sep 2002 ISBN 0764549286

Chapter 26: Java Enterprise Security and Web Services SecurityChapter 27: Securing Client-Side Components Chapter 28: Securing Server-Side Components Chapter 29: Application Security wit

Part IX: Enterprise Access

Chapter 26: Java Enterprise Security and Web Services SecurityChapter 27: Securing Client-Side Components

Chapter 28: Securing Server-Side Components

Chapter 29: Application Security with Java

To understand the PKI, only two things need to be studied in detail,the X.509 format and how digital certificates are managed in a

certificate chain From those two things you get a lot of informationabout other protocols such as X.500, LDAP, and asymmetric keying.The purpose of PKI is to transport a secure public key from a sender

of a secure message to the receiver of a secure message so that hemay decrypt the message PKI is a means to make the public keysecure

Java has a lot of packages for both formatting the X.509 digital

certificate and checking the certificate path The LDAP SDK also

offers a rich API for working with an LDAP server The LDAP server isimportant because the X.509 certificate format and certificate path aretightly coupled with the X.500 Directory Service schema for

manipulating certificates

The study of PKI is very extensive and a lot of work could go be

required from an organization to support PKI My suggestion is to takethe easiest route Use LDAP if you can, so that a lot of RDBMS work

is not required Know the services offered by your CA, Web services,and Application services so that you may take advantage of them Ihave worked with many companies and types of developers, andmany do think that it is cool to write their own LDAP server; however,there is a difference between having to write an LDAP server the nightbefore production and writing one on your own time Use as muchout-of-the-box functionality as possible Many organizations use PKI,

so there are very few things to be discovered in this area for mostorganizations unless you happen to be an RA or a CA

Chapter 26: Java Enterprise Security and Web Services Security

By now you should be familiar with the basic tools for security, such

as encryption, digital keys, and digital signatures, and you shouldknow about the different security technologies provided by J2EE andthe J2SDK v 1.4 This chapter helps you understand how those

technologies come together in the overall Java security architectureand their application in Web Services These technologies form asecurity framework that allows you to switch among services

You do not need to implement everything at once, and the frameworkprovides you with a roadmap for your security architecture The nextfew chapters explore in more detail how this architecture is used inthe client side (Chapter 27), the server side (Chapter 28), and howsome applications provide security using these technologies (Chapter29)

Chapter 27: Securing Client-Side Components

J2EE applications are deployed in servers, and each J2EE

component is installed in different containers A J2EE server is theruntime portion of a J2EE product and provides EJB and Web

containers The EJB container manages the life cycle of EnterpriseBeans, and the Web container manages the execution of JSP pagesand Servlets In addition, there are two more containers: the

application client container and the applet container The applicationclient container runs on the client and manages the execution of

application client components Finally, the applet container managesthe execution of applets and consists of the Web browser and a Javaplug-in running on the client Figure 27-1 illustrates these

relationships

Figure 27-1: The J2EE

containers

This chapter covers security from application, applet, and JSP andServlets perspectives (EJBs are covered in Chapter 28) In addition, itbriefly covers JNDI and presents an example to illustrate these

concepts.

Chapter 28: Securing Server-Side Components

When the term security is used, confidentiality, integrity, and

accountability come to mind This chapter explores these

characteristics from the server-side development and explores youroptions for distributed development from the server-side security withemphasis on the J2EE platform It starts with a brief overview of

Common Object Request Broker Architecture (CORBA) and CORBA

security and then explores RMI, including the RMISecurityManagerand RMIClassLoader Next, the chapter takes a look at RMI overIIOP and presents how the EJB container can be configured and how

it provides security

Chapter 29: Application Security with Java

As discussed throughout this book, security is more than networksecurity - it affects the entire enterprise solution I have discussed thesecurity requirements needed for a secure solution Namely, the

http://wwws.sun.com/software/

One of the greatest advantages of using digital certificates is non-repudiation Non-repudiation is like receiving a sales receipt when

placing an order Non-repudiation guarantees that when a message issent to a third-party application, a receipt is returned saying that themessage was received

When working with Business-to-Business (B2B), sometimes it is

necessary to get a receipt to ensure that the message was delivered

An example is placing an order through xyzFlowers.com The

company xyzFlowers.com could be a company that doesn't actuallydeliver flowers, but just handles the ordering process The companycould have a contract with a small flower shop in ABC City, Colorado,

a couple of miles from the customer who actually placed an order onthe Internet for a flower bouquet to be sent to his wife xyzFlowers

is acting on behalf of the customer by ordering the flowers for thecustomer without the customer's knowing about the local flower shop

If the customer doesn't receive the flowers in a timely manner, thexyzFlowers organization needs to ensure, without just taking theword of the local flower shop, that the local flower shop truly receivedthe order

There is no proof that the local flower shop is at fault because there is

no proof that it received the order Non-repudiation is when the client,xyzFlowers, sends a request to the service, the local flower shop,and there is a response and timestamp immediately returned from theservice saying that it received the order The non-repudiation protocol

is necessary to find out which organization is currently responsible forthe task

Note The purpose of a non-repudiation service is to establish

evidence that a message has had an action performed on it.This evidence is used to ensure that a message was

created, sent, submitted, transported, and received

Non-repudiation services provide an evidence generator that will

Non-Repudiation of Delivery: This service covers the case

where the recipient acknowledges that she has received themessage

Non-Repudiation of Submission: This service incorporates

a delivery service that acts as a third party that will receive themessage from the sender, acknowledge to the sender that itreceived the message, and forward it to one or more

recipients of the message It will acknowledge that the

message was sent from the sender It does not guarantee thatthe recipient received the message, but will make a best effort

to forward the message The sender trusts the delivery

service

Non-Repudiation of Transport: This service incorporates a

delivery service that acts as a third party that will receive themessage from the sender, acknowledge to the sender that themessage was received, and place the message in the datastore of the recipient The delivery service acknowledges thatthe message was placed in the recipient's data store but

cannot guarantee that the recipient received the messagebecause it cannot guarantee that the recipient checks the datastore

Distributed computing has evolved through the years to allow parts of

an enterprise system to be located on separate and possibly

heterogeneous platforms These systems may also be located indifferent geographic areas For example, there is no reason why adatabase located in Europe cannot be accessed by a transactionmanager in London

Corporation and the Object Management Group (OMG) These

distributed solutions typically require security

When an application (distributed or otherwise) provides security, there

is an expectation to safeguard user privacy, to ensure that information(such as transactions and data) is not tampered with either

accidentally or maliciously, and to prevent theft Authorized usersshould be able to access the information they are authorized to

access, and unauthorized users should not Even so, the level ofsecurity needed for the given application depends on the value of theinformation to be protected and the software and hardware involved

In addition, there are usually compromises that you must make incost, usability, and security

This chapter has brought together the different security technologiescovered throughout the book and discussed how they integrate in theJava platform In addition, this chapter briefly described Web Servicesand its associated technologies such as UDDI (Universal, Description,Discovery and Integration), WSDL (Web Service Descriptive

Language) and SOAP (Simple Object Access Protocol)

Initially, the sandbox model seemed a good security model, but astime has passed a policy-based security model seemed to satisfymore applications than the restrictive all-or-nothing model that thesandbox presented

This chapter also described the security changes included in the

J2SDK v 1.4 Some of these changes include the integration of

previously optional packages, such as JCE and JSSE It reviewed thebasics of authentication and authorization, Java permissions, and thepolicy file, which are the foundation for the next three chapters

Finally, this chapter briefly described the components that are

discussed in more detail in Chapters 27 and 28

javax.naming.directory, which extends the

javax.naming package to provide access to directories

Directory objects can have zero or more attributes, and JNDIhas the Attribute interface and Attributes interface(which is a collection of Attributes) JNDI also providesimplementation of these interfaces in BasicAttribute andBasicAttributes The DirContext interface represents adirectory context and provides methods for examining andupdating attributes associated with the directory context TheDirContext interface also provides overloaded search

methods

Tip Use DirContext.modifyAttributes() to modifythe directory Modifications to Attribute and

DirContext.getSchemaClassDefinition methods.javax.naming.event, which provides classes and

interfaces for event notification in naming and directory

services

A NamingEvent represents an event generated by a

naming/directory service The NamingEvent class definesfour types of events: OBJECT_ADDED, OBJECT_REMOVED,OBJECT_RENAMED, and OBJECT_CHANGED A

NamingEvents The NamespaceChangeListener

interface listens for namespace changes, while the

ObjectChangeListener listens for changes to an object'scontents For events notifications to be received, the listenermust be registered with either an EventContext or an

methods) request controls The InitialLdapContext is theinitial LDAP context to perform extended operations and

controls

javax.naming.spi, which is the Service Provider Interfacethat allows different providers to be dynamically plugged inunder the JNDI API

Understanding security with JNDI

JNDI has two main options: with and without security manager If

there is no security manager installed, the code is trusted and theapplication can access service providers from the local classpath If asecurity manager is installed, there is trusted and untrusted code

within the same application and access to service providers may be

env.put(Context.SECURITY_PRINCIPAL, "cn=Bob, ou=HR, o=XYZ"); env.put(Context.SECURITY_CREDENTIALS, "boby");

This chapter covered the essentials of client-side development andsecurity JNDI provides directory services to Java applications Notonly is JNDI an API, but the JNDI architecture provides a ServiceProvider Interface (SPI) so that the naming and directory services can

be abstracted from the implementation That allows different providers

to be used and interchanged without affecting the application

implementation Security in JNDI is based on the security servicesgiven by the underlying implementation and is not specified by thespecification

This chapter also covered client authentication, You have many

options to perform authentication, some of which were explored in thischapter Application deployment via the web.xml file, which specifieshow the application is configured, was covered as well

In addition, this chapter discussed Java Server Pages (JSPs) andServlets, including a brief discussion on how they are affected bysecurity Finally, you saw an application example (called Project InfoApp) that was used to illustrate how the different components fit

together With the basic examples explained here and the knowledgethat you have gained throughout the previous chapters, you can build

an application with robust authentication and authorization

platform CORBA clients.

This chapter explored the basics of CORBA and the different servicesthat CORBA provides Among these services is a security service thatprovides different levels of security In addition, the SECIOP packageprovides interoperability security and the Common Secure

Interoperability (CSI) package provides additional levels of security forinteroperability The different CSI levels that different protocols providefor your applications were listed For instance, the GSS Kerberosprotocol provides CSI level 1 but also can be used for level 0 TheRMI protocol, its security, and how it can use IIOP for the transportprotocol to bridge to CORBA were also discussed

Finally, Enterprise JavaBeans were explored first by discussing thedifferent types of EJBs that you currently encounter and giving a briefdescription of their life cycle The chapter finished with a discussion ofauthentication and authorization in the J2EE architecture and a

description of how the container provides the security mechanisms forEJBs

WebLogic Server (WLS) contains Java 2 platform technologies WLS

is part of BEA's family of products and, as of this writing, the currentversion is WLS 7.0 with full support for J2EE 1.3 You can find

layered architecture that separates the presentation, business logic,and the data connectivity The next section presents a brief overview

WebLogic provides support for transactions across EJB, JMS, J2CA,and JDBS and an infrastructure for transaction support It also

supports distributed transactions and two-phase commit, and

Protocol (LDAP) servers, can be adapted to WebLogic realms,

enabling single sign-on for the enterprise A security realm is a logical grouping of users, groups, and Access Control Lists (ACLs); a

security realm and a single ACL in that security realm protect a WLSresource Users in a security realm can access resources in that

Console allows you to modify some of the realm's

information but, for more control, it is best if you extend andmodify the provided classes

WLS authenticates and authorizes users by checking the ACL and