BEA WebLogic Enterprise 4.2    Developer Center     

        HOME   |   SITE MAP   |   SEARCH   |   CONTACT   |   GLOSSARY  |   PDF FILES |   WHAT'S NEW 
 
        JAVA REFERENCE    |   TABLE OF CONTENTS   |   PREVIOUS TOPIC   |   NEXT TOPIC  

Security Service


This chapter contains the following topics:

Introduction

The purpose of client security is to enable WLE clients to authenticate themselves via the IIOP Server Listener/Handler and to pass the WLE security checks.

WLE client security provides two types of security authentication:

You can use either method to implement client security.

Capabilities and Limitations

This implementation of WebLogic Enterprise client security has the following capabilities and limitations.

Getting Initial References to the SecurityCurrent Object

You use the Bootstrap object to get an initial reference to the SecurityCurrent object. For a description of the Bootstrap object method, refer to the com.beasys.Tobj_Bootstrap.resolve_initial_references method description in the Java API Reference.

Basic Security-Level Requirements for WebLogic Enterprise Clients

A client that connects to a WebLogic Enterprise domain must provide security information according to the security level required by the WebLogic Enterprise domain. Table 6-1 defines the security levels supported by WebLogic Enterprise domains.
Table 6-1 Security Levels Supported by WebLogic Enterprise Domains

Security Level Definition

TOBJ_NOAUTH

No authentication is needed; however, the client can still authenticate itself, and must specify a user name and a client name, but no password.

TOBJ_SYSAUTH

The client must authenticate itself to the WebLogic Enterprise domain, and must specify a user name, client name, and client application password.

TOBJ_APPAUTH

The client must provide information in addition to that which is required by TOBJ_SYSAUTH. If the default WebLogic Enterprise authentication service is used in the WebLogic Enterprise domain configuration, the client must provide a user password; otherwise, the client provides authentication data that is interpreted by the custom authentication service in the WebLogic Enterprise domain.

Functional Components

This section describes the functional components of the Security Service.

Security Model

The security model in the WebLogic Enterprise software defines the overall 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.

The WebLogic Enterprise security model defines:

Authentication of Principals

Authentication of principals, typically a human user or system entity, 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:

Controlling Access to Objects

The WebLogic Enterprise security model provides a simple framework through which a security officer can limit access 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:

Administrative Control

The system administrator is responsible for setting security policies for client machines, server machines, and IIOP Listener/Handlers that interact with applications in their WebLogic Enterprise domain. While the administrator sets the general policies, another person or group of people may be responsible for managing security (users, permissions, and so forth).

To provide system administrators the ability to define and enforce authentication of the principal, the software provides a set of configuration parameters and utilities. Through these features, a system administrator can configure the WebLogic Enterprise software to force the principals to be authenticated to access a system on which WebLogic Enterprise software is installed.

Security Model Functional Description

This section provides a functional description of the security model.

Description

The security model adopted in the WebLogic Enterprise software is based largely on the CORBA security model defined in the CORBAservices Security Service specification. Consequently, many of the concepts found in the CORBA security model apply to WebLogic Enterprise security.

In addition to many of the interfaces defined by the CORBAservices Security Service, BEA provides extensions, in the form of derived interfaces. These extensions expose the security functionality found in the BEA TUXEDO system as CORBA interfaces that are found in the Tobj namespace. The interfaces in the Tobj namespace are intended to be familiar to developers of BEA TUXEDO applications and provide a focused, simplified form of the equivalent CORBA-defined capability. An application developer can choose to use the CORBA-defined security model, or the BEA extensions, when developing an application.

In a security model, there are usually defined sets of specific security policies. The WebLogic Enterprise security model defines policies that specify whether a principal must be authenticated to use the system.

WebLogic Enterprise implements a delegated trust authentication model. In this model, clients authenticate to a trusted system gateway process. In the case of WebLogic Enterprise, the trusted system gateway process is the ISL/ISH. As part of a successful authentication, a security association (called a security context) is established between the client application and the ISL/ISH that is used to mediate access to objects. The WebLogic Enterprise software associates the security context with the network connection over which the principal was authenticated. Except for the authentication exchange, this is currently the default behavior of the WebLogic Enterprise system.

Figure 6-1 shows the security environment components.

Figure 6-1 WebLogic Enterprise Security Environment

Logging on to the System

When a user or other principal wants to use the WebLogic Enterprise system, the principal usually needs to authenticate and obtain credentials. The credentials obtained by the principal contain identity attributes that are used to control access to WebLogic Enterprise servers.

The WebLogic Enterprise Principal Authentication object provides a delegation mechanism to provide security to non-BEA branded clients. As illustrated in Figure 6-1, remote client applications perform authentication with the ISL/ISH, instead of with the server application itself. Consequently, the establishment of a security association is performed in the ISL/ISH, rather than in the server-side ORB.

In terms of CORBA security, the ISL/ISH acts as a CORBA-defined half-gateway into the WebLogic Enterprise domain, and is, therefore, responsible for providing the security mechanisms that will be used in secure invocations for a given object.

Example of a Secure Object Invocation

The following is a description of what happens when a client invokes on a target object in a WebLogic Enterprise environment:

Authentication

When an active entity wants to use a secure object system, it authenticates itself and obtains credentials. The credentials contain its certified identity, and, optionally, its privilege attributes, and control where and when they can be used. In the WebLogic Enterprise security model, an active entity must establish its rights to access objects in the system. The active entity must be either a principal, or a client that is acting on behalf of a principal.

