Security Fundamentals

The following sections describe security fundamentals as they relate to WebLogic Server security:

For implementation and use of user authentication and authorization, BEA WebLogic Server utilizes the security services of the SDK version 1.3 for the Java 2 Platform, Enterprise Edition (J2EE). Like the other J2EE components, the security services are based on standardized, modular components. BEA 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.

BEA WebLogic Server's support for SDK 1.3 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 SDK 1.3.

WebLogic Server is compliant with and supports the following SDK 1.3 security packages:

JSSE is a set of packages that support and implement the SSL and TLS v1 protocol, making those protocols and capabilities programmatically available. BEA WebLogic Server provides Secure Sockets Layer (SSL) support for encrypting data transmitted across WebLogic Server clients, and other servers.

JAAS is a set of packages that provide a framework for user-based authentication and access control. BEA WebLogic Server uses only the authentication classes of JAAS.

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 resources running in the Java Virtual Machine. Use of the Java Security Manager to protect resources in WebLogic Server is optional.

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.

The Java Cryptography Architecture and JCE have been integrated into the Java 2 SDK, Standard Edition, v 1.4.

In this release of WebLogic Server, a security realm comprises mechanisms for protecting WebLogic resources. Each security realm consists of a set of configured security providers, users, groups, roles, and security policies. A user must be defined in a security realm in order to access any WebLogic resources belonging to that realm. When a user attempts to access a particular WebLogic resource, WebLogic Server tries to authenticate and authorize the user by checking the role assigned to the user in the relevant realm and the security policy of the particular WebLogic resource.

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 that 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 provider concepts and functionality.

Users are entities that can be authenticated in a security realm (such as myrealm). A user can be a person, such as application end user, or a software entity, such as client application and other instances of WebLogic Server. As a result of authentication, a user assigned an identity, or principal. Each user is given a unique identity within the security realm. Users may be placed into groups that are associated with roles, or be directly associated with roles.

When users want to access WebLogic Server, they present proof material (for example, a password or a digital certificate) typically through a JAAS LoginModule to the Authentication providers configured in the security realm. If WebLogic Server can verify the identity of the user based on that username and credential, WebLogic Server associates the principal assigned to the user with a thread that executes code on behalf of the user. Before the thread begins executing code, however, WebLogic Server checks security policy of the resource and the user's principal that the user has been assigned to make sure that the user has the required permissions to continue.

When defining a user in WebLogic Server, you also define a password for that user. WebLogic Server hashes all passwords. When WebLogic Server receives a client request, the password presented by the client is hashed and WebLogic Server compares it to the already hashed password for matching.

Groups are logically ordered sets of users. Managing groups is more efficient than managing large numbers of users individually. For example, an administrator can specify permissions for 50 users at one time by defining a security policy for a resource and assigning a role, or access privilege, to a group. Usually, group members have something in common. For example, a company may separate its sales staff into two groups, Sales Representatives and Sales Managers, because staff members would logically have different levels of access to WebLogic Server resources depending on their job functions.

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 like WebLogic Server. The Java Authentication and Authorization Service (JAAS) requires that subjects be used as containers for authentication information, including principals.

Note: In this release of WebLogic Server, subjects replace WebLogic Server 6.x users.

Figure 2-2 illustrates the 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.

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.

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 reside in 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 end 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.

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 a another Authentication provider's LoginModule to add a principal of a type other than WLSUser with the name "Joseph".

If a security realm has multiple Authentication providers configured, the Control Flag attribute on the Authenticator-->General tab of the Administration Console determines the ordered execution of the Authentication providers. The values for the Control Flag attribute are as follows:

When used with a LoginModule, Identity Assertion providers support single sign-on. For example, an Identity Assertion provider can generate a token from a digital certificate, and that token can be passed around the system so that users are not asked to sign on more than once.

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.

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 you or an administrator 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.

With mutual authentication, both the client and the server are required to authenticate themselves to each other. This can be done using by means of certificates or other forms of proof material. WebLogic Server supports two-way SSL authentication, which is a form of mutual authentication. For more information, see One-way/Two-way SSL Authentication.

WebLogic Server users must be authenticated whenever they request access to a protected WebLogic Server resource. For this reason, each user is required to provide a credential (a username/password pair or a digital certificate) to WebLogic Server. The following types of authentication are supported by default by the WebLogic security providers that are included in the WebLogic Server distribution:

WebLogic Server can use the WebLogic security providers that are provided as part of the WebLogic Server product or Custom security providers to perform the different types of authentication. For information on WebLogic security providers and how to configure authentication, see "The WebLogic Security Providers" on page 3-7 and the following sections in Managing WebLogic Security:

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 resource.

The SSL (or HTTPS) protocol can be used to provide an additional level of security to password authentication. Because the SSL protocol 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.

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.

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. In this case, WebLogic Server not only authenticates itself to the client (which is the minimum requirement for certificate authentication), it also requires authentication from the requesting client. Clients are required to submit digital certificates issued by a trusted certificate authority. Two-way SSL authentication is useful when you must restrict access to trusted clients only. For example, you might restrict access by accepting only clients with digital certificates provided by you.

Note: Two-way SSL authentication is supported by the WebLogic security providers that are provided as part of the WebLogic Server product.

Perimeter authentication is the process of authenticating the identity of a remote user outside of the application server.

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," 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.

WebLogic Server is designed to extend the single sign-on concept all the way to the perimeter through support for identity assertion. 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 Checkpoint's OPSEC, the emerging Security Assertion Markup Language (SAML), or enhancements to protocols such as Common Secure Interoperability (CSI) v2 to achieve this functionality.

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.

WebLogic Server provides a rich single sign-on environment on which enterprise applications can be built. The single sign-on capabilities reach far beyond those of any other J2EE application server to address the issues found in today's enterprise environments. The WebLogic Security Framework allows the single sign-on capabilities to be integrated with the best-of-breed security vendors and allows for customization to meet an enterprise's ever-changing needs.

The embedded LDAP server is used to store user, group, security roles, and security policies for the WebLogic security providers. It is a complete LDAP server. You can use LDAP to access and modify entries in the LDAP server. The embedded LDAP connection allows the WebLogic security providers to read and write LDAP information from and to the server. You can use an LDAP Browser to import and export various information into and from the server. WebLogic Server does not support adding attributes to the embedded LDAP server.

Note: Question to Reviewers: Will we add LDAP import and export to the console in the Olympic release?

Note: Reminder: Refer to the TOIs for the various default providers. They describe how the security information such as users, groups, roles, and policies are stored in the LDAP server.

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 provider concepts and functionality:

A WebLogic resource is a structured object used to represent an underlying WebLogic Server entity that can be protected from unauthorized access. The level of granularity for WebLogic resources is up to you. For example, you can consider an entire Web application, a particular Enterprise JavaBean (EJB) within that Web application, or a single method within that EJB to be a WebLogic resource.

Note: WebLogic resources replace WebLogic Server 6.x access control lists (ACLs).

Roles are an abstract, logical collections of users similar to a group. The difference between groups and roles is a group is a static identity that a system administrator assigns, while membership in a role is dynamically calculated based on data such as username, group membership, or the time of day. Roles are granted to individual users or to groups. For more efficient management, BEA recommends granting roles to groups rather than to individual users. Once you create a role, you define an association between the role and a WebLogic resource. This association (called a security policy) specifies who has what access to the WebLogic resource.

In WebLogic Server 6.x, roles were used to protect EJBs and Web applications only. In this release of WebLogic Server, roles are expanded to protect all of the defined WebLogic Server resources. For a list of the defined WebLogic resources, see WebLogic Resources.

Multiple roles (either scoped or global) can be applied to a WebLogic resource. Both scoped and global roles are stored in the default Role Mapping provider. To use a role to create a security policy for a WebLogic resource, the role must be in the Role Mapping provider configured in the default security realm. By default, the WebLogic Role Mapping provider is the configured Role Mapping provider.

In the previous release of WebLogic Server, ACLs were used to protect WebLogic resources. In in this release of WebLogic Server, security policies replace 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 roles. You can optionally define a time constraint 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 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 resource. For a list of the defined WebLogic resources, see WebLogic Resources.

Security policies are stored in an Authorization provider. By default, the WebLogic Authorization provider is configured 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 Authentication provider configured in the default security realm. To use a role to create a security policy, the role must be defined in the Role Mapping provider configured in the default security realm. By default, the WebLogic Authentication and Role Mapping providers are configured.

By default, security policies are defined in WebLogic Server for the WebLogic resources. These security policies are based on roles and groups. You also have the option of basing a security policy on a user. BEA recommends basing security policies on roles rather than users or groups. Basing security policies on roles allows you to manage access based on a role 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 Managing WebLogic Security.

