How do I design secure Web services in J2EE? Should I use Acegi for authentication? What part does Aspect-Oriented Programming (AOP) play?
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
Before I discuss Web services security, I would like to highlight the relevant Java APIs for XML Web services. In J2EE, the Java APIs for XML Web services have become an integral part of J2EE 1.4 and later. Java EE5, the newest release of J2EE platform, offers a more comprehensive solution for Web services by supporting key OASIS XML Web services standards and WS-I profiles. These Java APIs for XML Web services are also collectively available as JAX-WS 2.0. To implement Web services security, JAX-WS provides support for OASIS-endorsed XML security standards such as WS-Security, XML-Signature, XML-Encryption and SAML tokens. From open-source initiatives, Apache Axis provides similar capabilities.
In a J2EE application environment, building a comprehensive security model for Web services mandates design and implementation of security at the "transport layer" and "message layer" of its exposed Web services endpoint.
Message-layer security contributes to ensuring XML message and element-level confidentiality, data integrity, message authentication and non-repudiation. The J2EE environment (J2EE 1.4 and above) allows implementation of XML security by providing support for Web services security standards such as WS-Security, XML-Signature and XML-Encryption.
Effectively, to achieve end-to-end security of a Web services-based application environment, it is important to mitigate for other known security risks at the network perimeter, target hosts and application infrastructure, including database and directory services. It is also important to adopt standards-based security mechanisms and verify the Web services security mechanisms for interoperability so that the promise of adopting XML Web services is not sacrificed.
Now, answering your question about using Acegi for Web services security! Acegi is a security framework primarily designed to secure applications developed using the Spring API framework only. Spring is usually considered as an alternative API solution to implementing EJB components. More important, Acegi does not offer support for XML Web services security standards.
AOP can definitely be considered one of the development approaches for implementing Web services security in J2EE applications. For example, implementing message-level security can be accomplished using a modular approach via AOP where each aspect can address a message-level security requirement such as encryption, signature, logging, etc.
Speaking from my experience, I have been practicing Web services security using security patterns and best practices-based approaches. Security patterns help how a security-related problem can be resolved architecturally or built by implementing a known defensive strategy or a best practice(s). Security patterns are usually represented using a standard template, which captures all the elements of pattern and describes its security motivation in terms of technology used, strategy, scenarios and examples. I would suggest you take a look at Core Security Patterns.
In a J2EE application environment, building a comprehensive security model for Web services mandates design and implementation of security at the "transport layer" and "message layer" of its exposed Web services endpoint.
- The transport-layer security represents the protection of communication and ensures confidentiality and integrity of the transmitted messages between the communicating service endpoints.
Two-way SSL/TLS communication (client/server or mutual authentication via SSL) is often recommended for transport-layer security. From J2EE 1.4 and above (Java EE5), the Java EE application server environment allows you to configure two-way SSL communication for securing transport between XML Web services endpoints. Both JAX-WS and Apache Axis-based Web services solutions provide SSL/TLS support. - The message-layer security represents the protection of actual XML messages, including application-specific content such as a user's identity, routing information, authentication/authorization credentials and business data. Without message-layer security, the XML message and its elements will be available for potential viewing or manipulation or interception by unintended recipients and Web services intermediaries.
Message-layer security contributes to ensuring XML message and element-level confidentiality, data integrity, message authentication and non-repudiation. The J2EE environment (J2EE 1.4 and above) allows implementation of XML security by providing support for Web services security standards such as WS-Security, XML-Signature and XML-Encryption.
Effectively, to achieve end-to-end security of a Web services-based application environment, it is important to mitigate for other known security risks at the network perimeter, target hosts and application infrastructure, including database and directory services. It is also important to adopt standards-based security mechanisms and verify the Web services security mechanisms for interoperability so that the promise of adopting XML Web services is not sacrificed.
Now, answering your question about using Acegi for Web services security! Acegi is a security framework primarily designed to secure applications developed using the Spring API framework only. Spring is usually considered as an alternative API solution to implementing EJB components. More important, Acegi does not offer support for XML Web services security standards.
AOP can definitely be considered one of the development approaches for implementing Web services security in J2EE applications. For example, implementing message-level security can be accomplished using a modular approach via AOP where each aspect can address a message-level security requirement such as encryption, signature, logging, etc.
Speaking from my experience, I have been practicing Web services security using security patterns and best practices-based approaches. Security patterns help how a security-related problem can be resolved architecturally or built by implementing a known defensive strategy or a best practice(s). Security patterns are usually represented using a standard template, which captures all the elements of pattern and describes its security motivation in terms of technology used, strategy, scenarios and examples. I would suggest you take a look at Core Security Patterns.
This was first published in August 2006