A principal is defined to be either a user or a system entity that is registered in and authenticatable to the security system. Authentication may be accomplished in a number of ways. The most common way is for a user to supply a password. When a user or other principal is authenticated, the principal usually supplies:

Once authenticated, the principal's security attributes are maintained in the security system in a credential. The credentials provide a means for the security system to provide the principal's certified identity and describes the privileges granted to the particular principal.

Principals who initiate activities, have one identity that may be used. The identity is represented in the system as attributes.

Authentication Mechanisms

As stated in "Logging on to the System" on page 6-7, the lack of interoperable security amongst the ORB vendors has resulted in it being necessary to utilize a delegation mechanism to provide authentication to client environments. The delegation mechanism used is similar to the mechanism found in BEA TUXEDO. Consequently, an authentication mechanism known as BEA TUXEDO-based security is supported in WebLogic Enterprise domains. The implementation of this mechanism is layered on top of the security mechanism provided in BEA TUXEDO.

As in BEA TUXEDO, remote client applications perform authentication with the ISL/ISH instead of with the server application itself. Consequently, the establishment of a security association is actually performed in the ISL/ISH, rather than in the server-side ORB. Machines and server applications within a WebLogic Enterprise domain are considered trusted. This trust is a result of a defined trust model that is based on the assumption that the machines and applications that make up the domain are under the control of administrators only.

Authentication of principals in an environment based on BEA TUXEDO requires the use of user names and passwords. Unlike most operating systems, BEA TUXEDO security defines three different authentication levels:

The level of authentication required is administratively controlled and is defined in the application's configuration. Because a client application is typically unaware of the level of authentication configured, it must query the security system to determine the authentication level required.

The configuration of the authentication level required is specified in an application's configuration, not on an object or method level. Consequently, if an application is configured to require authentication, all objects in the application require certified credentials for the principals. Applications can be configured to support either unauthenticated or authenticated principals. In unauthenticated scenarios, application developers may use a Principal Authenticator to assert a user name and client name, neither of which will be verified.

Because the BEA TUXEDO-based authentication mechanism is layered on top of the security mechanisms provided in BEA TUXEDO, it is possible for customers to replace the Authentication Server that provides the default authentication mechanism with a custom implementation. A description of how to replace the Authentication Server in BEA TUXEDO is described in the BEA TUXEDO manuals and is outside the scope of this document.

Authentication Process

The process of authenticating a principal is done by a user sponsor (see Figure 6-2). A user sponsor is the code that calls the security interfaces for user authentication. In a WebLogic Enterprise domain configured to use BEA TUXEDO-based security, the client application is the user sponsor.

In either case, the user provides identity and authentication data, such as a password, to the user sponsor. The user sponsor uses the Principal Authenticator object provided as part of the security implementation 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 6-2 Authentication

Principal Authenticator Object

The Principal Authenticator object is the object visible to the application that is responsible for the creation of Credentials for a given principal. A user or principal that requires authentication but has not been authenticated uses the Principal Authenticator object.

Credentials Object

A Credentials object holds the security attributes of a principal. These security attributes include its authenticated or unauthenticated identities. It also contains information for establishing security associations. The Credentials object provides methods to obtain security attributes of the principals it represents.

SecurityCurrent Object

The SecurityCurrent object represents the current execution context at the client and target object. The SecurityCurrent object provides methods to give access to security information associated with the execution context. The SecurityCurrent object gives access to the Credentials associated with the execution environment.

At any stage, a client or target object can find the default credentials for subsequent invocations by calling the Current.get_credentials method to request the invocation credentials. These default credentials are used in all invocations that use object references.

Principal Authenticator Object

The Principal Authenticator object is used by a user or 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 Credentials object is returned so it can be used for other methods on the Credentials.

The Principal Authenticator object is a singleton object; there is only a single instance allowed in a process address space. Multiple references to the Principal Authenticator object must be supported. 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 that invocation raises the standard exception CORBA.NO_PERMISSION. A method that fails because the feature requested is not supported by the security infrastructure implementation raises the CORBA.NO_IMPLEMENT standard exception. Any parameter that has inappropriate values raises the CORBA.BAD_PARAM standard exception.

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, results in the raising of the CORBA.MARSHAL exception.

WebLogic Enterprise Extensions to the Principal Authenticator Object

BEA extends the Principal Authenticator object with functionality to support similar security to that found in BEA TUXEDO. The enhanced functionality is provided by defining the com.beasys.Tobj.PrincipalAuthenticator interface. This interface contains methods to provide similar capability to that available from BEA TUXEDO through the tpinit function.

The methods defined for the Tobj.PrincipalAuthenticator interface are intended to be familiar to developers of BEA TUXEDO applications, and provide a focused, simplified form of the equivalent CORBA-defined capability. An application developer can choose to use the CORBA-defined or BEA extensions when developing an application. 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 user name, client name, and additional authentication data (for example, passwords) used for authentication. Because the information needs to be transmitted over the network to the ISL/ISH, 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. As a result, multithreaded applications that need to use more than one principal identity are required to call the Current.get_credentials method immediately after the logon method to retrieve the Credentials object as a result of the logon method. Retrieval of the Credentials object directly after a logon method should be protected with serialized access since it is possible for another thread to also perform a logon method.

Credentials Object

A Credentials object (see Figure 6-3) 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. The Credentials object also contains information for establishing security associations.

Credentials objects are created as the result of:

There can be more than one Credentials object in a process address space. Multiple references to a Credentials object must be 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.

