Understanding WebLogic Security
Security Fundamentals
The following sections describe security fundamentals as they relate to security in WebLogic Server:
- Auditing
- Authentication
- Security Assertion Markup Language (SAML)
- Single Sign-On (SSO)
- Authorization
- Identity and Trust
- Secure Sockets Layer (SSL)
- Firewalls
- J2EE and WebLogic Security
Auditing
Auditing is the process whereby information about operating requests and the outcome of those requests are collected, stored, and distributed for the purposes of non-repudiation. In other words, auditing provides an electronic trail of computer activity. In the WebLogic Server security architecture, an Auditing provider is used to provide auditing services.
If configured, the WebLogic Security Framework will call through to an Auditing provider before and after security operations (such as authentication or authorization) have been performed, when changes to the domain configuration are made, or when management operations on any resources in the domain are invoked. The decision to audit a particular event is made by the Auditing provider itself and can be based on specific audit criteria and/or severity levels. The records containing the audit information may be written to output repositories such as an LDAP server, database, and a simple file.
Authentication
Authentication is the mechanism by which callers prove that they are acting on behalf of specific users or systems. Authentication answers the question, “Who are you?” using credentials such as username/password combinations.
In WebLogic Server, Authentication providers are used to prove the identity of users or system processes. Authentication providers also remember, transport, and make identity information available to various components of a system (via subjects) when needed. During the authentication process, a Principal Validation provider provides additional security protections for the principals (users and groups) contained within the subject by signing and verifying the authenticity of those principals.
The following sections describe authentication concepts and functionality.
- Subjects and Principals
- Java Authentication and Authorization Service (JAAS)
- CallbackHandlers
- Mutual Authentication
- Servlet Authentication Filters
- Identity Assertion Providers and LoginModules
- Identity Assertion and Tokens
- Types of Authentication
Subjects and Principals
Subjects and principals are closely related.
A principal is an identity assigned to a user or group as a result of authentication. Both users and groups can be used as principals by application servers such as WebLogic Server. The Java Authentication and Authorization Service (JAAS) requires that subjects be used as containers for authentication information, including principals.
Figure 3-1 illustrates the relationships among users, groups, principals, and subjects. Figure 3-1 Relationships Among Users, Groups, Principals and Subjects
As part of a successful authentication, principals are signed and stored in a subject for future use. A Principal Validation provider signs principals, and an Authentication provider's LoginModule actually stores the principals in the subject. Later, when a caller attempts to access a principal stored within a subject, a Principal Validation provider verifies that the principal has not been altered since it was signed, and the principal is returned to the caller (assuming all other security conditions are met).
Any principal that is going to represent a WebLogic Server user or group needs to implement the WLSUser and WLSGroup interfaces, which are available in the weblogic.security.spi package.
Java Authentication and Authorization Service (JAAS)
Whether the client is an application, applet, Enterprise JavaBean (EJB), or servlet that requires authentication, WebLogic Server uses the Java Authentication and Authorization Service (JAAS) classes to reliably and securely authenticate to the client. JAAS implements a Java version of the Pluggable Authentication Module (PAM) framework, which permits applications to remain independent from underlying authentication technologies. Therefore, the PAM framework allows the use of new or updated authentication technologies without requiring modifications to your application.
WebLogic Server uses JAAS for remote fat-client authentication, and internally for authentication. Therefore, only developers of custom Authentication providers and developers of remote fat client applications need to be involved with JAAS directly. Users of thin clients or developers of within-container fat client applications (for example, those calling an Enterprise JavaBean (EJB) from a servlet) do not require the direct use or knowledge of JAAS.
JAAS LoginModules
LoginModules are the work-horses of authentication: all LoginModules are responsible for authenticating users within the security realm and for populating a subject with the necessary principals (users/groups). LoginModules that are not used for perimeter authentication also verify the proof material submitted (for example, a user's password).
If there are multiple Authentication providers configured in a security realm, each of the Authentication providers' LoginModules will store principals within the same subject. Therefore, if a principal that represents a WebLogic Server user (that is, an implementation of the WLSUser interface) named “Joe” is added to the subject by one Authentication provider's LoginModule, any other Authentication provider in the security realm should be referring to the same person when they encounter “Joe”. In other words, the other Authentication providers' LoginModules should not attempt to add another principal to the subject that represents a WebLogic Server user (for example, named “Joseph”) to refer to the same person. However, it is acceptable for another Authentication provider's LoginModule to add a principal of a type other than WLSUser with the name “Joseph”.
JAAS Control Flags
If a security realm has multiple Authentication providers configured, the Control Flag attribute on the Authenticator provider determines the ordered execution of the Authentication providers. The values for the Control Flag attribute are as follows:
- REQUIRED—This LoginModule must succeed. Even if it fails, authentication proceeds down the list of LoginModules for the configured Authentication providers. This setting is the default.
- REQUISITE—This LoginModule must succeed. If other Authentication providers are configured and this LoginModule succeeds, authentication proceeds down the list of LoginModules. Otherwise, return control to the application.
- SUFFICIENT—This LoginModule needs not succeed. If it does succeed, return control to the application. If it fails and other Authentication providers are configured, authentication proceeds down the LoginModule list.
- OPTIONAL—The user is allowed to pass or fail the authentication test of this Authentication providers. However, if all Authentication providers configured in a security realm have the JAAS Control Flag set to OPTIONAL, the user must pass the authentication test of one of the configured providers.
CallbackHandlers
A CallbackHandler is a highly-flexible JAAS standard that allows a variable number of arguments to be passed as complex objects to a method. There are three types of CallbackHandlers: NameCallback, PasswordCallback, and TextInputCallback, all of which are part of the javax.security.auth.callback package. The NameCallback and PasswordCallback return the username and password, respectively. TextInputCallback can be used to access the data users enter into any additional fields on a login form (that is, fields other than those for obtaining the username and password). When used, there should be one TextInputCallback per additional form field, and the prompt string of each TextInputCallback must match the field name in the form. WebLogic Server only uses the TextInputCallback for form-based Web application login.
An application implements a CallbackHandler and passes it to underlying security services so that they may interact with the application to retrieve specific authentication data, such as usernames and passwords, or to display certain information, such as error and warning messages.
CallbackHandlers are implemented in an application-dependent fashion. For example, implementations for an application with a graphical user interface (GUI) may pop up windows to prompt for requested information or to display error messages. An implementation may also choose to obtain requested information from an alternate source without asking the user.
Underlying security services make requests for different types of information by passing individual Callbacks to the CallbackHandler. The CallbackHandler implementation decides how to retrieve and display information depending on the Callbacks passed to it. For example, if the underlying service needs a username and password to authenticate a user, it uses a NameCallback and PasswordCallback. The CallbackHandler can then choose to prompt for a username and password serially, or to prompt for both in a single window.
Mutual Authentication
With mutual authentication, both the client and the server are required to authenticate themselves to each other. This can be done by means of certificates or other forms of proof material. WebLogic Server supports two-way SSL authentication, which is a form of mutual authentication. However, by strict definition, mutual authentication takes place at higher layers in the protocol stack then does SSL authentication. For more information, see One-way/Two-way SSL Authentication.
Identity Assertion Providers and LoginModules
When used with a LoginModule, identity assertion providers support single sign-on. For example, an identity assertion provider can process a SAML assertion so that users are not asked to sign on more than once.
The LoginModule that an identity assertion provider uses can be:
- Part of a custom Authentication provider you develop.
- Part of the WebLogic Authentication provider that Oracle developed and packaged with WebLogic Server.
- Part of a third-party security vendor's Authentication provider.
Unlike in a simple authentication situation, the LoginModules that identity assertion providers use do not verify proof material such as usernames and passwords; they simply verify that the user exists.
Identity Assertion and Tokens
identity assertion providers support user name mappers, which map a valid token to a WebLogic Server user. You develop identity assertion providers to support the specific types of tokens that you will be using to assert the identities of users or system processes. You can develop an identity assertion provider to support multiple token types, but the WebLogic Server administrator must configure the identity assertion provider so that it validates only one “active” token type. While you can have multiple identity assertion providers in a security realm with the ability to validate the same token type, only one identity assertion provider can actually perform this validation.
To use the WebLogic identity assertion provider for X.501 and X.509 certificates, you have the option of using the default user name mapper that is supplied with the WebLogic Server product (weblogic.security.providers.authentication. DefaultUserNameMapperImpl) or providing you own implementation of the weblogic.security.providers.authentication.UserNameMapper interface. For more information, see Do I Need to Develop a Custom Identity Assertion Provider? in Developing security providers for WebLogic Server.
Challenge Identity Assertion
Challenge identity assertion schemes provide for multiple challenges, responses messages, and state. A WebLogic Server security realm can include security providers that support authentication protocols such as Microsoft's Windows NT Challenge/Response (NTLM), Simple and Protected GSS-API Negotiation Mechanism (SPNEGO), and other challenge/response authentication mechanisms. WebLogic Server includes a SPNEGO security provider, named the Negotiate identity assertion provider. You can develop and deploy security providers that implement NTLM or other challenge/response authentication mechanisms. For more information, see Developing security providers for WebLogic Server.
Servlet Authentication Filters
As defined by the Java Servlet API 2.3 specification, filters are objects that can modify a request or response. Filters are preprocessors of the request before it reaches the servlet, and/or postprocessors of the response leaving the servlet. Filters provide the ability to encapsulate recurring tasks in reusable units.
Filters can be used as a substitute for container-based authentication but there are some drawbacks to this design:
- As specified by the Java Servlet API 2.3 specification, filters are run after authentication and authorization. If filters are used for authentication, they must also be used for authorization thereby preventing container-managed authorization from being used. Most use cases that require extensions to the authentication process in the Servlet container do not require extensions to the authorization process. Having to implement the authorization process in a filter is awkward, time consuming, and error-prone.
- J2EE filters are defined per Web application. Code for a filter must reside in the WAR file for the Web application and the configuration must be defined in the web.xml file. An authentication mechanism is typically determined by the system administrator after an application is written (not by the programmer who created the WAR file). The mechanism can be changed during the lifetime of an application, and is desired for all (or at least most) applications in a site.
Servlet Authentication filters are an extension to of the filter object which overcome these drawbacks allowing filters to replace container-based authentication.
JAAS LoginModules (within a WebLogic Authentication provider) can be used for customization of the login process. Servlet Authentication filters enable the LoginModule model allowing the authentication provider to control the actual conversation with the client. Customizing the location of the user database, the types of proof material required to execute a login, or the population of the Subject with groups is implemented via a LoginModule. On the other hand, redirecting to a remote site to execute the login, extracting login information out of the query string, and negotiating a login mechanism with a browser is implemented via a Servlet Authentication filter.
Types of Authentication
WebLogic Server users must be authenticated whenever they request access to a protected WebLogic resource. For this reason, each user is required to provide a credential (for example, a password) to WebLogic Server. The following types of authentication are supported by the WebLogic Authentication provider that is included in the WebLogic Server distribution:
- Username/Password Authentication
- Certificate Authentication
- Digest Authentication
- Perimeter Authentication
WebLogic Server can use the WebLogic Authentication provider that is provided as part of the WebLogic Server product or custom security providers to perform the different types of authentication. For information on the WebLogic Authentication provider and how to configure authentication, see The Authentication Process on page 5-3 and the following sections in Securing WebLogic Server:
Username/Password Authentication
In username/password authentication, a user ID and password are requested from the user and sent to WebLogic Server. WebLogic Server checks the information and if it is trustworthy, grants access to the protected WebLogic resource.
Secure Sockets Layer (SSL), or Hyper-Text Transfer Protocol (HTTPS), can be used to provide an additional level of security to username/password authentication. Because SSL encrypts the data transferred between the client and WebLogic Server, the user ID and password of the user do not flow in the clear. Therefore, WebLogic Server can authenticate the user without compromising the confidentiality of the user's ID and password.
Certificate Authentication
When an SSL or HTTPS client request is initiated, WebLogic Server responds by presenting its digital certificate to the client. The client then verifies the digital certificate and an SSL connection is established. The digital certificate is issued by an entity (a trusted certificate authority), which validates the identity of WebLogic Server.
You can also use two-way SSL authentication, a form of mutual authentication. With two-way SSL authentication, both the client and server must present a certificate before the connection thread is enabled between the two. See One-way/Two-way SSL Authentication.
Two-way SSL authentication is supported by the WebLogic Authentication provider that is provided as part of the WebLogic Server product.
Digest Authentication
When using Digest authentication, the client makes an un-authenticated request to the server, and the server sends a response with a digest authentication challenge indicating that it supports Digest authentication. The client generates a nonce and sends it to the server along with a timestamp, digest, and username. The digest is a cyptographic hash of the password, nonce, and timestamp. The client requests the resource again this time sending the username and a cyptographic hash of the password combined with the nonce value. The server generates the hash itself, and if the generated hash matches the hash in the request, the request is allowed.
The advantage of Digest authentication is it is resistant to replay attacks. The implementation maintains a cache of used nonces/timestamps for a specified period of time. All requests with a timestamp older than the specified timestamp are rejected as well as any requests that use the same timestamp/nonce pair as the most recent timestamp/nonce pair still in the cache. WebLogic Server stores this cache in a database. A command-line option is available to disable the cache in order to improve performance.
Perimeter Authentication
Perimeter authentication is the process of authenticating the identity of a remote user outside of the application server domain.
The following sections describe perimeter authentication:
- How is Perimeter Authentication Accomplished?
- How Does WebLogic Server Support Perimeter Authentication?
How is Perimeter Authentication Accomplished?
Perimeter authentication is typically accomplished by the remote user specifying an asserted identity and some form of corresponding proof material, normally in the form of a passphrase (such as a password, a credit card number, Personal Identification Number, or some other form of personal identification information), which is used to perform the verification.
The authentication agent, the entity that actually vouches for the identity, can take many forms, such as a Virtual Private Network (VPN), firewall, an enterprise authentication service, or some other form of global identity service. Each of these forms of authentication agents has a common characteristic: they all perform an authentication process that results in an artifact or token that must be presented to determine information about the authenticated user at a later time. Currently, the format of the token varies from vendor to vendor, but there are efforts to define a standard token format using XML. In addition, there is a current standard for Attribute Certificates, which is based on the X.509 standard for digital certificates. But even after all of this, if the applications and the infrastructure on which they are built are not designed to support this concept, enterprises are still forced to require that their remote users re-authenticate to the applications within the network.
How Does WebLogic Server Support Perimeter Authentication?
WebLogic Server is designed to extend the single sign-on concept all the way to the perimeter through support for identity assertion (see Figure 3-2). Provided as a critical piece of the WebLogic Security Framework, the concept of identity assertion allows WebLogic Server to use the authentication mechanism provided by perimeter authentication schemes such as the Security Assertion Markup Language (SAML), the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO), or enhancements to protocols such as Common Secure Interoperability (CSI) v2 to achieve this functionality. Figure 3-2 Perimeter Authentication
Support for perimeter authentication requires the use of an identity assertion provider that is designed to support one or more token formats. Multiple and different identity assertion providers can be registered for use. The tokens are transmitted as part of any normal business request, using the mechanism provided by each of the various protocols supported by WebLogic Server. Once a request is received with WebLogic Server, the entity that handles the processing of the protocol message recognizes the existence of the token in the message. This information is used in a call to the WebLogic Security Framework that results in the appropriate identity assertion provider being called to handle the verification of the token. It is the responsibility of the identity assertion provider implementation to perform whatever actions are necessary to establish validity and trust in the token and to provide the identity of the user with a reasonable degree of assurance, without the need for the user to re-authenticate to the application.
Security Assertion Markup Language (SAML)
The SAML standard defines a common XML framework for creating, requesting, and exchanging security assertions between software entities on the Web. This framework specifies how SAML assertions and protocols may be used to provide the following:
- Browser-based single sign-on (SSO) between online business partners
- The exchange of identity information in web services security
SAML was developed by the Organization for the Advancement of Structured Information Standards (OASIS), and this release of WebLogic Server includes broad support for SAML 1.1 and 2.0, including support for the following:
- SAML Web SSO profile
The SAML Web SSO profile specifies how SAML assertions and protocols should be used to provide browser-based single sign-on between an identity provider (a producer of assertions) and a service provider (a consumer of assertions).
In the SAML 2.0 Web SSO profile, a web user either invokes a resource hosted by a service provider site, or accesses an identity provider site in a way that results in an invocation on a resource hosted by the service provider. In either case, the web user is authenticated by the identity provider, which in turn generates an assertion on behalf of that user that contains information about the user's identity. The identity provider sends the assertion to the service provider, which consumes the assertion by extracting identity information about the user that is mapped to a Subject in the local security realm.
- Web Services Security (WS-Security) SAML Token profile 1.1
The SAML Token profile is part of the core set of WS-Security standards, and specifies how SAML assertions can be used for Web Services security. WebLogic Server supports SAML Token Profile 1.1, including support for SAML 2.0 and SAML 1.1 assertions. SAML Token Profile 1.1 is backwards compatible with SAML Token Profile 1.0.
The following sections introduce how SAML is supported in WebLogic Server:
SAML Framework Concepts
The SAML framework is based on the following concepts.
The terms for these concepts differ somewhat between SAML 1.1 and 2.0, particularly regarding how the entities to which they correspond are represented in the WebLogic Server Administration Console, as described in this section.
- identity provider—A system, or administrative domain, that asserts that a user has been authenticated and is given associated attributes. For example, there is a user Dan Murphy, he has an email address of dmurphy@company.com and he authenticated to this domain using a password mechanism. An identity provider is also known as a SAML authority, asserting party, or source site, and is often abbreviated as IdP.
You can configure a WebLogic Server instance to act in the role of identity provider. An identity provider is known by its Issuer URI (name). The SAML credential mapping provider supplies this functionality in WebLogic Server. (Note that the specific credential mapping provider you configure is specific to the version of SAML you are using.)
When you configure SAML 1.1 services in a WebLogic Server instance, the Administration Console uses the term source site in place of identity provider.
- service provider—A system, or administrative domain, that determines whether it trusts the assertions provided to it by the identity provider. SAML defines a number of mechanisms that enable the service provider to trust the assertions provided to it. A service provider is also known as a relying party, or destination site, and is often abbreviated as SP.
Although a service provider may trust the assertions provided to it, local access policy defines whether the subject may access local resources. Therefore, even if a service provider trusts that a user is Dan Murphy, it does not mean Dan Murphy can access all the resources in the domain.
You can configure a WebLogic Server instance to act in the role of service provider. Trust relationships with identity provider partners must be established. The SAML identity assertion provider supplies this functionality in WebLogic Server. (Note that the specific identity assertion provider you configure is specific to the version of SAML you are using.)
When you configure SAML 1.1 services in a WebLogic Server instance, the Administration Console uses the term destination site in place of service provider.
- Assertions—An assertion is a package of information that supplies one or more statements made by an identity provider. The following types of statements are supported:
- Authentication statements, which say when and how a subject was authenticated.
- Attribute statements, which provide specific information about the subject (for example, what groups the Subject is a member of).
- Authorization statements identity what the Subject is entitled to do.
Note the following regarding SAML assertions in WebLogic Server:
Note: Attribute statements are supported only for the purpose of including group information. The SAML Authentication provider can retrieve group information from a SAML assertion (see Configuring the SAML Authentication Provider in Securing WebLogic Server.) Note: SAML authorization is not supported in this release of WebLogic Server.
- Protocols—SAML defines a number of request/response protocols for obtaining assertions. A SAML request can ask for a specific known assertion or make authentication or attribute decision queries, with the SAML response providing back the requested assertions. The XML format for protocol messages with their allowable extensions is defined in an XML schema.
WebLogic Server supports the authentication request protocol, which defines an authentication request (that is, a message containing an <AuthnRequest> statement) that causes an authentication response (that is, a message containing a <Response> statement) to be returned. The authentication response contains an assertion that pertains to a Principal.
Typically the authentication request is sent by a service provider to an identity provider, which returns the authentication response. The authentication request protocol is used to support the Web Browser SSO Profile.
- Bindings—Bindings define the lower-level communication or messaging protocols (such as HTTP or SOAP) over which the SAML protocols can be transported. A binding details exactly how the SAML protocol maps onto transport and messaging protocols. For example, the mapping of the SAML <AuthnRequest> message onto HTTP.
For SAML 1.1, WebLogic Server provides support for the HTTP POST and HTTP Artifact bindings for the Web SSO profile. For SAML 2.0, WebLogic Server adds the HTTP Redirect binding for the Web SSO profile.
- Profiles—Descriptions of particular flows of assertions and protocol messages that define how SAML can be used for a particular purpose. A profile is the combination of protocols, bindings, and the structure of assertions that are used to support a particular use case, such as the Web SSO profile and SAML Token profile supported in WebLogic Server.
- Metadata files—SAML 2.0 defines a new metadata schema for exchanging configuration information between partners. WebLogic Server supports this schema by providing the ability to create local site configuration data that is published to a file and shared with partners for use with the Web SSO Profile. Partners subsequently import this metadata file to retrieve this configuration data, which is used to populate partner registries and ensure that SAML messages can be transmitted and consumed more consistently and reliably. Note that metadata files are not used with the WS-Security SAML Token Profile 1.1.
For a complete description of these concepts and how they apply to the SAML architecture, see the following:
- For SAML V1.1, see Technical Overview of the OASIS Security Assertion Markup Language (SAML) V1.1.
- For SAML V2.0, see Security Assertion Markup Language (SAML) 2.0 Technical Overview.
SAML Components Provided in WebLogic Server
Support for SAML 1.1 and 2.0 is provided in the following WebLogic Server components:
- SAML security providers
- Single Sign-On services
- Web Services support for SAML Token Profile 1.1
SAML security providers
WebLogic Server provides the following security providers to support SAML 1.1 and 2.0:
| To support . . . | The following provider . . . | Does the following . . . |
|---|---|---|
| SAML 1.1 | SAML credential mapping provider Version 2 | Generates SAML 1.1 assertions. This provider must be configured for a WebLogic Server instance that serves as an identity provider (or, as identified in the Administration Console, the source site). |
| SAML credential mapping provider Version 1 | Generates SAML 1.1 assertions (deprecated). | |
| SAML identity assertion provider Version 2 | Consumes SAML 1.1 assertions. This provider must be configured for a WebLogic Server instance that serves as an service provider (or, as identified in the Administration Console, the destination site). | |
| SAML identity assertion provider Version 1 | Consumes SAML 1.1 assertions (deprecated). | |
| SAML 2.0 | SAML 2.0 credential mapping provider | Generates SAML 2.0 assertions. This provider must be configured for a WebLogic Server instance that serves as an identity provider. |
| SAML 2.0 identity assertion provider | Consumes SAML 2.0 assertions. This provider must be configured for a WebLogic Server instance that serves as an service provider. | |
| SAML 1.1 and 2.0 | SAML Authentication provider | Enables “virtual user” functionality for both the SAML 1.1 and SAML 2.0 identity assertion providers. (See Configuring the SAML Authentication Provider in Securing WebLogic Server.) |
Single Sign-On Services
WebLogic Server can be configured to act as a SAML identity provider (IdP), service provider, or both. When acting as an IdP, the SAML credential mapping provider must be configured so that the IdP can produce assertions. When acting as a service provider, the SAML identity assertion provider must be configured so that the service provider can consume assertions.
SAML Single Sign-On Services (SSO) are configured on a per-server basis. To enable SAML SSO in two or more servers in a domain, such as in a cluster, the recommended approach is to do the following:
- Create a domain in which the RDBMS security store is configured. For more information, see “Managing the RDBMS Security Store” in Securing WebLogic Server.
- Ensure that SSO services are configured individually and identically on each server instance.
Web Services support for SAML Token Profile 1.1
WebLogic Server Web Services supports SAML Token Profile 1.1. This feature includes support for both SAML 2.0 and SAML 1.1 assertions and is backwards-compatible with SAML Token Profile 1.0.
You configure SAML tokens for a web service through use of the appropriate WS-SecurityPolicy assertions.
SAML Token Profile 1.1 is supported only through WS-SecurityPolicy. The earlier “WLS 9.2 Security Policy” supports SAML Token Profile 1.0/SAML 1.1 only.
When using SAML Token Profile, the appropriate SAML security providers must be configured (either the SAML 2.0 or SAML 1.1 credential mapping or identity assertion providers) depending on the desired SAML version and assertion usage.
Single Sign-On (SSO)
Single Sign-On is the ability to require a user to sign on to an application only once and gain access to many different application components, even though these components may have their own authentication schemes. Single sign-on enables users to login securely to all their applications, web sites and mainframe sessions with just one identity. WebLogic Server provides single sign-on (SSO) with the following environments:
Web Browsers and HTTP Clients via SAML
The Security Assertion Markup Language (SAML) enables cross-platform authentication between Web applications or Web Services running in a WebLogic Server domain and Web browsers or other HTTP clients. WebLogic Server supports single sign-on (SSO) based on SAML. When users are authenticated at one site that participates in a single sign-on (SSO) configuration, they are automatically authenticated at other sites in the SSO configuration and do not need to log in separately.
When you use the Administration Console to configure SAML, you will notice that the names used for some SAML entities differ between SAML 1.1 and 2.0. This section identifies the key terminology differences.
The following steps describe a typical scenario that shows how SAML SSO works.
- A Web user attempts to access a target resource at a site that is configured to accept authentications through SAML assertions.
When configuring SAML 1.1 in the Administration Console, this site is called the destination site. In SAML 2.0, this site is called the service provider.
- The service provider determines that the user's credentials need to be authenticated by a central site that can generate a SAML assertion for that user. The service provider redirects the authentication request to that central site.
In SAML 1.1, the site that generates the SAML assertion is called the source site. In SAML 2.0, this site is the identity provider. In both SAML versions, this site is sometimes called a SAML Authority.
- The user logs in to the identity provider site, typically via a login web application hosted by that site. The identity provider authenticates the user, and generates a SAML assertion.
- Information about the SAML assertion provided by the identity provider and associated with the user and the desired target is conveyed from the identity provider site to the service provider site by the protocol exchange.
Through a sequence of HTTP exchanges, the user browser is transferred to an Assertion Consumer Service (ACS) at the service provider site. The WebLogic Server SAML identity assertion provider makes up a portion of the ACS.
- The identity assertion provider maps the identity contained in the assertion to a Subject in the local security realm. The access policies on the requested target are evaluated to determine whether the user is authorized for that target. If access is authorized, the user authenticated by the identity provider site is accepted as an authenticated user by the service provider site, thereby achieving Web-based SSO.
For more background information about the OASIS SAML standard, see the following:
- For SAML V1.1, see Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML) V1.1.
- For SAML V2.0, see:
For information about how SSO with web browsers and HTTP clients is implemented in WebLogic Server, see Single Sign-On with the WebLogic Security Framework.
Desktop Clients
SSO with Desktop Clients uses HTTP-based authentication with Microsoft clients that have authenticated in the Windows Active Directory environment. The Windows Active Directory environment uses Kerberos as its security protocol. Kerberos provides network authentication of heterogeneous realms. This means a user logged into a Windows domain can access a Web application running on an application server and use their Windows Active Directory credentials to authenticate to the server. The application server can run on any platform that supports Kerberos.
When a Web server receives a request from a browser it can request that the browser use the Kerberos protocol to authenticate itself. This protocol performs authentication via HTTP, and allows the browser (in most cases, Internet Explorer) to pass a delegated credential to allow a web application to log into subsequent Kerberos-based services on the user's behalf.
When an HTTP server wishes to login a Microsoft client, it returns a 401 Unauthorized response to the HTTP request with the WWW-Authorization:Negotiate header. The browser then contacts the Key Distribution Center (KDC)/Ticket Granting Service (TGS) to obtain a service ticket. It chooses a special Service Principal Name for the ticket request. The returned ticket is then wrapped in a SPNEGO token which is encoded and sent back to the server using an HTTP request. The token is unwrapped and the ticket is authenticated. Once authenticated, the page corresponding to the requested URL is returned.
For information about how SSO with Microsoft clients is implemented in WebLogic Server, see Desktop SSO Process.
Authorization
Authorization is the process whereby the interactions between users and WebLogic resources are controlled, based on user identity or other information. In other words, authorization answers the question, “What can you access?” In WebLogic Server, an Authorization provider is used to limit the interactions between users and WebLogic resources to ensure integrity, confidentiality, and availability.
The following sections describe authorization concepts and functionality:
- WebLogic Resources
- Security Policies
- ContextHandlers
- Access Decisions
- Adjudication
- Java Authorization Contract for Containers (JACC)
WebLogic Resources
A WebLogic resource is a structured object used to represent an underlying WebLogic Server entity, which can be protected from unauthorized access using security roles and security policies.
WebLogic resources are hierarchical. Therefore, the level at which you define these security roles and security policies is up to you. For example, you can define security roles and security policies on: entire enterprise applications (EARs); an Enterprise JavaBean (EJB) JAR containing multiple EJBs; a particular Enterprise JavaBean (EJB) within that JAR; or a single method within that EJB.
WebLogic resource implementations are available for:
- Administrative resources
- Application resources
- Common Object Model (COM) resources
- Enterprise Information System (EIS) resources
- Enterprise JavaBean (EJB) resources
- Java Database Connectivity (JDBC) resources
- Java Messaging Service (JMS) resources
- Java Naming and Directory Interface (JNDI) resources
- Server resources
- Web application resources
- Web Service resources
- Work Context resources
Each of these WebLogic resource implementations is explained in detail in the Javadocs for WebLogic Classes. For more information, see “Types of WebLogic Resources” in Securing WebLogic Resources Using Roles and Policies.
Security Policies
Security policies replace access control lists (ACLs) and answer the question “Who has access to a WebLogic resource?” A security policy is created when you define an association between a WebLogic resource and one or more users, groups, or security roles. You can optionally define date and time constraints for a security policy. A WebLogic resource has no protection until you assign it a security policy.
You assign security policies to any of the defined WebLogic resources (for example, an EJB resource or a JNDI resource) or to attributes or operations of a particular instance of a WebLogic resource (an EJB method or a servlet within a Web application). If you assign a security policy to a type of WebLogic resource, all new instances of that resource inherit that security policy. Security policies assigned to individual resources or attributes override security policies assigned to a type of WebLogic resource. For a list of the defined WebLogic resources, see WebLogic Resources.
Security policies are stored in an Authorization provider's database. By default, the XACML Authorization provider is configured in a domain, and security policies are stored in the embedded LDAP server.
To use a user or group to create a security policy, the user or group must be defined in the security provider database for the Authentication provider that is configured in the default security realm. To use a security role to create a security policy, the security role must be defined in the security provider database for the Role Mapping provider that is configured in the default security realm. By default, the WebLogic Authentication and XACML Role Mapping providers are configured in the database in the embedded LDAP server.
By default, security policies are defined in WebLogic Server for the WebLogic resources. These security policies are based on security roles and default global groups. You also have the option of basing a security policy on a user. Oracle recommends basing security policies on security roles rather than users or groups. Basing security policies on security roles allows you to manage access based on a security role that a user or group is granted, which is a more efficient method of management. For a listing of the default security policies for the WebLogic resources, see “Default Security Policies” in Securing WebLogic Resources Using Roles and Policies.
ContextHandlers
A ContextHandler is a high-performing WebLogic class that obtains additional context and container-specific information from the resource container, and provides that information to security providers making access or role mapping decisions. The ContextHandler interface provides a way for an internal WebLogic resource container to pass additional information to a WebLogic Security Framework call, so that a security provider can obtain contextual information beyond what is provided by the arguments to a particular method. A ContextHandler is essentially a name/value list and as such, it requires that a security provider know what names to look for. (In other words, use of a ContextHandler requires close cooperation between the WebLogic resource container and the security provider.) Each name/value pair in a ContextHandler is known as a context element, and is represented by a ContextElement object.
Currently, three types of WebLogic resource containers pass ContextHandlers to the WebLogic Security Framework: the Servlet, EJB, and Web Service containers. Thus, URL (Web), EJB, and Web Service resource types have different context elements whose values Adjudication, Identity Assertion, Authorization credential mapping, and Role Mapping providers and the LoginModules used by an Authentication provider can inspect. An implementation of the AuditContext interface (used when a security provider is implemented to post audit events) may also examine the values of context elements.
For more information about the values of particular context elements, see ContextHandlers and WebLogic Resources in Developing security providers for WebLogic Server.
Access Decisions
Like LoginModules for Authentication providers, an Access Decision is the component of an Authorization provider that actually answers the “is access allowed?” question. Specifically, an Access Decision is asked whether a subject has permission to perform a given operation on a WebLogic resource, with specific parameters in an application. Given this information, the Access Decision responds with a result of PERMIT, DENY, or ABSTAIN.
Adjudication
Adjudication involves resolving any authorization conflicts that may occur when more than one Authorization provider is configured in a security realm, by weighing the result of each Authorization provider's Access Decision. In WebLogic Server, an Adjudication provider is used to tally the results that multiple Access Decisions return, and determines the final PERMIT or DENY decision. An Adjudication provider may also specify what should be done when an answer of ABSTAIN is returned from a single Authorization provider's Access Decision.
Identity and Trust
Private keys, digital certificates, and trusted certificate authority certificates establish and verify identity and trust in the WebLogic Server environment.
The public key is embedded into a digital certificate. A private key and digital certificate provide identity. The trusted certificate authority (CA) certificate establishes trust for a certificate. Certificates and certificate chains need to be validated before a trust relationship is established.
This topic details the concepts associated with identity and trust. For more information, see:
Private Keys
WebLogic Server uses public key encryption technology for authentication. With public key encryption, a public key and a private key are generated for a server. The keys are related such that data encrypted with the public key can only be decrypted using the corresponding private key and vice versa. The private key is carefully protected so that only the owner can decrypt messages that were encrypted using the public key.
Digital Certificates
Digital certificates are electronic documents used to verify the unique identities of principals and entities over networks such as the Internet. A digital certificate securely binds the identity of a user or entity, as verified by a trusted third party (known as a certificate authority), to a particular public key. The combination of the public key and the private key provides a unique identity to the owner of the digital certificate.
Digital certificates enable verification of the claim that a specific public key does in fact belong to a specific user or entity. A recipient of a digital certificate can use the public key in a digital certificate to verify that a digital signature was created with the corresponding private key. If such verification is successful, this chain of reasoning provides assurance that the corresponding private key is held by the subject named in the digital certificate, and that the digital signature was created by that subject.
A digital certificate typically includes a variety of information, such as the following:
- The name of the subject (holder, owner) and other information required to confirm the unique identity of the subject, such as the URL of the Web server using the digital certificate, or an individual's e-mail address
- The subject's public key
- The name of the certificate authority that issued the digital certificate
- A serial number
- The validity period (or lifetime) of the digital certificate (defined by a start date and an end date)
The most widely accepted format for digital certificates is defined by the ITU-T X.509 international standard. Digital certificates can be read or written by any application complying with the X.509 standard. The public key infrastructure (PKI) in WebLogic Server recognizes digital certificates that comply with X.509 version 3, or X.509v3. Oracle recommends obtaining digital certificates from a certificate authority such as Verisign or Entrust.
For more information, see “Configuring SSL” in Securing WebLogic Server.
Certificate Authorities
Digital certificates are issued by certificate authorities. Any trusted, third-party organization or company that is willing to vouch for the identities of those to whom it issues digital certificates and public keys can be a certificate authority. When a certificate authority creates a digital certificate, the certificate authority signs it with its private key, to ensure that any tampering will be detected. The certificate authority then returns the signed digital certificate to the requesting party.
The requesting party can verify the signature of the issuing certificate authority by using the public key of the certificate authority. The certificate authority makes its public key available by providing a certificate issued from a higher-level certificate authority attesting to the validity of the public key of the lower-level certificate authority. This scheme gives rise to hierarchies of certificate authorities. This hierarchy is terminated by a top-level, self-signed certificate known as the root certificate, because no other public key is needed to certify it. Root certificates are issued by trusted (root) Certificate Authorities.
If the recipient has a digital certificate containing the public key of the certificate authority signed by a superior certificate authority who the recipient already trusts, the recipient of an encrypted message can develop trust in the public key of a certificate authority recursively. In this sense, a digital certificate is a stepping stone in digital trust. Ultimately, it is necessary to trust only the public keys of a small number of top-level certificate authorities. Through a chain of certificates, trust in a large number of users' digital signatures can be established.
Thus, digital signatures establish the identities of communicating entities, but a digital signature can be trusted only to the extent that the public key for verifying it can be trusted.
For more information, see “Configuring SSL” in Securing WebLogic Server.
Certificate Lookup and Validation
Applications that rely on public key technology for security must be confident that a user's public key is genuine. A user may have a chain of certificates which recursively point to the trusted CA that issued the initial certificate (referred to as the end certificate). A certificate chain must be validated before it can be used to establish trust. In addition, a user may not have a complete chain from a trusted CA to the target certificate. Completing a valid chain of certificates from the target certificate to the trusted CA is another requirement for public key technology.
In WebLogic Server, certificate validation is performed by the Certificate Lookup and Validation (CLV) framework which completes and validates X.509 certificate chains for inbound 2-way SSL, outbound SSL, application code, and WebLogic Web services. The CLV framework receives a certificate or certificate chain, completes the chain (if necessary), and lookups and validates the certificate in the certificate chain. The framework can use the end certificate, the Subject DN, the Issuer DN plus serial number, the subject key identifier and/or X.509 thumbprint to find and validate a certificate chain. In addition, the framework can perform additional validation on the certificate chain such as revocation checking.
The CLV framework is based on the JDK architecture and plug-in framework for locating and validating certificate chains. The CLV providers were built using the JDK CertPath Builder and CertPath Validator API/SPI.
Secure Sockets Layer (SSL)
SSL enables secure communication between applications connected through the Web. For a discussion of the components of SSL communication and why each component is necessary, see How SSL Works, published by the Netscape Communications Corporation.
This release of WebLogic Server uses the Certicom SSLPlus Java version 4.0 SSL implementation. The RSA Cert-J and Crypto-J have been upgraded to Cert-J version 2.1.1 and Crypto-J version 3.5.
WebLogic Server fully supports SSL communication. By default, WebLogic Server is configured for one-way SSL authentication, however, the SSL port is disabled. Using the Administration Console, you can configure WebLogic Server for two-way SSL authentication.
- To use one-way SSL from a client to a server: enable the SSL port on the server, configure identity for the server and trust for the client.
- To use two-way SSL between a client and a server: enable two-way SSL on the server, configure trust for the server, and identity for the server.
In either case, the trusted CA certificates need to include the trusted CA certificate that issued the peer's identity certificate. This certificate does not necessarily have to be the root CA certificate.
To acquire a digital certificate for your server, you generate a public key, private key, and a Certificate Signature Request (CSR), which contains your public key. You send the CSR request to a certificate authority and follow their procedures for obtaining a signed digital certificate.
Once you have your private keys, digital certificates, and any additional trusted CA certificates that you may need, you need to store them so that WebLogic Server can use them to verify identity. Store private keys and certificates in keystores.
For purposes of backwards compatibility, you may also store your private keys and certificates in files. For more information about private key, public key, and certificate requirements and procedures, see Configuring SSL and Securing WebLogic Server.
To use SSL when connecting to a WebLogic server application with your browser, you simply specify HTTPS and the secure port (port number 7002) in the URL. For example:
https://localhost:7002/examplesWebApp/SnoopServlet.jsp
Where localhost is the name of the system hosting the Web application.
The following topics are discussed in this section:
- SSL Features
- SSL Tunneling
- One-way/Two-way SSL Authentication
- Host Name Verification
- Trust Managers
- Asymmetric Key Algorithms
- Symmetric Key Algorithms
- Message Digest Algorithms
- Cipher Suites
SSL Features
WebLogic Server provides a pure-Java implementation of SSL. Generally, SSL provides the following:
- A mechanism that the communicating applications can use to authenticate each other's identity.
- Encryption of the data exchanged by the applications.
When SSL is used, the target (the server) always authenticates itself to the initiator (the client). Optionally, if the target requests it, the initiator can authenticate itself to the target. Encryption makes data transmitted over the network intelligible only to the intended recipient. An SSL connection begins with a handshake during which the applications exchange digital certificates, agree on the encryption algorithms to be used, and generate the encryption keys to be used for the remainder of the session.
SSL provides the following security features:
- Server authentication—WebLogic Server uses its digital certificate, issued by a trusted certificate authority, to authenticate to clients. SSL minimally requires the server to authenticate to the client using its digital certificate. If the client is not required to present a digital certificate, the connection type is called one-way SSL authentication.
- Client Identity Verification—Optionally, clients might be required to present their digital certificates to WebLogic Server. WebLogic Server then verifies that the digital certificate was issued by a trusted certificate authority and establishes the SSL connection. An SSL connection is not established if the digital certificate is not presented and verified. This type of connection is called two-way SSL authentication, a form of mutual authentication.
- Confidentiality—All client requests and server responses are encrypted to maintain the confidentiality of data exchanged over the network.
- Data Integrity—Each SSL message contains a message digest computed from the original data. On the receiving end, a new digest is computed from the de-crypted data and then compared with the digest that came with the message. If the data is altered, the digests don't match and tampering is detected.
- Data that flows between a client and WebLogic Server is protected from tampering by a third-party validation of user identities.
If you are using a Web browser to communicate with WebLogic Server, you can use the Hyper-Text Transfer Protocol with SSL (HTTPS) to secure network communications.
SSL Tunneling
WebLogic Server tunnels the HTTP, T3, and IIOP protocols over SSL. SSL can be used by Web browsers and Java clients as follows:
- A Web browser makes a SSL connection to a server over https. The browser then sends HTTP requests and receives HTTP responses over this SSL connection. For example:
https://myserver.com/mypage.html
WebLogic Server supports SSL versioning which means it can communicate with any clients over this protocol including Web browsers.
- Java clients using HTTP/T3 protocols are tunnelled over SSL. For example:
t3s://myserver.com:7002/mypage.html
Java clients running in WebLogic Server can establish either T3S connections to other WebLogic Servers, or HTTPS connections to other servers that support SSL, such as Web servers or secure proxy servers.
One-way/Two-way SSL Authentication
WebLogic Server supports one-way and two-way SSL authentication.With one-way SSL authentication, the target (the server) is required to present a digital certificate to the initiator (the client) to prove its identity. The client performs two checks to validate the digital certificate:
- The client verifies that the certificate is trusted (meaning, it was issued by the client's trusted CA), is valid (not expired), and satisfies the other certificate constraints.
- The client checks that the certificate Subject's common name (CN) field value matches the host name of the server to which the client is trying to connect
If both of the above checks return true, the SSL connection is established.
With two-way SSL authentication, both the client and the server must present digital certificates before the SSL connection is enabled between the two. Thus, in this case, WebLogic Server not only authenticates itself to the client (which is the minimum requirement for certificate authentication), but it also requires authentication from the requesting client. Two-way SSL authentication is useful when restrict access to trusted clients only.
Figure 3-3 illustrates WebLogic Server SSL connections and shows which connections support one-way SSL, two-way SSL, or both. The Web browser client, Web Server, Fat client, Web Services client, and SSL server connections can be configured for either one-way or two-way SSL. WebLogic Server determines whether an SSL connection is configured for one-way or two-way. Use the Administration Console to configure SSL. Figure 3-3 How WebLogic Server Supports SSL Connections
Host Name Verification
Host Name verification is the process of verifying that the name of the host to which an SSL connection is made is the intended or authorized party. Host name verification prevents man-in-the-middle attacks when a Web client (a Web browser, a WebLogic client, or a WebLogic Server acting as a client) requests an SSL connection to another application server.
By default, the SSL client, as a function of the SSL handshake, compares the common name in the SubjectDN of the SSL server's digital certificate with the host name of the SSL server to which it is trying to connect. If these names do not match, the SSL connection is dropped.
Trust Managers
The Trust Manager provides a way to override the default SSL trust validation rules. It allows the server to decide whether or not it trusts the client that is contacting it. Using a Trust Manager you can perform custom checks before continuing an SSL connection. For example, you can use the Trust Manager to specify that only users from specific localities, such as towns, states, or countries, or users with other special attributes, can gain access via the SSL connection.
WebLogic Server provides the weblogic.security.SSL.TrustManager interface. This interface allows custom Trust Manager implementations to be called during the SSL handshake. The custom implementation can override the handshake error detected by the SSL implementation validation check or raise an error based on its own certification rules.
WebLogic Server also provides the weblogic.security.SSL.CertPath.TrustManager interface which application and custom code can use to control if outbound SSL uses certificate lookup and validation.
This interface replaces the weblogic.security.SSL.TrustManagerJSSE interface, which is deprecated in this release of WebLogic Server.
Asymmetric Key Algorithms
Asymmetric key (also referred to as public key) algorithms are implemented through a pair of different, but mathematically related keys: a public key and a private key.
- The public key (which is distributed widely) is used for verifying a digital signature or transforming data into a seemingly unintelligible form.
- The private key (which is always kept secret) is used for creating a digital signature or returning the data to its original form.
The Public Key Infrastructure (PKI) in WebLogic Server also supports digital signature algorithms. Digital signature algorithms are simply public key algorithms used to generate digital signatures.
WebLogic Server supports the Rivest, Shamir, and Adelman (RSA) algorithm.
Symmetric Key Algorithms
With symmetric key algorithms, you use the same key to encrypt and decrypt a message. This common key encryption system uses a symmetric key algorithm to encrypt a message sent between two communicating entities. Symmetric cryptography tends to be relatively fast compared to asymmetric cryptography.
A block cipher is a type of symmetric key algorithm that transforms a fixed-length block of plain text (unencrypted text) data into a block of cipher text (encrypted text) data of the same length. This transformation takes place in accordance with the value of a randomly generated session key. The fixed length is called the block size.
The PKI in WebLogic Server supports the following symmetric key algorithms:
- DES-CBC (Data Encryption Standard for Cipher Block Chaining)
DES-CBC is a 64-bit block cipher run in Cipher Block Chaining (CBC) mode. It provides 56-bit keys. (8 parity bits are stripped from the full 64-bit key.)
- Two-key triple-DES (Data Encryption Standard)
Two-key triple-DES is a 128-bit block cipher run in Encrypt-Decrypt-Encrypt (EDE) mode. Two-key triple-DES provides two 56-bit keys (in effect, a 112-bit key).
For some time it has been common practice to protect and transport a key for DES encryption with triple-DES, which means that the input data (in this case the single-DES key) is encrypted, decrypted, and then encrypted again (an encrypt-decrypt-encrypt process). The same key is used for the two encryption operations.
- RC4 (Rivest's Cipher 4)
RC4 is a variable key-size block cipher with a key size range of 40 to 128 bits. It is faster than DES.
WebLogic Server users cannot expand or modify this list of algorithms.
Message Digest Algorithms
WebLogic Server supports the MD5 and SHA (Secure Hash Algorithm) message digest algorithms. Both MD5 and SHA are well known, one-way hash algorithms. A one-way hash algorithm takes a message and converts it into a fixed string of digits, which is referred to as a message digest or hash value.
MD5 is a high-speed, 128-bit hash; it is intended for use with 32-bit machines. SHA offers more security by using a 160-bit hash, but is slower than MD5.
Cipher Suites
A cipher suite is an SSL encryption method that includes the key exchange algorithm, the symmetric encryption algorithm, and the secure hash algorithm. A cipher suite is used to protect the integrity of a communication. For example, the cipher suite called RSA_WITH_RC4_128_MD5 uses RSA for key exchange, RC4 with a 128-bit key for bulk encryption, and MD5 for message digest.
Check the validation lists at http://csrc.nist.gov/cryptval/ for FIPS140 validation status.
WebLogic Server supports the RSA cipher suites described in Table 3-2.
Firewalls
A firewall limits traffic between two networks. Firewalls can be a combination of software and hardware, including routers and dedicated gateway machines. They employ filters that allow or disallow traffic to pass based on the protocol, the service requested, routing information, and the origin and destination hosts or networks. They may also allow access for authenticated users.
Figure 3-4 illustrates a typical setup with a firewall that filters traffic destined for a WebLogic Server cluster. Figure 3-4 Typical Firewall Setup
You can use the following features in WebLogic Server in conjunction with firewalls:
Connection Filters
You can use WebLogic Server connection filters to set up firewalls that filter network traffic based on protocols, IP addresses, and DNS node names. For more information, see “Using Network Connection Filters” in Programming WebLogic Security.
Perimeter Authentication
You can use identity assertion providers to set up perimeter authentication—a special type of authentication using tokens. The WebLogic Server security architecture supports identity assertion providers that perform perimeter-based authentication (Web server, firewall, VPN) and handle multiple security token types/protocols (SOAP, SAML, SPNEGO, IIOP-CSIv2).
J2EE and WebLogic Security
For implementation and use of user authentication and authorization, WebLogic Server utilizes the security services of the SDK version J2SE 5.0. Like the other J2EE components, the security services are based on standardized, modular components. WebLogic Server implements these Java security service methods according to the standard, and adds extensions that handle many details of application behavior automatically, without requiring additional programming.
WebLogic Server's support for J2SE 5.0 security means that application developers can take advantage of Sun Microsystems' latest enhancements and developments in the area of security, thus leveraging a company's investment in Java programming expertise. By following the defined and documented Java standard, WebLogic Server's security support has a common baseline for Java developers. The innovations that WebLogic Server provides rest on the baseline support for J2SE 5.0.
The following topics are discussed in this section:
J2SE 5.0 Security Packages
WebLogic Server is compliant with and supports the following J2SE 5.0 security packages:
- The Java Secure Socket Extension (JSSE)
- Java Authentication and Authorization Services (JAAS)
- The Java Security Manager
- Java Cryptography Architecture and Java Cryptography Extensions (JCE)
- Java Authorization Contract for Containers (JACC)
The Java Secure Socket Extension (JSSE)
JSSE is a set of packages that support and implement the SSL and TLS v1 protocol, making those protocols and capabilities programmatically available. WebLogic Server provides Secure Sockets Layer (SSL) support for encrypting data transmitted across WebLogic Server clients, as well as other servers.
While JSSE provides a core set of classes for SSL functions, other companies, such as Certicom, provide extensions to those classes. WebLogic Server uses the Certicom JSSE extensions in its implementation of SSL.
Java Authentication and Authorization Services (JAAS)
JAAS is a set of packages that provide a framework for user-based authentication and access control. WebLogic Server uses only the authentication classes of JAAS.
JAAS is used as follows:
- For remote Java client authentication
- For authentication internally in instances of WebLogic Server in the Web and EJB containers and in the WebLogic Authentication and identity assertion providers.
For more information on JAAS, see Java Authentication and Authorization Service (JAAS).
The Java Security Manager
Developed by Sun Microsystems, Inc., the Java Security Manager is the security manager for the Java Virtual Machine (JVM). The security manager works with the Java API to define security boundaries through the java.lang.SecurityManager class. The SecurityManager class enables programmers to establish a custom security policy for their Java applications.
The Java Security Manager can be used with WebLogic Server to provide additional protection for WebLogic resources running in the JVM. Use of the Java Security Manager to protect WebLogic resources in WebLogic Server is an optional security step.
You can use the Java Security Manager to perform the following security tasks to protect WebLogic resources:
- Modify the weblogic.policy file for general use.
- Set application-type security policies on EJBs and Resource Adapters.
You use the Java security policy file to perform this task.
- Set application-specific security policies on specific EJBs and Resource Adapters.
You use the deployment descriptors (weblogic.xml, weblogic-ejb-jar.xml, and rar.xml) to perform this task.
For more information on how to use the Java Security Manager to perform these tasks, see Using the Java Security Manager to Protect WebLogic Resources in Programming WebLogic Security.
Java Cryptography Architecture and Java Cryptography Extensions (JCE)
Developed by Sun Microsystems, Inc., these security APIs provide a framework for accessing and developing cryptographic functionality for the Java platform and developing implementations for encryption, key generation and key agreement, and Message Authentication Code (MAC) algorithms.
WebLogic Server fully supports these security APIs.
Java Authorization Contract for Containers (JACC)
JACC provides an alternate authorization mechanism for the EJB and Servlet containers in a WebLogic Server domain. When JACC is configured, the WebLogic Security Framework access decisions, adjudication, and role mapping functions are not used for EJB and Servlet authorization decisions. The JACC classes are used for role-to-principal mapping as well as for rendering access decisions. You cannot use the JACC framework in conjunction with the WebLogic Security Framework. The JACC classes used by WebLogic Server do not include an implementation of a Policy object for rendering decisions but instead rely on the J2SE 1.4 java.security.Policy object.
Common Secure Interoperability Version 2 (CSIv2)
WebLogic Server provides support for the Enterprise JavaBean (EJB) interoperability protocol that is based on Internet Inter-ORB (IIOP) (GIOP version 1.2) and the CORBA Common Secure Interoperability version 2 (CSIv2) specification. CSIv2 support in WebLogic Server:
- Interoperates with the Java 2 Enterprise Edition (J2EE) version 1.4.1 reference implementation.
- Allows WebLogic Server IIOP clients to specify a username and password in the same manner as T3 clients.
- Supports Generic Security Services Application Programming Interface (GSSAPI) initial context tokens. For this release, only usernames and passwords and GSSUP (Generic Security Services Username Password) tokens are supported.
The CSIv2 implementation in WebLogic Server passed Java 2 Enterprise Edition (J2EE) Compatibility Test Suite (CTS) conformance testing.
The external interface to the CSIv2 implementation is a JAAS LoginModule that retrieves the username and password of the CORBA object. The JAAS LoginModule can be used in a WebLogic Java client or in a WebLogic Server instance that acts as a client to another J2EE application server. The JAAS LoginModule for the CSIv2 support is called UsernamePasswordLoginModule, and is located in the weblogic.security.auth.login package.
For information related to load balancing support for CSIv2 in a WebLogic Server cluster, see
“Server Affinity and IIOP Client Authentication Using CSIv2” in Using WebLogic Server Clusters.