Understanding WebLogic Security
Deploying, managing, and maintaining security is a huge challenge for an information technology (IT) organization that is providing new and expanded services to customers using the Web. To serve a worldwide network of Web-based users, an IT organization must address the fundamental issues of maintaining the confidentiality, integrity and availability of the system and its data. Challenges to security involve every component of the system, from the network itself to the individual client machines. Security across the infrastructure is a complex business that requires vigilance as well as established and well-communicated security policies and procedures.
WebLogic Server includes a security architecture that provides a unique and secure foundation for applications that are available via the Web. By taking advantage of the new security features in WebLogic Server, enterprises benefit from a comprehensive, flexible security infrastructure designed to address the security challenges of making applications available on the Web. WebLogic security can be used standalone to secure WebLogic Server applications or as part of an enterprise-wide, security management system that represents a best-in-breed, security management solution.
The open, flexible security architecture of WebLogic Server delivers advantages to all levels of users and introduces an advanced security design for application servers. Companies now have a unique application server security solution that, together with clear and well-documented security policies and procedures, can assure the confidentiality, integrity and availability of the server and its data.
The components and services of the WebLogic Security Service seek to strike a balance between ease of use, manageability (for end users and administrators), and customizability (for application developers and security developers). The following paragraphs highlight some examples:
Easy to use: For the end user, the secure WebLogic Server environment requires only a single sign-on for user authentication (ascertaining the user's identity). Users do not have to re-authenticate within the boundaries of the WebLogic Server domain that contains application resources. Single sign-on allows users to log on to the domain once per session rather than requiring them to log on to each resource or application separately.
For the developer and the administrator, WebLogic Server provides a new Domain Configuration Wizard to help with the creation of new domains with an administration server, managed servers, and optionally, a cluster, or with extending existing domains by adding individual severs. The Domain Configuration Wizard also automatically generates a
config.xml file and start scripts for the server(s) you choose to add to the new domain.
Manageable: Administrators who configure and deploy applications in the WebLogic Server environment can use the WebLogic security providers included with the product. These default providers support all required security functions, out of the box. An administrator can store security data in the WebLogic Server-supplied, security store (an embedded, special-purpose, LDAP directory server) or use an external LDAP server, database, or user source. To simplify the configuration and management of security in WebLogic Server, a robust, default security configuration is provided.
Customizable: For application developers, WebLogic Server supports the WebLogic security API and J2EE security standards such as JAAS, JSS, JCE, and JACC. Using these APIs and standards, you can create a fine-grained and customized security environment for applications that connect to WebLogic Server.
Note: If you are not familiar with the new features provided in version 9.0 of WebLogic Server, see the What's New in WebLogic Server 9.0 section of the WebLogic Server Release Notes, which is available here: What's New in WebLogic Server 9.0.
As of version 9.1, WebLogic Server has implementations of a set of authorization and role mapping providers that support the eXtensible Access Control Markup Language (XACML) 2.0 standard from OASIS. WebLogic Server includes two new security providers, the XACML Authorization provider and the XACML Role Mapping provider.
New domains created using 9.1 will default to using the XACML authorization and role mapping providers. Existing domains, upgraded to 9.1, will continue to use the authorization and role mapping providers currently specified, such as third-party partner providers or the original WebLogic Server proprietary providers. Customers who want to migrate existing domains from using WebLogic Server proprietary providers to the XACML providers can do so, including performing bulk moves of existing policy.
If you use the WebLogic Server Administration Console to add a new Authorization or Role Mapping provider, you can add the new provider as a DefaultAuthorizer or DefaultRoleMapper provider, or as a XACML provider.
The XACML 2.0 specification is available at (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml).
In WebLogic Server 9.0, all SAML configuration was done by means of configuration attributes on the SAML provider MBeans. In WebLogic Server 9.1, configuration of the SAML providers and services has been enhanced as follows:
In WebLogic Server 9.0, SAML used the server's SSL server identity credentials (private key and certificate chain) for signing assertions and SAML protocol elements, and for connecting to external SAML services when SSL client credentials were required.
In WebLogic Server 9.1, SAML still relies on the server's keystore and requires that SSL be configured to use keystores, but it is now possible to configure separate aliases and passphrases for three distinct credentials: an assertion signing key, a protocol signing key, and an SSL client identity. Each of these credentials defaults to the server's SSL identity if not specified. These changes are implemented only in the new versions of the providers.
WebLogic Server 9.1 improves trust management by requiring that each partner configuration specify the aliases of the certificates trusted for particular purposes - assertion signing, SAML protocol element signing, and SSL client authentication.
As in WebLogic Server 9.0, certificates must be present in the SAML certificate registry to be trusted. However, registration is a necessary but insufficient condition for trust. Unlike WebLogic Server 9.0, which trusts any registered certificate for any purpose, WebLogic Server 9.1 trusts only the specific certificate configured, on a per-partner basis, for the particular purpose at hand.
WebLogic Server 9.1 removes the requirement that signatures include a <ds:keyinfo> element containing a certificate that can be used to verify the signature. Because the certificate trusted for a given signature is known through configuration, the SAML runtime does not need <ds:keyinfo> for signature verification.
During execution of the Browser/Artifact profile, which specifies a method of conveying an SSO assertion to an ACS service by passing an identifying "artifact" as a query parameter, a destination site that has received a SAML artifact contacts the source site that issued the artifact to retrieve the corresponding assertion.
The WebLogic Server 9.0 Assertion Retrieval Service (ARS) can verify trust in destination sites when two-way SSL is used, but cannot verify that the destination site requesting an assertion is the one to which an artifact was sent.
In WebLogic Server 9.1, the ARS supports multiple authentication methods for destination sites (SSL client certificate, username/password), and verifies that the site requesting an assertion is the site to which the corresponding artifact was sent.
SAML partner configuration in WebLogic Server 9.1 includes the ability to specify parameters that are appended as query parameters when redirecting, or included as form variables when POSTing, during execution of the of SSO profiles. In addition, the implementation ensures that any query parameters/form variables received on a SAML service URL are propagated end-to-end during execution of the SSO profiles.
One important use of this feature is to include partner IDs as request parameters. (Many SAML implementations require that a partner ID be specified as a query parameter on an incoming SSO profile request.) WebLogic Server 9.1 also requires that partner IDs be present, and uses them to look up partner configuration information.
WebLogic Server provides several application WAR files that are deployed by default to provide application contexts for the SAML services. These WAR files contain no displayable files or executable code; they exist only to provide application contexts and deployment descriptors appropriate to the SAML services.
In WebLogic Server 9.0, these applications are always deployed on every server. In WebLogic Server 9.1, the applications are individually deployed only when actually needed; that is, when one or more SAML services are configured to run in that application context on the server where the application is deployed.