A ContextHandler is a high-performing WebLogic class that allows a variable number of arguments to be passed as strings to a method.

The ContextHandler interface provides a way for an internal WebLogic container to pass additional information to a WebLogic Security Framework call, so that a security provider can obtain additional context 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 a security provider to know what names to look for (that is, use of a ContextHandler requires close cooperation between the WebLogic container and a security provider). The name/value list is also called a context element, and is represented by a ContextElement object.

For example, a ContextHandler argument is passed into the isAccessAllowed method of an Access Decision. As another example, if one was attempting to access a file in a directory, the name of that file could be passed through a ContextHandler object.

The Role Mapping providers use the ContextHandler to request various pieces of information about the request. They construct a set of Callback objects that represent the type of information being requested. This set of Callback objects is then passed as an array to the ContextHandler using the handle method.

The Role Mapping providers use the values contained in the Callback objects, the subject, and the resource to compute a list of roles to which the subject making the request is entitled, and pass the list of applicable roles back to the WebLogic Security Framework.

The Authorization providers' Access Decisions also use the ContextHandler to request various pieces of information about the request. They too construct a set of Callback objects that represent the type of information being requested. This set of Callback objects is then passed as an array to the ContextHandler using the handle method.

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 involves resolving any authorization conflicts that may occur when more than one Authorization provider is configured, 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.

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 Server Framework will call through to an Auditing provider before and after security operations (such as authentication or authorization) have been performed, enabling audit event recording. 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 back-end, database, and a simple file.

SSL offers security to applications connected through a network. WebLogic Server fully supports SSL communication. By default, WebLogic Server is configured for one-way SSL authentication. Using the Administration Console, you can configure WebLogic Server for two-way SSL authentication.

To use SSL when connecting to WebLogic server application with your browser, you simply specify HTTPS and the secure port (port number 7002) in the URL. For example:

When the 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.

If you are using a Web browser to communicate with WebLogic Server, you can use the Hypertext Transfer Protocol with SSL (HTTPS) to secure network communications.

SSL is tunneled over an IP-based protocol. Tunneling means that each SSL record is encapsulated and packaged with the headers needed to send the record over another protocol. The use of SSL is signified in the protocol scheme of the URL used to specify the location of WebLogic Server.

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 then verifies the digital certificate and an SSL authentication connection is established.

With two-way SSL authentication, both the client and server must present digital certificates before the connection thread is enabled between the two. 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 you must restrict access to trusted clients only.

The standard WebLogic Server distribution supports exportable-strength SSL only. The domestic version is available, by request only from your BEA sales representative. Because the United States Government relaxed restrictions on exporting encryption software in early 2000, the domestic version of WebLogic Server can be used in most countries.

During installation, you are prompted to choose which strength of the SSL protocol you want to use.We recommend the domestic WebLogic Server distribution because it allows stronger encryption. If you generate a Certificate Signature Request (CSR) using the exportable WebLogic Server distribution, you cannot support high-strength connections and you cannot authenticate clients that present domestic-strength certificates.

The implementation of the SSL protocol provided by WebLogic Server is a pure-Java implementation.

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 allow 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 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. We recommend obtaining digital certificates from a certificate authority such as Verisign or Entrust.

Digital certificates are issued by a certificate authority. 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 subject.

The subject 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 digital 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 digital 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 (CAs).

The recipient of an encrypted message can develop trust in the private key of a certificate authority recursively, 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. 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 digital 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.

Asymmetric key (also so referred to a public key) algorithms are implemented through a pair of different, but mathematically related keys: a public key and a private key.

The Public Key Infrastructures (PKI) in WebLogic Server also support digital signature algorithms. Digital signature algorithms are simply public key algorithms used to generate digital signatures.

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 key encryption operates at least 1000 times faster than public key 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.

Note: WebLogic Server users cannot expand or modify this list of 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.

A cipher suite is an SSL encryption method that includes the key exchange algorithm, the symmetric encryption algorithm, and the secure hash algorithm 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.

Table 2-1 SSL Cipher Suites Supported by WebLogic Server