All Credentials objects support the SecurityLevel2.Credentials interface. Any invocation that fails as a result of the security infrastructure determining that the client does not have permission, raises the standard exception CORBA.NO_PERMISSION. A method that fails because the feature requested is not supported by the security infrastructure implementation raises the CORBA.NO_IMPLEMENT standard exception. Any parameter that has inappropriate values raises the CORBA.BAD_PARAM standard exception.

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, results in the raising of the CORBA.MARSHAL exception.

SecurityCurrent Object

The SecurityCurrent object (see Figure 6-4) represents the current execution context at both client and target objects. The SecurityCurrent object represents service-specific state information associated with the current execution context. Both clients and servers have SecurityCurrent objects that represent state associated with the thread of execution and the capsule (process) in which the thread is executing (their execution contexts).

The SecurityCurrent object is a singleton object; there is only a single instance allowed in a process address space. Multiple references to the SecurityCurrentobject must be supported.

The SecurityCurrent object is stateful. The methods of the SecurityCurrent object are intended to return information about the state associated with the current execution context. This includes information specific to both the thread of execution that is used to make the call on the SecurityCurrent object, as well as the capsule (process) to which the thread belongs. Changes in state associated purely with the thread, and not with any broader execution context, will remain until the thread terminates or until more state changes are made. State changes associated with a broader execution context (like a process) persist across multiple invocations of methods in the target object, until it is further modified through methods of the SecurityCurrent object or by other means.

Consequently, thread-specific methods called on the SecurityCurrent object are performed on the state associated with the calling thread. The thread in which the SecurityCurrent object was obtained has no influence on the behavior of these methods.

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 or target object can find the default credentials for subsequent invocations by calling the Current.get_credentials method, asking for the invocation credentials. These default credentials are used in all invocations that use object references.

Figure 6-4 SecurityCurrent Object

When the Current.get_attributes method is invoked by a client application, the attributes returned from the Credentials object are those of the user.

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 the raising of the CORBA.MARSHAL exception.

Client Security API

The following client security application programming interface (API) modules are implemented as pseudo-objects on the client:

The OMG Interface Definition Language (IDL) definitions for these modules are provided in the following sections.

CORBA Module

The Object Management Group (OMG) added the org.omg.CORBA.Current interface to the CORBA module to support the SecurityCurrent pseudo-object. The change enables the CORBA module to support Security Replaceability and Security Level 2.

Listing 6-1 shows the org.omg.CORBA.Current interface OMG IDL statements.

Listing 6-1 org.omg.CORBA.Current Interface OMG IDL Statements
module CORBA {
// Extensions to CORBA
interface Current {
};
};
// This information is taken from CORBAservices: Common Object 
// Services Specification
, page 15-230. Revised Edition:
// March 31, 1995. Updated: November 1997. Used with permission by OMG.

TimeBase Module

All data structures pertaining to the basic Time Service, Universal Time Object, and Time Interval Object are defined in the TimeBase module. This allows other services to use these data structures without requiring the interface definitions. The interface definitions and associated enums and exceptions are encapsulated in the TimeBase module.

Listing 6-2 shows the TimeBase module OMG IDL statements.

Listing 6-2 TimeBase Module OMG IDL Statements
// From time service
module TimeBase {
// interim definition of type ulonglong pending the
// adoption of the type extension by all client ORBs.
struct ulonglong {
unsigned long low;
unsigned long high;
};
typedef ulonglong TimeT;
typedef short TdfT;
struct UtcT {
TimeT time; // 8 octets
unsigned long inacclo; // 4 octets
unsigned short inacchi; // 2 octets
TdfT tdf; // 2 octets
// total 16 octets
};
};
// This information is taken from CORBAservices: Common Object 
// Services Specification
, p. 14-5. Revised Edition:
// March 31, 1995. Updated: November 1997. Used with permission by OMG.

Table 6-2 defines the TimeBase module data types.

Note: This information is taken from CORBAservices: Common Object Services Specification, p. 14-6. Revised Edition: March 31, 1995. Updated: November 1997. Used with permission by OMG.

Table 6-2 TimeBase Module Data Type Definitions

Data Type Definition

Time ulonglong

OMG IDL does not at present have a native type representing an unsigned 64-bit integer. The adoption of technology submitted against that RFP will provide a means for defining a native type representing unsigned 64-bit integers in OMG IDL.

Pending the adoption of that technology, you can use this structure to represent unsigned 64-bit integers, understanding that when a native type becomes available, it may not be interoperable with this declaration on all platforms. This definition is for the interim, and is meant to be removed when the native unsigned 64-bit integer type becomes available in OMG IDL.

Time TimeT

TimeT represents a single time value, which is 64 bit in size, and holds the number of 100 nanoseconds that have passed since the base time. For absolute time, the base is 15 October 1582 00:00.

Time TdfT

TdfT is of size 16 bits short type and holds the time displacement factor in the form of seconds of displacement from the Greenwich Meridian. Displacements east of the meridian are positive, while those to the west are negative.

Time UtcT

UtcT defines the structure of the time value that is used universally in the service. When the UtcT structure is holding, a relative or absolute time is determined by its history. There is no explicit flag within the object holding that state information. The inacclo and inacchi fields together hold a value of type InaccuracyT packed into 48 bits. The tdf field holds time zone information. Implementation must place the time displacement factor for the local time zone in this field whenever it creates a Universal Time Object (UTO).

The content of this structure is intended to be opaque; to be able to marshal it correctly, the types of fields need to be identified.

Security Module

The Security module defines the OMG IDL for security data types common to the other security modules. This module depends on the TimeBase module and must be available with any ORB that claims to be security ready.

Listing 6-3 shows the data types supported by the Security module.

