Distributed Application Security

Part 3, The Application, revolves around design, development and operation of secure and distributed applications developed in Java. These activities, in general terms, translate into the identification of application-specific security requirements, the selection of appropriate security API, mechanism and/or configuration elements, writing the corresponding code, and finally, testing it. The selection of appropriate security technology depends as much on the application-specific requirements as the distributed computing technology used to build the application.

We went over many different forms of distributed programs—socket-based programs; Java RMI-based programs; Web applications based on Servlets and JSPs; EJB-based applications and Web services. Each of these forms has its own security model, satisfying a different set of security considerations. For example, socket-based programs have very little built-in security whereas EJB architecture satisfies a comprehensive set of security requirements.

Though the selection of a particular form of distributed computing technology depends on overall application requirements and other organizational considerations, security requirements must play an important role in this selection process. For example, use of vanilla RMI-based server programs is not appropriate for security-sensitive applications when clients make invocations over the Internet. As another proof-point, a reason often cited for slow adoption of Web services technology among enterprises is slow rollout of interoperable security standards.

For these reasons, it is important to compare and contrast various distributed computing technologies from an application security perspective. But before we do that, let us recapitulate the application security requirements. These fall under the following headings:

  • Client authentication— the server program should be able to authenticate the client (either a human or a program);

  • Server authentication— the client should be able to authenticate the server program.

  • Client authorization— a program should be able to determine the authorization available to a particular client for a specific activity on a specific resource.

  • Message integrity and confidentiality— It should be possible to ensure integrity and confidentiality of messages exchanged between the client and the server, even in cases where the media used for exchange is not secure.

  • User identity propagation— At times, execution of a particular task involving collaboration among multiple programs may require the identity of the user to be propagated among these programs without the need for authentication by every program.

  • User identity delegation— There are times when it is better to map a user identity to another user identity through identity delegation.

Table 12-1 summarizes how these generic security requirements are supported by various distributed programming technologies within the Java platform.

Table 12-1. Mechanisms to satisfy security requirements for various distributed programming technologies
 SocketsJava RMIEJBsWeb ApplicationsWeb Services
Client AuthenticationSSL-CertificateSSL-CertificateSSL-Certificate; JNDI (username/password); JAASHTTP-Basic; HTTP-Digest;

FORM-based;

SSL-Certificate
HTTP-Basic; HTTP-Digest;

SSL-Certificate;

XML Signature
Server AuthenticationSSL-CertificateSSL-CertificateSSL-CertificateSSL-CertificateSSL Certificate; XML Signature
AuthorizationJava Policy FilesJava Policy FilesDeployment descriptor statements; Programmatic APIs; JAASDeployment descriptor statements; Programmatic APIsXML Signature
Message ConfidentialitySSLSSLSSLSSLSSL; XML Encryption
Message IntegritySSLSSLSSLSSLSSL; XML Signature
Identity PropagationNoneNoneDeployment descriptor statementsNoneXML Signature
Identity DelegationNoneNoneDeployment descriptor statementsNoneNone

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.191.233.44