Cipher Suite	Symmetric Key Strength
TLS_RSA_WITH_RC4_128_SHA	128
TLS_RSA_WITH_RC4_128_MD5	128
TLS_RSA_WITH_DES_CBC_SHA	56
TLS_RSA_EXPORT_WITH_RC4_40_MD5	40
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA	40
TLS_RSA_WITH_3DES_EDE_CBC_SHA	112
TLS_RSA_WITH_NULL_SHA	0
TLS_RSA_WITH_NULL_MD5	0
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA	56
TLS_RSA_EXPORT124_WITH_RC4_56_SHA	56

The license for WebLogic Server determines what strength (either domestic or export) of cipher suite is used to protect communications. If the cipher suite strength defined in the config.xml file exceeds the strength specified by the license, the server uses the strength specified by the license. For example, if you have an export strength license but you define the use of an domestic strength cipher suite in the config.xml file, the server rejects the domestic strength cipher suite and uses the export strength cipher suite.

Security policies allow you to secure WebLogic Server resources using some characteristic of a user. However, you can add an additional layer of security by using connection filters to filter network connections. For example, you can deny any non-SSL connections originating outside of your corporate network.

Security providers are modules that "plug into" a WebLogic Server security realm to provide security services to applications. You can use the security providers that are provided as part of the WebLogic Server product, purchase custom security providers from third-party security vendors, or develop your own custom security providers. For information on how to develop custom security providers, see Developing Security Providers for WebLogic Server.

The security plug-in scheme in BEA WebLogic Server is based on a set of Security Service Provider Interfaces (SSPIs) for the plug-in points. The SSPIs can be used by BEA administrators, customers, or third-party vendors to develop security plug-ins for the WebLogic Server environment. SSPIs are available for Authentication, Authorization, Auditing, Credential mapping, Role mapping, and Keystore.

The SSPI scheme means that customers have four choices for securing WebLogic Server resources:

A required task for developing a custom security provider is to generate an MBean type for the custom security provider to be developed. The term MBean is short for managed bean, a Java object that represents a Java Management eXtensions (JMX) manageable resource.

Note: JMX is a specification created by Sun Microsystems that defines a standard management architecture, APIs, and management services. For more information, see the Java Management Extensions White Paper.

An MBean type is a factory for instances of MBeans. You use MBean interfaces called SSPI MBeans to create MBean types. There are two types of SSPI MBeans you can use to create an MBean type for a custom security provider:

Once you have created the MBean types, you can use the Administration Console to create instances of MBeans. After you have created the MBean instances, you can use them, via the Administration Console, to configure and manage the custom security provider.

The following sections explain what a security provider database is and describe how security realms affect the use of security provider databases:

A security provider database contains the users, groups, policies, roles, and credentials used by some types of security providers to provide security services. For example: an Authentication provider requires information about users and groups; an Authorization provider requires information about security policies; a Role Mapping provider requires information about roles, and a Credential Mapping provider requires information about credentials. These security providers need this information to be available in a database in order to function properly.

The security provider database can be the embedded LDAP server (as used by the WebLogic security providers), a properties file (as used by the sample security providers), or a production-quality, customer-supplied database that you may already be using.

Note: The sample security providers are available under "Code Direct" on the dev2dev Web site.

The security provider database should be initialized the first time security providers are used. This initialization can be done:

At minimum, you must initialize a security provider database with the default users, groups, policies, roles, or credentials that your Authentication, Authorization, Role Mapping, and Credential Mapping providers expect. For more information, see the following sections in Managing WebLogic Security:

If you have multiple security providers of the same type configured in the same security realm, these security providers may use the same security provider database. This behavior holds true for all of the WebLogic security providers and the sample security providers that are available under "Code Direct" on the dev2dev Web site.

For example, if you or an administrator configure two WebLogic Authentication providers in the default security realm (called myrealm), both WebLogic Authentication providers will use the same location in the embedded LDAP server as their security provider database, and thus, will use the same users and groups. Furthermore, if you or an administrator add a user or group to one of the WebLogic Authentication providers, you will see that user or group appear for the other WebLogic Authentication provider as well.

Note: If you have two WebLogic security providers (or two sample security providers) of the same type configured in two different security realms, each will use its own security provider database.

The custom security providers that you develop (or the custom security providers that you obtain from third-party security vendors) can be designed so that each instance of the security provider uses its own database or so that all instances of the security provider in a security realm share the same database. This is a design decision that you need to make based on your existing systems and security requirements.

The following sections describe the types of security providers that you can use with WebLogic Server:

Security Provider Summary specifies whether you can configure multiple security providers of the same type in a security realm.