Listing 6-3 Security Module OMG IDL Statements
module Security {
typedef sequence<octet> Opaque;

// Extensible families for standard data types
struct ExtensibleFamily {
unsigned short family_definer;
unsigned short family;
};
       //security attributes
typedef unsigned long SecurityAttributeType;

// identity attributes; family = 0
const SecurityAttributeType AuditId = 1;
const SecurityAttributeType AccountingId = 2;
const SecurityAttributeType NonRepudiationId = 3;

// privilege attributes; family = 1
const SecurityAttributeType Public = 1;
const SecurityAttributeType AccessId = 2;
const SecurityAttributeType PrimaryGroupId = 3;
const SecurityAttributeType GroupId = 4;
const SecurityAttributeType Role = 5;
const SecurityAttributeType AttributeSet = 6;
const SecurityAttributeType Clearance = 7;
const SecurityAttributeType Capability = 8;

struct AttributeType {
ExtensibleFamily attribute_family;
SecurityAttributeType attribute_type;
};

typedef sequence <AttributeType> AttributeTypeLists;
struct SecAttribute {
AttributeType attribute_type;
Opaque defining_authority;
Opaque value;
// The value of this attribute can be
// interpreted only with knowledge of type
};

typedef sequence<SecAttribute> AttributeList;

// Authentication return status
enum AuthenticationStatus {
SecAuthSuccess,
SecAuthFailure,
SecAuthContinue,
SecAuthExpired
};
       // Authentication method
typedef unsigned long AuthenticationMethod;
        enum CredentialType {
SecInvocationCredentials;
SecOwnCredentials;
SecNRCredentials
       // Pick up from TimeBase
typedef TimeBase::UtcT UtcT;
};
// This information is taken from CORBAservices: Common Object 
// Services Specification
, pp. 15-193 to195. Revised Edition:
// March 31, 1995. Updated: November 1997. Used with permission by OMG.

Table 6-3 describes the Security module data type.

Table 6-3 Security Module Data Type Definition

Data Type Definition

sequence<octet>

Data whose representation is known only to the Security Service implementation.

Security Level 1 Module

This section defines those interfaces available to client application objects that use only Level 1 Security functionality. This module depends on the CORBA module and the Security and TimeBase modules. The SecurityCurrent interface is implemented by the ORB.

Listing 6-4 shows the Security Level 1 module OMG IDL statements.

Listing 6-4 Security Level 1 Module OMG IDL Statements
module SecurityLevel1 {
interface Current : CORBA::Current { // PIDL
Security::AttributeList get_attributes(
in Security::AttributeTypeList attributes
);
};
};
// This information is taken from CORBAservices: Common Object 
// Services Specification
, p. 15-198. Revised Edition:
// March 31, 1995. Updated: November 1997. Used with permission by OMG.

Security Level 2 Module

This section defines the additional interfaces available to client application objects that use Level 2 Security functionality. This module depends on the CORBA and Security modules.

Listing 6-5 shows the Security Level 2 module OMG IDL statements.

Listing 6-5 Security Level 2 Module OMG IDL Statements
module SecurityLevel2 {
// Forward declaration of interfaces
interface PrincipalAuthenticator;
interface Credentials;
interface Current;
      // Interface Principal Authenticator
interface PrincipalAuthenticator {
Security::AuthenticationStatus authenticate(
in Security::AuthenticationMethod method,
in string security_name,
in Security::Opaque auth_data,
in Security::AttributeList privileges,
out Credentials creds,
out Security::Opaque continuation_data,
out Security::Opaque auth_specific_data
);

Security::AuthenticationStatus
continue_authentication(
in Security::Opaque response_data,
inout Credentials creds,
out Security::Opaque continuation_data,
out Security::Opaque auth_specific_data
);
};

// Interface Credentials
interface Credentials {
Security::AttributeList get_attributes(
in Security::AttributeTypeList attributes
);
boolean is_valid(
out Security::UtcT expiry_time
);
};

// Interface Current derived from SecurityLevel1::Current
// providing additional operations on Current at this
// security level. This is implemented by the ORB.
interface Current : SecurityLevel1::Current { // PIDL
void set_credentials(
in Security::CredentialType cred_type,
in Credentials cred
);

Credentials get_credentials(
in Security::CredentialType cred_type
);
readonly attribute PrincipalAuthenticator
principal_authenticator;
};
};
// This information is taken from CORBAservices: Common Object 
// Services Specification
, pp. 15-198 to 200. Revised Edition:
// March 31, 1995. Updated: November 1997. Used with permission by // OMG.

Tobj Module

This section defines the Tobj module interfaces.

This module provides the interfaces you use to program the BEA TUXEDO style of authentication.

Listing 6-6 shows the Tobj module OMG IDL statements.

Listing 6-6 Tobj Module OMG IDL Statements
//Tobj Specific definitions

module Tobj {
const Security::AuthenticationMethod TuxedoSecurity =
0x54555800;
        //get_auth_type () return values
enum AuthType {
TOBJ_NOAUTH,
TOBJ_SYSAUTH,
TOBJ_APPAUTH
};
       typedef sequence<octet>    UserAuthData;
      interface PrincipalAuthenticator :
SecurityLevel2::PrincipalAuthenticator { // PIDL
AuthType get_auth_type();
              Security::AuthenticationStatus logon(
in string user_name,
in string client_name,
in string system_password,
in string user_password,
in UserAuthData user_data
);
void logoff();
              void build_auth_data(
in string user_name,
in string client_name,
in string system_password,
in string user_password,
in UserAuthData user_data,
out Security::Opaque auth_data,
out Security::AttributeList privileges
);
};
};

Java Programming Examples

This section provides programming examples that use the Security Service.

Note: In Listing 6-7, notice that the resolve_initial_references("SecurityCurrent") method is used to get a reference to the SecurityCurrent object. The reference is then narrowed, assigned to cur, and used to get PrincipalAuthenticator. Refer to Chapter 4, "Bootstrap Object," for a description of this method.

Using WebLogic Enterprise Extensions to Log on

Listing 6-7 shows how to program a Netscape Communicator client using the WebLogic Enterprise extensions to CORBA security. The WebLogic Enterprise extensions enable you to use BEA TUXEDO style authentication. The code in boldface shows the OMG method for logging on, which is an alternative to the BEA TUXEDO method. You may prefer the OMG method for log on. Note that the build_auth_data method is a BEA-specific method used to prepare data for the OMG method.

Listing 6-7 Java Client Application Using WebLogic Enterprise Extensions to CORBA Security to Log on
/*     Copyright (c) 1998 BEA Systems, Inc.
All rights reserved
THIS IS PROPRIETARY
SOURCE CODE OF BEA Systems, Inc.
The copyright notice above does not
evidence any actual or intended
publication of such source code.
*/
//*************************************************************************** //File:		SECURITY_CLIENT_EXAMPLE.JAVA       
//Description: JAVA Client program. //**************************************************************************
import org.omg.CORBA.*;
import com.beasys.Tobj.*;
import com.beasys.*;
import com.beasys.TobjInternal.*;
import java.io.*;
public class security_client_example {
public static void main(String args[])
{

try {
                 // Initialize ORB
ORB orb = ORB.init();

// Create Bootstrap Object
Tobj_Bootstrap bs = new Tobj_Bootstrap(orb, "");

// Get the Security Current Object
org.omg.CORBA.Object secCurObj = bs.resolve_initial_references(
"SecurityCurrent");

org.omg.SecurityLevel2.Current secCur =
org.omg.SecurityLevel2.CurrentHelper.narrow(secCurObj);

// Get a principalauthenticator
org.omg.SecurityLevel2.PrincipalAuthenticator authlev2=
secCur.principal_authenticator();

com.beasys.Tobj.PrincipalAuthenticator auth =
org.omg.SecurityLevel2.PrincipalAuthenticatorHelper.narrow(authlev2);
                 // Get the auth type
com.beasys.Tobj.AuthType authType = auth.get_auth_type();
System.out.println( "authType =" + authType);
byte[] userData = new byte[0];
String userName = "guest";
String clientName = "simpclt";
String systemPassword = null;
String userPassword = null;

// Set args according to security level
switch (authType.value())
{
case com.beasys.Tobj.AuthType._TOBJ_NOAUTH:
System.out.println(" No Password Required ");
break;
case com.beasys.Tobj.AuthType._TOBJ_SYSAUTH:
System.out.println("System Password Required ");
systemPassword = "security";
break;
case com.beasys.Tobj.AuthType._TOBJ_APPAUTH:
System.out.println("System Password Required & ");
System.out.println("User Password Required ");
systemPassword = "security";
userPassword = "hello";
break;
}
// Perform Tuxedo style logon
org.omg.Security.AuthenticationStatus status =
auth.logon(userName, clientName, systemPassword,
userPassword, userData);

// Prepare args CORBA Seciop style for authentication
com.beasys.Tobj.UserAuthData userData;
org.omg.Security.Opaque_var authData;
org.omg.Security.AttributeList_var privileges;
org.omg.SecurityLevel2.Credentials_var creds;
org.omg.Security.Opaque_var continueData;
org.omg.CORBA.ULong method = com.beasys.Tobj.TuxedoSecurity;
org.omg.Security.Opaque_var authSpecificData;

// Use helper to build the authentication data
BeaPa->build_auth_data(userName, clientName,
systemPassword,
userPassword,
userData, authData, privileges);
// Perform Corba Seciop authentication
Security.AuthenticationStatus Status =
BeaPa->authenticate(method, userName, authData,
privileges, creds, continueData,
authSpecificData);

System.out.println( "logon status =" + status);
if (status != org.omg.Security.AuthenticationStatus.SecAuthSuccess)
System.exit(1);
}
catch (UserException e){
System.err.println("User exception: " + e);
e.printStackTrace();
System.exit(1);
}
catch (SystemException e){
System.err.println("System exception: " + e);
e.printStackTrace();
System.exit(1);
}
}
}

Getting Information from Privileges

Listing 6-8 shows how to use the Security Service to get information from privileges on a Java client.

Listing 6-8 Getting Information from Privileges
try {
      // Build empty attribute list to return all privileges
org.omg.Security.AttributeType[] type_list =
new org.omg.Security.AttributeType[0];
// Get attributes from current
org.omg.Security.SecAttribute[] privs =
secCur.get_attributes(type_list);
// Print attributes contents
for (int i = 0 ; i < privs.length ; i++){
switch( privs[i].attribute_type.attribute_type){
case org.omg.Security.Public.value:
// No security was specified.
// Nothing to print.
continue;
case org.omg.Security.AccessId.value:
// User name
String user = new String(privs[i].value);
System.out.println("User = " + user);
continue;
case org.omg.Security.PrimaryGroupId.value:
// Client name
String client = new String(privs[i].value);
System.out.println("Client = " + client);
continue;
}
}
}
catch (SystemException e){
System.out.println("Exception while checking attributes");
System.exit(1);
}

Checking the Validity of the Credentials Expiration Time

Listing 6-9 shows how to use the Security Service to check the validity of the Credentials expiration time on a Netscape Communicator client.

Listing 6-9 Checking Validity of Credentials Expiration Time on a Java Client
try {
       // Get Credentials from current
org.omg.SecurityLevel2.Credentials cred = secCur.get_credentials(
org.omg.Security.CredentialType.SecInvocationCredentials);
// Verify credentials
org.omg.TimeBase.UtcTHolder expiry_time =
new org.omg.TimeBase.UtcTHolder();
if (!cred.is_valid(expiry_time)){
System.out.println(
"Credentials are not valid any more");
System.exit(1);
}
// expiry_time contains credentials expiration in
// 100 nanoseconds since 15 October 1582 00:00
}
catch (SystemException e){
System.out.println("Exception while checking credentials");
System.exit(1);
}

Authentication Using SecurityLevel2.PrincipalAuthenticator

The following code fragment illustrates the use of the CORBA-compliant interfaces to perform authentication.

import org.omg.CORBA.*;
import com.beasys.Tobj.*;
import com.beasys.*;
import com.beasys.TobjInternal.*
import java.io.*;

public class security_client
{
public static void main(String[] args)
{
Tobj.PrincipalAuthenticator auth = null;

try
{
String HostPort = args[0];

// Initialize ORB
ORB orb = ORB.init();

// Create bootstrap object
Tobj_Bootstrap bs =
new Tobj_Bootstrap(orb, "//" + HostPort);

// Get security current
org.omg.CORBA.Object secCurObj =
bs.resolve_initial_references( "SecurityCurrent" );
org.omg.SecurityLevel2.Current secCur2Obj =
org.omg.SecurityLevel2.CurrentHelper.narrow(secCurObj);

// Get Principal Authenticator
org.omg.Security.PrincipalAuthenticator princAuth =
secCur2Obj.principal_authenticator();
com.beasys.Tobj.PrincipalAuthenticator auth =
Tobj.PrincipalAuthenticatorHelper.narrow(princAuth);

// Get Authentication type
com.beasys.Tobj.AuthType authType = auth.get_auth_type();

// Initialize arguments
String userName = "John";
String clientName = "Teller";
String systemPassword = null;
String userPassword = null;
byte[] userData = new byte[0];

// Prepare arguments according to security level requested
switch(authType.value())
{
case com.beasys.Tobj.AuthType._TPNOAUTH:
break;

case com.beasys.Tobj.AuthType._TPSYSAUTH:
systemPassword = "sys_pw";
break;

case com.beasys.Tobj.AuthType._TPAPPAUTH:
systemPassword = "sys_pw";
userPassword = "john_pw";
break;
}

// Build security data
org.omg.Security.OpaqueHolder auth_data =
new org.omg.Security.OpaqueHolder();
org.omg.Security.AttributeListHolder privs =
new Security.AttributeListHolder();
auth.build_auth_data(userNname, clientName, systemPassword,
userPassword, userData, authData,
privs);

// Authenticate user
org.omg.SecurityLevel2.CredentialsHolder creds =
new org.omg.SecurityLevel2.CredentialHolder();
org.omg.Security.OpaqueHolder cont_data =
new org.omg.Security.OpaqueHolder();
org.omg.Security.OpaqueHolder auth_spec_data =
new org.omg.Security.OpaqueHolder();

org.omg.Security.AuthenticationStatus status =
auth.authenticate(com.beasys.Tobj.TuxedoSecurity.value,
0, userName, auth_data.value(),
privs.value(), creds, cont_data,
auth_spec_data);
if (status != AuthenticatoinStatus.SecAuthSuccess)
System.exit(1);
}

catch(UserException e )
{
System.err.println( "User exception: " + e );
e.printStackTrace();
System.exit(1);
}

catch(SystemException e )
{
System.err.println( "User exception: " + e );
e.printStackTrace();
System.exit(1);
}
}
}

Authentication Using Tobj.PrincipalAuthenticator

The following code fragment illustrates the use of the BEA extensions to perform authentication.

import org.omg.CORBA.*;
import com.beasys.Tobj.*;
import com.beasys.*;
import com.beasys.TobjInternal.*
import java.io.*;

public class security_client
{
public static void main(String[] args)
{
Tobj.PrincipalAuthenticator auth = null;

try
{
String HostPort = args[0];

// Initialize ORB
ORB orb = ORB.init();

// Create bootstrap object
Tobj_Bootstrap bs =
new Tobj_Bootstrap(orb, "//" + HostPort);

// Get security current
org.omg.CORBA.Object secCurObj =
bs.resolve_initial_references( "SecurityCurrent" );
org.omg.SecurityLevel2.Current secCur2Obj =
org.omg.SecurityLevel2.CurrentHelper.narrow(secCurObj);

// Get Principal Authenticator
org.omg.Security.PrincipalAuthenticator princAuth =
secCur2Obj.principal_authenticator();
com.beasys.Tobj.PrincipalAuthenticator auth =
Tobj.PrincipalAuthenticatorHelper.narrow(princAuth);

// Get Authentication type
com.beasys.Tobj.AuthType authType = auth.get_auth_type();

// Initialize arguments
String userName = "John";
String clientName = "Teller";
String systemPassword = null;
String userPassword = null;
byte[] userData = new byte[0];

// Prepare arguments according to security level requested
switch(authType.value())
{
case com.beasys.Tobj.AuthType._TPNOAUTH:
break;

case com.beasys.Tobj.AuthType._TPSYSAUTH:
systemPassword = "sys_pw";
break;

case com.beasys.Tobj.AuthType._TPAPPAUTH:
systemPassword = "sys_pw";
userPassword = "john_pw";
break;
}

// TUXEDO-style Authenticatation
org.omg.Security.AuthenticationStatus status =
auth.logon(userName, clientName, systemPassword,
userPassword, userData);

// Check authentication result
if (status!= Security.AuthenticationStatus._SecAuthSuccess)
System.exit(1);
}

catch(UserException e )
{
System.err.println( "User exception: " + e );
e.printStackTrace();
System.exit(1);
}

catch(SystemException e )
{
System.err.println( "User exception: " + e );
e.printStackTrace();
System.exit(1);
}
// Can now proceed with application
}

Logging Off Using Tobj.PrincipalAuthenticator

The following code fragment illustrates the use of the BEA extensions to log off of a domain.

// Log off
try
{
auth.logoff();
}
catch (SystemException e)
{
}
}

Checking the Validity of Credentials

The following code fragment illustrates the use of the CORBA-compliant interfaces to check the validity of a principal's credentials.

try
{
org.omg.Security.UtcTHolder expiry_time =
new org.omg.Security.UtcTHolder();

// Verify credentials
if (!cred.is_valid(expiry_time))
{
System.out.println( "Credentials are not valid any more" );
System.exit(1);
}

// expiry_time contains credentials expiration in
// 100 nanoseconds since 15 October 1582 00:00
}

catch (SystemException e)
{
System.out.println( "Exception while checking credentials" );
System.exit(1);
}

Getting Principal's Privileges

The following code fragment illustrates the use of the CORBA-compliant interfaces to retrieve the privileges and other attributes from a principal's credentials.

try
{
// Build empty attribute type list to return all privileges
org.omg.Security.AttributeType[] type_list =
new org.omg.Security.AttributeType[0];

// Get attributes from current
org.omg.Security.SecAttribute[] privs =
creds.get_attributes(type_list);

// Print attributes contents
for (int i = 0 ; i < privs.length ; i++)
{
switch(privs[i].attribute_type)
{
case org.omg.Security.Public.value:
// No security was specified - Nothing to print.
continue;
case org.omg.Security.AccessId.value:
// User name
String user = new String(privs[i].value);
System.out.println( "User = " + user);
continue;
case org.omg.Security.PrimaryGroupId.value:
// Client name
String client = new String(privs[i].value);
System.out.println( "Client = " + client);
continue;
}
}
}
catch (SystemException e)
{
System.out.println( "Exception while getting privileges" );
System.exit(1);
}

Copying a Credentials Object

The following code fragment illustrates the use of the CORBA-compliant interfaces to copy a Credentials object. Copying a Credentials object results in a "deep copy," possibly creating another security association based on the security technology used by the security provided. Copying a Credentials object that is on the SecurityCurrent object's "own" list does not place the newly create copy on the "own" list. As a result, the newly created copy of the Credentials object can only be used as the default for one or more threads of the application, and will never be used as a default Credentials object for the capsule (process).

try
{
org.omg.SecurityLevel2.Credentials creds_copy =
secCur2.copy();
}
catch
{
System.out.println( "Exception while copying credential" );
System.exit(1);
};

Destroying a Credentials Object

The following code fragment illustrates the use of the CORBA-compliant interfaces to destroy a Credentials object. Typically, a Credentials object exists on the "own" list of the SecurityCurrent object. As a result, it should be removed from the "own" list prior to being destroyed. Destroying a Credentials object always results in the destruction of the security association between the client application and the target object, unless the security association is shared with another Credentials object.

try
{
secCur2.remove_own_credentials( creds );
secCur2.destroy();
}
catch
{
System.out.println( "Exception while destroying credential" );
System.exit(1);
};

Getting the Principal Authenticator Object

The following code fragment illustrates the use of the CORBA-compliant interfaces to retrieve the Principal Authenticator object.

try
{
org.omg.SecurityLevel2.PrincipalAuthenticator princAuth =
secCurLev2.principal_authenticator();
}
catch (SystemException e )
{
System.err.println( "Error getting principal authenticator" );
System.exit(1);
}

Getting Credentials

The following code fragment illustrates the use of the CORBA-compliant interfaces to retrieve the privileges and other attributes from a principal's credentials.

try
{
org.omg.SecurityLevel2.Credentials creds =
secCur.get_credentials(
org.omg.Security.CredentialType.SecInvocatonCredentials);
}
catch (SystemException e)
{
System.out.println( "Exception while getting credentials" );
System.exit(1);
}

Setting Default Credentials

The following code fragment illustrates the use of the CORBA-compliant interfaces to set the privileges and other attributes for a principal's credentials as the credentials to be used for invocations in the current thread.

try
{
secCur.set_credentials(
org.omg.Security.CredentialType.SecInvocationCredentials,
creds );
}
catch (SystemException e )
{
System.out.println( "Exception while setting credentials" );
System.exit(1);
}

Getting a Principal's Privileges

The following code fragment illustrates the use of the CORBA-compliant interfaces to retrieve the privileges and other attributes from a principal's credentials.

try
{
// Build empty attribute type list to return all privileges
org.omg.Security.AttributeType[] type_list =
new org.omg.Security.AttributeType[0];

// Get attributes from current
org.omg.Security.SecAttribute[] privs =
secCur.get_attributes(type_list);

// Print attributes contents
for (int i = 0 ; i < privs.length ; i++)
{
switch(privs[i].attribute_type)
{
case org.omg.Security.Public.value:
// No security was specified - Nothing to print.
continue;
case org.omg.Security.AccessId.value:
// User name
String user = new String(privs[i].value);
System.out.println( "User = " + user);
continue;
case org.omg.Security.PrimaryGroupId.value:
// Client name
String client = new String(privs[i].value);
System.out.println( "Client = " + client);
continue;
}
}
}
catch (SystemException e)
{
System.out.println( "Exception while getting privileges" );
System.exit(1);
}

Removing a Credentials Object from the "Own" List

The following code fragment illustrates the use of the CORBA-compliant interfaces to remove a Credentials object from the list of default Credentials objects for the current capsule (process). Removing a Credentials object from this list eliminates the ability for the removed Credentials object to be used as the capsule default. It does not destroy the Credentials object, or the security association that it represents.

try
{
secCur2.remove_own_credentials( creds );
}
catch
{
System.out.println( "Exception while removing credential" );
System.exit(1);
};

Getting Credentials of the Requesting Principal

The following code fragment illustrates the use of the CORBA-compliant interfaces to retrieve the credentials for the requesting principal.

try
{
org.omg.SecurityLevel2.ReceivedCredentials recCreds =
secCurLev2.recevied_credentials();
org.omg.SecurityLevel2.Credentials creds =
recCreds.accepting_credentials();
}
catch (SystemException e )
{
System.err.println( "Exception getting received credentials" );
System.exit(1);
}

Getting the Principal's Privileges from Credentials

The following code fragment illustrates the use of the CORBA-compliant interfaces to retrieve the privileges and other attributes from the requesting principal's credentials.

try
{
// Build empty attribute list to return all privileges
org.omg.Security.AttributeType[] type_list =
new org.omg.Security.AttributeType[0];

// Get attributes from Credentials
org.omg.Security.SecAttribute[] privs =
creds.get_attributes(type_list);

// Print attributes contents
for (int i = 0 ; i < privs.length ; i++)
{
switch(privs[i].attribute_type)
{
case org.omg.Security.Public.value:
// No security was specified - Nothing to print.
continue;
case org.omg.Security.AccessId.value:
// User name
String user = new String(privs[i].value);
System.out.println( "User = " + user);
continue;
case org.omg.Security.PrimaryGroupId.value:
// Client name
String client = new String(privs[i].value);
System.out.println( "Client = " + client);
continue;
}
}
}
catch (SystemException e)
{
System.out.println( "Exception while getting privileges" );
System.exit(1);
}

Getting the Principal's Privileges from the SecurityCurrent object

The following code fragment illustrates the use of the CORBA-compliant interfaces to retrieve the privileges and other attributes for the requesting principal from the SecurityCurrent object.

try
{
// Build empty attribute list to return all privileges
org.omg.Security.AttributeType[] type_list =
new org.omg.Security.AttributeType[0];

// Get attributes from current
org.omg.Security.SecAttribute[] privs =
secCurLev2.get_attributes(type_list);

// Print attributes contents
for (int i = 0 ; i < privs.length ; i++)
{
switch(privs[i].attribute_type)
{
case org.omg.Security.Public.value:
// No security was specified - Nothing to print.
continue;
case org.omg.Security.AccessId.value:
// User name
String user = new String(privs[i].value);
System.out.println( "User = " + user);
continue;
case org.omg.Security.PrimaryGroupId.value:
// Client name
String client = new String(privs[i].value);
System.out.println( "Client = " + client);
continue;
}
}
}
catch (SystemException e)
{
System.out.println( "Exception while getting privileges" );
System.exit(1);
}

Obtaining the SecurityCurrent Object

The following code fragment illustrates how a server application can obtain a reference to the SecurityCurrent object.

// Obtain a reference to the bootstrap object
Tobj_Bootstrap bs = TP.bootstrap();
// Get the Security Current
org.omg.CORBA.Object secCurObj =
bs.resolve_initial_references( "SecurityCurrent" );
org.omg.SecurityLevel2.Current secCurLev2
org.omg.SecurityLevel2.CurrentHelper.narrow(secCurObj);

Getting Association Options

The following code fragment illustrates the use of the CORBA-compliant interfaces to get the association options in effect for the secure association with the remote principal.

try
{
short options = recCreds.association_options_used();
}
catch (SystemException e)
{
System.out.println( "Exception getting association options" );
System.exit(1);
}

Getting Delegation State

The following code fragment illustrates the use of the CORBA-compliant interfaces to get the delegation state of the remote principal for these credentials.

try
{
org.omg.Security.DelegationState delState =
recCreds.delegation_state();
switch( delState )
{
case org.omg.Security.SecInitiator:
System.out.println( "Acting on own behalf" );
break;
case org.omg.Security.SecDelegate:
System.out.println( "acting on behalf of another" );
break;
}
}
catch (SystemException e)
{
System.out.println( "Exception getting delegation state" );
System.exit(1);
}

Getting Delegation Mode

The following code fragment illustrates the use of the CORBA-compliant interfaces to get the delegation mode of the credentials.

try
{
org.omg.Security.DelegationMode delMode =
recCreds.delegation_mode();
switch( delMode )
{
case org.omg.Security.SecDelModeNoDelegation:
System.out.println( "Unusable for invocation" );
break;
case org.omg.Security.SecDelModeSimpleDelegation:
System.out.println( "Usable for simple delegation" );
break;
case org.omg.Security.SecDelModeCompositeDelegation:
System.out.println( "Usable for composite delegation" );
break;
}
}
catch (SystemException e)
{
System.out.println( "Exception getting delegation mode" );
System.exit(1);
}


Copyright © 1999 BEA Systems, Inc. All Rights Reserved.
Required browser version: Netscape Communicator version 4.0 or higher, or Microsoft Internet Explorer version 4.0 or higher.
Last update: July 01, 1999.