|
|
|
|
|
|
WebLogic Enterprise Security Service APIs
This topic includes the following sections:
For the C++, Java, and Automation method descriptions for the WebLogic Enterprise Security Service, see the following topics:
The WebLogic Enterprise Security Model
The security model in the WebLogic Enterprise product defines only a framework for security. The WebLogic Enterprise product provides the flexibility to support different security mechanisms and policies that can be used to achieve the appropriate level of functionality and assurance for a particular WebLogic Enterprise application.
The security model in the WebLogic Enterprise product defines:
The security model in the base WebLogic Enterprise product is a combination of the security model defined in the CORBAservices Security Service specification and the value-added extensions that provide a focused, simplified form of the security model found in BEA Tuxedo.
The following sections describe the general characteristics of the WebLogic Enterprise security model.
Authentication of Principals
Authentication of principals (for example, an individual user, a client application, a server application, a joint client/server application, or an IIOP Listener/Handler) provides security officers with the ability to ensure that only registered principals have access to the objects in the system. An authenticated principal is used as the primary mechanism to control access to objects. The act of authenticating principals allows the security mechanisms to:
The WebLogic Enterprise security model provides a simple framework through which a security officer can limit access to the WebLogic Enterprise domain to authorized users only. Limiting access to objects allows security officers to prohibit access to objects by unauthorized principals. The access control framework consists of two parts:
The system administrator is responsible for setting security policies for the WebLogic Enterprise application. The WebLogic Enterprise product provides a set of configuration parameters and utilities. Using the configuration parameters and utilities, a system administrator can configure the WebLogic Enterprise application to force the principals to be authenticated to access a system on which WebLogic Enterprise software is installed. To enforce the configuration parameters, the system administrator uses the tmloadcf command to update the configuration file for a particular WebLogic Enterprise application.
For more information about configuring security for your WebLogic Enterprise application, see "Configuring the SSL Protocol" on page 6-1 and "Configuring Authentication" on page 7-1.
Functional Components of the WebLogic Enterprise Security Service
The WebLogic Enterprise security model is based on the process of authenticating principals to the WebLogic Enterprise domain. The objects of the WebLogic Enterprise Security Service are used to authenticate a principal. The principal provides identity and authentication data, such as a password, to the client application. The client application uses the Principal Authenticator object to make the calls necessary to authenticate the principal. The credentials for the authenticated principal are associated with the security system's implementation of the SecurityCurrent object and are represented by a Credentials object.
Figure 14-1 illustrates the authentication process used in the WebLogic Enterprise security model.
Figure 14-1 Authentication Process in the WebLogic Enterprise Product
The following sections describe the objects in the WebLogic Enterprise security model.
The Principal Authenticator Object
The Principal Authenticator object is used by a principal that requires authentication but has not been authenticated prior to calling the object system. The act of authenticating a principal results in the creation of a Credentials object that is made available as the default credentials for the application.
The Principal Authenticator object is a singleton object; there is only a single instance allowed in a process address space. The Principal Authenticator object is also stateless. A Credentials object is not associated with the Principal Authenticator object that created it.
All Principal Authenticator objects support the SecurityLevel2::PrincipalAuthenticator interface defined in the CORBAservices Security Service specification. This interface contains two methods that are used to accomplish the authentication of the principal. This is because authentication of principals may require more than one step. The authenticate method allows the caller to authenticate, and optionally select, attributes for the principal of this session.
Any invocation that fails because the security infrastructure does not permit the invocation will raise the standard exception CORBA::NO_PERMISSION. A method that fails because the feature requested is not supported by the security infrastructure implementation will raise the CORBA::NO_IMPLEMENT standard exception. Any parameter that has inappropriate values will raise the CORBA::BAD_PARAM standard exception. If a timing-related problem occurs, they raise a CORBA::COMM_FAILURE. The Bootstrap object maps most system exceptions to CORBA::Invalid_Domain.
The Principal Authenticator object is a locality-constrained object. Therefore, a Principal Authenticator object may not be used through the DII/DSI facilities of CORBA. Any attempt to pass a reference to this object outside of the current process, or any attempt to externalize it using CORBA::ORB::object_to_string, will result in the raising of the CORBA::MARSHAL exception.
Using the Principal Authenticator Object with Certificate-based Authentication
The Principal Authenticator object has been enhanced to support certificate-based authentication. The use of certificate-based authentication is controlled by specifying the Security::AuthenticationMethod value of Tobj::CertificateBased as a parameter to the PrincipalAuthenticator::authenticate operation. When certificate-based authentication is used, the implementation of the PrincipalAuthenticator::authenticate operation must retrieve the credentials for the principal by obtaining the private key and digital certificates for the principal and registering them for use with the SSL protocol.
The values of the security_name and auth_data parameters of the PrincipalAuthenticator::authenticate operation are used to open the private key for the principal. If the user does not specify the proper values for both of these parameters, the private key cannot be opened and the user fails to be authenticated. As a result of successfully opening the private key, a chain of digital certificates that represent the local identity of the principal is built. Both the private key and the chain of digital certificates must be registered to be used with the SSL protocol.
WebLogic Enterprise Extensions to the Principal Authenticator Object
The WebLogic Enterprise product extends the Principal Authenticator object to support a security mechanism similar to the security in BEA Tuxedo. The enhanced functionality is provided by defining the Tobj::PrincipalAuthenticator interface. This interface contains methods to provide similar capability to that available from BEA Tuxedo through the tpinit function. The interface Tobj::PrincipalAuthenticator is derived from the CORBA SecurityLevel2::PrincipalAuthenticator interface.
The extended Principal Authenticator object adheres to all the same rules as the Principal Authenticator object defined in the CORBAservices Security Service specification.
The implementation of the extended Principal Authenticator object requires users to supply a username, client name, and additional authentication data (for example, passwords) used for authentication. Because the information needs to be transmitted over the network to the IIOP Listener/Handler, it is protected to ensure confidentiality. The protection must include encryption of any information provided by the user.
An extended Principal Authenticator object that supports the Tobj::PrincipalAuthenticator interface provides the same functionality as if the SecurityLevel2::PrincipalAuthenticator interface were used to perform the authentication of the principal. However, unlike the SecurityLevel2::PrincipalAuthenticator::authenticate method, the logon method defined on the Tobj::PrincipalAuthenticator interface does not return a Credentials object.
The Credentials Object
A Credentials object (as shown in Figure 14-2) holds the security attributes of a principal. The Credentials object provides methods to obtain and set the security attributes of the principals it represents. These security attributes include its authenticated or unauthenticated identities and privileges. It also contains information for establishing security associations.
Credentials objects are created as the result of:
Figure 14-2 The Credentials Object
Multiple references to a Credentials object are supported. A Credentials object is stateful. It maintains state on behalf of the principal for which it was created. This state includes any information necessary to determine the identity and privileges of the principal it represents. Credentials objects are not associated with the Principal Authenticator object that created it, but must contain some indication of the authentication authority that certified the principal's identity.
The Credentials object is a locality-constrained object; therefore, a Credentials object may not be used through the DII/DSI facilities. Any attempt to pass a reference to this object outside of the current process, or any attempt to externalize it using CORBA::ORB::object_to_string, will result in the raising of the CORBA::MARSHAL exception.
The Credentials object has been enhanced to allow application developers to indicate the security attributes for establishing secure connections. These attributes allow developers to indicate whether a secure connection requires integrity, confidentiality, or both. To support this capability, two new attributes were added to the SecurityLevel2::Credentials interface.
The SecurityCurrent Object
The SecurityCurrent object (see Figure 14-3) represents the current execution context at both the principal and target objects. The SecurityCurrent object represents service-specific state information associated with the current execution context. Both client and server applications have SecurityCurrent objects that represent state associated with the thread of execution and the process in which the thread is executing.
Figure 14-3 The SecurityCurrent Object
The SecurityCurrent object is a singleton object; there is only a single instance allowed in a process address space. Multiple references to the SecurityCurrent object are supported.
The CORBAservices Security Service specification defines two interfaces for the SecurityCurrent object associated with security:
Both interfaces give access to security information associated with the execution context.
At any stage, a client application can determine the default credentials for subsequent invocations by calling the Current::get_credentials method and asking for the invocation credentials. These default credentials are used in all invocations that use object references.
When the Current::get_attributes method is invoked by a client application, the attributes returned from the Credentials object are those of the principal.
The SecurityCurrent object is a locality-constrained object; therefore, a SecurityCurrent object may not be used through the DII/DSI facilities. Any attempt to pass a reference to this object outside of the current process, or any attempt to externalize it using CORBA::ORB::object_to_string, results in a CORBA::MARSHAL exception.
|
|
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|