Note: You cannot develop a single security provider that merges several provider types (for example, you cannot have one security provider that does authorization and role mapping).

Authentication providers allow WebLogic Server to establish trust by validating a user. The WebLogic Server security architecture supports Authentication providers that perform: username/password authentication; certificate-based authentication directly with WebLogic Server; and HTTP certificate-based authentication proxied through an external Web server.

Note: An Identity Assertion provider is a special type of Authentication provider that handles perimeter-based authentication and multiple security token types/protocols. For more information, see Identity Assertion Providers.

A LoginModule is the part of an Authentication provider that actually performs the authentication of a user or system. Authentication providers also use Principal Validation providers to verify the authenticity of principals (users/groups) associated with the Java Authentication and Authorization Service (JAAS). For more information about Principal Validation providers, see Principal Validation Providers.

You must have one Authentication provider in a security realm, and you can configure multiple Authentication providers in a security realm. Having multiple Authentication providers allows you to have multiple LoginModules, each of which may perform a different kind of authentication. An administrator configures each Authentication provider to determine how multiple LoginModules are called when users attempt to login to the system. Because they add security to the principals used in authentication, a Principal Validation provider must be accessible to your Authentication providers.

Authentication providers and LoginModules are discussed in more detail in Authentication Providers.

Identity assertion involves establishing a client's identity using client-supplied tokens that may exist outside of the request. Thus, the function of an Identity Assertion provider is to validate and map a token to a username. Once this mapping is complete, an Authentication provider's LoginModule can be used to convert the username to principals.

An Identity Assertion provider is a specific form of Authentication provider that allows users or system processes to assert their identity using tokens (in other words, perimeter authentication). You can use an Identity Assertion provider in place of an Authentication provider if you create a LoginModule for the Identity Assertion provider, or in addition to an Authentication provider if you want to use the Authentication provider's LoginModule.

You can develop Identity Assertion providers that support different token types, including Kerberos, SAML (Security Assertion Markup Language) and Microsoft Passport. When used with an Authentication provider's LoginModule, Identity Assertion providers support single sign-on. For example, the Identity Assertion provider can generate a token from a digital certificate, and that token can be passed around the system so that users are not asked to sign on more than once.

You can configure multiple Identity Assertion providers in a security realm, but none are required. Identity Assertion providers can support more than one token type, but only one token type per Identity Assertion provider can be active at a given time. For example, an Identity Assertion provider can support both Kerberos and SAML, but an administrator configuring the system must select which token type (Kerberos or SAML) is the active token type for the Identity Assertion provider. If this Identity Assertion provider is set to Kerberos, but SAML token types must be supported, then another Identity Assertion provider that can handle SAML must have SAML set as its active token type.

WebLogic Server provides support for an Enterprise JavaBean (EJB) interoperability protocol 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:

Note: 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.

Because some LoginModules can be remotely executed on behalf of RMI clients, and because the client application code can retain the authenticated subject between programmatic server invocations, Authentication providers rely on Principal Validation providers to provide additional security protections for the principals contained within the subject.

Principal Validation providers provide these additional security protections by signing and verifying the authenticity of the principals. This principal validation provides an additional level of trust and may reduce the likelihood of malicious principal tampering. Verification of the subject's principals takes place during the WebLogic Server's demarshalling of RMI client requests for each invocation. The authenticity of the subject's principals is also verified when making authorization decisions.

Because you must have one Authentication provider in a security realm, you must also have one Principal Validation provider in a security realm. If you have multiple Authentication providers, each of those Authentication providers must have a corresponding Principal Validation provider.

Authorization providers control access to WebLogic resources based on user identity or other information. The WebLogic security architecture supports several types of authorization:

An Access Decision is the part of the Authorization provider that actually determines whether a subject has permission to perform a given operation on a WebLogic resource. Authorization providers can also use Principal Validation providers to verify the authenticity of principals (users and groups) associated with the Java Authentication and Authorization Service (JAAS). For more information about Principal Validation providers, see Principal Validation Providers.

You must have one Authorization provider in a security realm, and you can configure multiple Authorization providers in a security realm. Having multiple Authorization providers allows you to follow a more modular design (for example, you may want to have an Authorization provider that handles JNDI permissions and another that handles Web application permissions).

Authorization providers and Access Decisions are discussed in more detail in Authorization Providers.

