Introduction to WebLogic Security
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, 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 server, database, and a simple file.
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.
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 2-1 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).
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.
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".
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:
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
TextInputCallback, all of which are part of the
javax.security.auth.callback package. The
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 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
CallbackHandler can then choose to prompt for a username and password serially, or to prompt for both in a single window.
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.
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.
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.
Note: 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 mformation, see Do I Need to Develop a Custom Identity Assertion Provider? in Developing Security Providers for WebLogic Server.
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:
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 Credential Mapping Process on page 4-9 and the following sections in Managing WebLogic Security:
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.
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.
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.
WebLogic Server is designed to extend the single sign-on concept all the way to the perimeter through support for identity assertion (see Figure 2-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 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.
Single sign-on (SSO) is the ability for 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. SSO 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 Microsoft clients. This type of SSO 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 SSO with Microsoft Clients Process.
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.
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.
Note: 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.
In releases prior to WebLogic Server 7.0, access control lists (ACLs) were used to protect WebLogic resources. 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 security 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 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.
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 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. BEA 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.
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
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 Authorization and Role Mapping providers 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.
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
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
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.
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.
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 with WebLogic Server, you need a private key, a digital certificate containing the matching public key, and a certificate signed by at least one trusted certificate authority (CA) that can verify the data embedded in the digital certificate. If the certificate authority that signed the digital certificate is not well-known, you may also need to install their root trusted CA's certificate in your WebLogic Server. Trusted CA ceritificates are signed by authorities that are well-know.
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. In this release of WebLogic Server, you should store your 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 Managing WebLogic Security.
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 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. SSL can be used by Web browsers and Java clients as follows:
WebLogic Server supports HTTPS with Web browsers that support SSL version 3. The Java Virtual Machine (JVM) in WebLogic Server does not currently support the HTTPS adapter. Consequently, WebLogic Server depends on the implementation of SSL in the Web browser.
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:
With two-way SSL authentication, both the client and 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 you must restrict access to trusted clients only.
Figure 2-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.
Notes: If you request the domestic-strength version of WebLogic Server and you qualify to receive it, you will receive a domestic-strength WebLogic Server software license to use when you install the WebLogic Server distribution.
Note: If you generate a Certificate Signature Request (CSR), which is an electronically generated request for a certificate, using the exportable-strength WebLogic Server distribution, you cannot support domestic-strength SSL connections and you cannot authenticate clients that present domestic-strength 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.
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. BEA recommends obtaining digital certificates from a certificate authority such as Verisign or Entrust.
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.
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, WebLogic Server, 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 used to initiate the SSL connection. If these names do not match, the SSL connection is dropped.
When an SSL client connects to an SSL server, the SSL server presents its digital certificate chain to the client for authentication. That chain could contain an invalid digital certificate. The SSL specification says that the client should drop the SSL connection upon discovery of an invalid certificate. Web browsers, however, ask the user whether to ignore the invalid certificate and continue up the chain to determine if it is possible to authenticate the SSL server with any of the remaining certificates in the certificate chain. The Trust Manager eliminates this inconsistent practice by enabling you to control when to continue or discontinue an SSL connection. 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.TrustManagerJSSE interface, which enables you to override validation errors in a peer's digital certificate and continue the SSL handshake. You can also use this interface to discontinue an SSL handshake by performing additional validation on a server's digital certificate chain.
For information on storage of public and private keys, see Keystore Providers.
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.
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 is a variable key-size block cipher with a key size range of 40 to 128 bits. It is faster than DES and can be exported with a key size of 40 bits. A 56-bit key size is allowed for foreign subsidiaries and overseas offices of United States companies. In the United States, RC4 can be used with keys of virtually unlimited length, although the WebLogic Server PKI restricts the key length to 128 bits.
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.
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.
WebLogic Server supports the RSA cipher suites described in Table 2-1.
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 WebLogic Server
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.
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 2-4 illustrates a typical setup with a firewall that filters traffic destined for a WebLogic Server cluster.
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.
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, IIOP-CSIv2).
For implementation and use of user authentication and authorization, BEA WebLogic Server utilizes the security services of the SDK version 1.4.1 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.4.1 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.4.1.
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.
For more information on JAAS, see Java Authentication and Authorization Service (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 WebLogic resources running in the JVM. Use of the Java Security Manager to protect WebLogic resources in WebLogic Server is an optional security step.
weblogic.policyfile for general use.
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.
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 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:
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
Note: 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.