Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management

J2EE-based applications can standardize the exchange of identities and access using SAML, which allows single sign-on across heterogeneous platforms within the enterprise (single domain) or across several security infrastructures (cross-domain). SAML becomes a common language or interface that allows users to sign on once to an application and to seamlessly access other applications to which they are entitled. The use of security patterns such as Assertion Builder (refer to the security patterns section later in this chapter) will be very handy. Architects and developers do not need to custom-build access control or authorization modules for each individual application or legacy system.

SAML does not replace the authentication service in J2EE-based applications and Web services. Developers still require the use of an authentication infrastructure, which may be a JAAS authentication module or a home-grown authentication framework using a directory server. After the system authenticates a user, a SAML authentication assertion is created. SAML also does not substitute for a policy manager or policy engine. Developers still need a policy manager that stores the access control rules and enforces the security policy rules using a Policy Enforcement Point. The policy manager evaluates the user and then creates a SAML attribute assertion based on the policies and rules defined.

There are two SAML usage scenarios in a J2EE-based application environment:

• Once the J2EE application authenticates a user, the J2EE components can create a SAML Authentication Assertion for that authentication event. This can be accomplished using a JAAS authentication module as part of the post-login process. In addition, it can implement the SAML Web Browser SSO profile, which defines how SAML Authentication Assertions are represented using the Authentication Query and Response messages to enable SSO for a user accessing via a Web browser.

• J2EE applications can make use of SAML assertions obtained from a user who is authenticated to an external security infrastructure (that acts as a SAML authority). Based on this authentication, the user receives SAML assertions and uses them to access J2EE applications. In this case, the J2EE applications can make use of a JAAS login module to verify the SAML assertions for authenticity. The JAAS login module can initiate callbacks to request the user's SAML assertions from the SAML authority using the SOAP protocol or HTTP POST. If the SAML assertions are found to be correct, then the JAAS login module can make use of the commit() method, which adds the Principal from the corresponding SAML assertion and populates the Subject with the Principal. If the authentication fails, the commit() method returns false and destroys the authentication state information and denies access to the requested application.

Without the use of SAML, J2EE-based applications are confined to proprietary mechanisms for passing authentication and authorization information between each other. This works well under an ideal, monolithic enterprise IT environment that has only J2EE-based applications. However, if there are custom-built applications, ERP, and legacy systems, architects and developers need to customize J2EE connectors and build session control for single sign-on. In such a case, the development effort is considerable, and the integration with these systems is fairly complex.