As part of an Authorization provider, an Access Decision determines whether a subject has permission to access a given WebLogic resource. Therefore, if multiple Authorization providers are configured, each may return a different answer to the "is access allowed?" question. These answers may be PERMIT, DENY, or ABSTAIN. Determining what do to if multiple Authorization providers' Access Decisions do not agree on an answer is the function of an Adjudication provider. The Adjudication provider resolves authorization conflicts by weighing each Access Decision's answer and returning a final result. If you only have one Authorization provider and no Adjudication provider, then an ABSTAIN returned from the single Authorization provider's Access Decision is treated like a DENY.

You must configure an Adjudication provider in a security realm only if you have multiple Authorization providers. You can have only one Adjudication provider in a security realm.

A Role Mapping provider supports dynamic role associations by obtaining a computed set of roles granted to a requestor for a given WebLogic resource. The WebLogic Security Framework determines which roles (if any) apply to a particular subject at the moment that access is required for a given WebLogic resource by:

A Role Mapping provider supplies Authorization providers with this role information so that the Authorization provider can answer the "is access allowed?" question for WebLogic resources that use role-based security (that is, Web application and Enterprise JavaBean container resources).

You set roles in J2EE deployment descriptors, or create them using the WebLogic Server Administration Console. These roles are applied at deployment time (unless you specifically choose to ignore the roles).

You must have one Role Mapping provider in a security realm, and you can configure multiple Role Mapping providers in a security realm. Having multiple Role Mapping providers allows you to work within existing infrastructure requirements (for example, configuring one Role Mapping provider for each LDAP server that contains user and role information), or follow a more modular design (for example, configuring one Role Mapping provider that handles mappings for JNDI resources and another that handles mappings for Web applications).

Note: If multiple Role Mapping providers are configured, the set of roles returned by all Role Mapping providers will be intersected by the WebLogic Security Framework. That is, role names from all the Role Mapping providers will be merged into single list, with duplicates removed.

An Auditing provider collects, stores, and distributes information about operating requests and the outcome of those requests for the purposes of non-repudiation. An Auditing provider makes the decision about whether to audit a particular event based on specific audit criteria, including audit severity levels. Auditing providers can write the audit information to output repositories such as an LDAP back-end, database, or simple file. Specific actions, such as paging security personnel, can also be configured as part of an Auditing provider.

Other types of security providers (such as Authentication or Authorization providers) can request audit services before and after security operations have been performed by calling through the Auditor. (The Auditor is the portion of the WebLogic Server Framework that calls into each Auditing provider, enabling audit event recording.)

You can configure multiple Auditing providers in a security realm, but none are required.

A credential map is a mapping of credentials used by WebLogic Server to credentials used in a legacy (or any remote) system, which tell WebLogic Server how to connect to a given resource in that system. In other words, credential maps allow WebLogic Server to log into a remote system on behalf of a subject that has already been authenticated. You can develop a Credential Mapping provider to map credentials in this way.

A Credential Mapping provider can handle several different types of credentials (for example, username/password combinations, Kerberos tickets, and public key certificates). You can set credential mappings in deployment descriptors or by using the WebLogic Server Administration Console. These credential mappings are applied at deploy time (unless you specifically choose to ignore the credential mappings).

You must have one Credential Mapping provider in a security realm, and you can configure multiple Credential Mapping providers in a security realm. If multiple Credential Mapping providers are configured, then the Credential Manager—the portion of the WebLogic Security Framework that calls into each Credential Mapping provider to find out if they contain the type of credentials requested by the container—accumulates and returns all the credentials as a list.

Credential Mapping providers are discussed in more detail in Credential Mapping Providers.

With WebLogic Server, you can use a Keystore to create and manage password-protected stores of private keys (and their associated public key certificates) and trusted certificate authorities. The Keystore is available to applications that may need it for authentication or signing purposes.

The Keystore provider that is included as part of the WebLogic Server product is used to obtain secured private keys from Keystores. For more information on Keystore providers, see "The WebLogic Security Providers" on page 3-7.

The WebLogic Realm Adapter providers provide backward-compatibility with 6.x WebLogic security realms by allowing the use of existing, 6.x security realms with the security features in this release of WebLogic Server. The WebLogic Realm Adapter providers map the realm API (weblogic.security.acl) used in WebLogic Server 6.x to the APIs used in this release of WebLogic Server. There are four WebLogic Realm Adapter providers:

Table 2-2 indicates whether you can configure multiple security providers of the same type in a security realm.

Table 2-2 Security Provider Summary

Type	Multiple?
Authentication provider	Yes
Identity Assertion provider	Yes
Principal Validation provider	Yes
Authorization provider	Yes
Adjudication provider	No
Role Mapping provider	Yes
Auditing provider	Yes
Credential Mapping provider	Yes

All security providers exist within the context of a security realm. If you are not running a prior, 6.x release of WebLogic Server, the WebLogic Server 7.0 security realm defined out-of-the-box as the default realm (that is, the active security realm called myrealm) contains the WebLogic security providers displayed in Figure 2-4.

Note: If you are upgrading from a 6.x release to the 7.0 release, your out-of-the-box experience begins with a compatibility realm—which is initially defined as the default realm—to allow you to work with your existing configuration. Because the 6.x model is deprecated, you need to upgrade your security realm to the 7.0 model. For information about upgrading, see "Upgrading Security" under "Upgrading WebLogic Server 6.x to Version 7.0" in the Upgrade Guide for BEA WebLogic Server 7.0.

Note: The types of security providers that are required for a 7.0 security realm are shown in solid boxes; the security providers that are optional for a 7.0 security realm are shown in dashed boxes.

Because security providers are individual modules or components that are "plugged into" a WebLogic Server security realm, you can add, replace, or remove a security provider with minimal effort. You can use the WebLogic security providers, custom security providers you develop, security providers obtained from third-party security vendors, or a combination of all three to create a fully-functioning security realm. However, as Figure 2-4 also shows, some types of security providers are required for a 7.0 security realm to operate properly. Table 2-3 summarizes which security providers must be configured for a fully-operational 7.0 security realm.

Table 2-3 Security Providers in a Security Realm

Type	Required?
Authentication provider	Yes
Identity Assertion provider	No
Principal Validation provider	Yes
Authorization provider	Yes
Adjudication provider	Yes, if there are multiple Authorization providers configured.
Role Mapping provider	Yes
Auditing provider	No
Credential Mapping provider	Yes
Keystore provider	No Note: The WebLogic Keystore provider has been deprecated in WebLogic Server 7.0 SP01, and you cannot develop custom Keystore providers.

For more information about security realms, see the following topics in Managing WebLogic Security:

digital certificates (generate via certgen utility or certificate request generator servlet)

Today, a growing number of applications are being made available over the Web. These applications are typically comprised of different components, each of which may have its own authentication scheme or user registry. As are result, development and operations staffs are faced with the increasingly difficult problem of how to require their user community to authenticate or "sign-on" once, yet have access to each of the components of the application. The ability to require a user to sign-on to an application only once is called single sign-on.

BEA's WebLogic Server attempts to address a number of the issues concerning single sign-on support through a series of approaches, each focused at a different tier in which a portion of an application is housed, and addressing the problems that appear in that tier. The new security architecture provides essential integration points, called security providers, that allow best-in-breed solutions to be "plugged in" by commercial security vendors or customers themselves. In addition, WebLogic Server provides implementations for most of these providers.

With a growing focus on the Web as the user interface to applications, the Web tier is fast becoming the most common place where the requirement for single sign-on appears. In the Web tier, the user of a browser is prompted to authenticate their identity to the application. This identity is then propagated to the application server and utilized in the authentication of the user. The result of a successful sign-on is a cookie that is scope to the DNS domain in which the application server is resident. This cookie is then returned to the browser where it is sent with each future request to the application server.

As a J2EE 1.3 conferment application server, WebLogic Server supports all of the required mechanisms for authentication and single sign-on. These include:

The first two forms of authentication, basic and form-based, typically require the use of a secure transport, such as SSL or TLS, in order to protect the rather weak security utilized to protect the user's credentials.

In addition to the J2EE prescribed mechanisms, WebLogic Server can also be configured to support the use of additional authentication technology. This is possible through the use of the extensible WebLogic Security Framework. The use of the WebLogic Security Framework allows for the consistent enforcement of authentication policies regardless of whether the client is a browser or an application. This also removes the requirement for each application having to provide its own servlet filter with which to perform authentication. A further benefit is that this allows the type of authentication mechanisms, such as the use of a stronger authentication mechanism, to be changed without requiring changes in the application itself.

WebLogic Server goes beyond the J2EE 1.3 specification with its support for single sign-on by supporting fail over and load balancing to other members of a cluster without the need to re-authenticate to each cluster member. Furthermore, if the session has been configured for file or JDBC persistence, then the single sign-on solution can be extended even further to other non-clustered servers within the same DNS domain. Finally, it is possible to both disable single sign-on, as well as to create a group of different applications or Web components that participate in a single sign-on group by specifying a name, which is used to control the scope of a cookie within the weblogic.xml deployment descriptor file. The use of single sign-on groups provides the ability for a single DNS domain to be home to multiple applications, each of which can control which other applications or Web components are allowed to participate as part of its particular single sign-on environment.

Although the J2EE 1.3 specification does not address the concept of a single sign-on environment that spans multiple DNS domains, WebLogic Server is uniquely designed to support this type of environment through partnerships with other security vendors. Cross-Domain single sign-on allows users to authenticate once but access multiple applications, even if these applications reside in different DNS domains. This provides the ability to construct a network of affiliates or partners that can participate in a single sign-on domain.

Through the use of the Security Framework contained in WebLogic Server, it is possible for standards-based solutions to be utilized to provide single sign-on integration at both the affiliate, as well as the global level. In particular, emerging standards and de facto standards such as the Security Assertions Markup Language (SAML) from Oasis and Internet-wide solutions such as Microsoft Passport and the result of the Liberty Alliance can be integrated with WebLogic Server to create an even broader single sign-on solution.

In today's enterprise applications, it is rare that all the components that make up the application are all contained in the Web tier or are hosted on the same application server. As a result, it is critical that a single sign-on solution support integration of those components as part of the overall offering.

WebLogic Server provides a single sign-on solution that extends beyond the Web tier in order to incorporate integration with legacy systems and other J2EE application servers as part of its standard product features. The mechanisms used to support this functionality can be extended by customers, security vendors, or independent software vendors (ISVs) to provide enhanced capabilities.

As part of the single sign-on solution provided by WebLogic Server, application adapters defined by the J2EE Connector Architecture are able to acquire the credentials necessary to authenticate with the other components that make up the business solution. The credential acquisition capabilities are provided as part of the new security framework in WebLogic Server. Through this framework, the Connector container is able to retrieve the appropriate set of credential information for the target, based on the information in the deployment descriptor, and the mapping contained in the one of the Credential Mapping providers. The credential information is then passed to the adapter, where it can be used to authenticate to the target.

A Credential Mapping provider is responsible for providing a mapping between the combination of the requestor's identity and the desired resource to the credential set appropriate for authenticating with the desired resource for that requestor. In order to allow for easier administration, the identity of the requestor used in the mapping can be either the username under which the requestor authenticated or the name of a group in which the requestor must be a member.

Each Credential Mapping provider can be associated with one or more credential formats, including Kerberos tickets, SAML name assertions, or others. The format of the credentials supported by a given Credential Mapping provider is registered with WebLogic Server at the time the provider is instantiated. BEA provides a default WebLogic Credential Mapping provider that can yield credentials in the form of username and password. This provider is included in the WebLogic Server and later distribution software.

The conformance with Level 0 of the Common Secure Interoperability (CSI) v2 specification allows WebLogic Server to participate in a secure, single sign-on environment with Enterprise JavaBeans (EJBs) hosted in other conferment J2EE application servers over the IIOP protocol.

WebLogic Server supports the required Generic Security Service Username/Password (GSSUP) authentication mechanism as a means to authenticate to another conferment J2EE application server, as well as the ability act as the target of such authentication. It can also support the use of Identity Tokens, as described in the CSIv2 specification, when configured in a trust relationship between the two containers.

Another aspect of single sign-on amongst J2EE application servers that can occur is when an application utilizes Message-Driven Beans with a foreign Java Message Service (JMS) provider, such as IBM MQueue Series. In this scenario, the WebLogic Server EJB container must authenticate itself to the foreign JMS implementation in order to retrieve the queued messages that are to be dispatched to the application code.

As with J2EE Connection adapters, WebLogic Server utilizes the Credential Mapping providers as a means to obtain the necessary credentials to authenticate with the foreign JMS provider. The use of the Credential Mapping provider allows the mapping between the foreign JMS provider and the requestor's identity to the appropriate credential set to be defined using the WebLogic Server Administration Console. In addition, because Credential Mapping providers can be written by customers and external vendors, custom implementations that contain enhanced mappings are possible.