HOME | SITE MAP | SEARCH | CONTACT | GLOSSARY | PDF FILES | WHAT'S NEW
C++ REFERENCE | TABLE OF CONTENTS | PREVIOUS TOPIC | NEXT TOPIC
|
|
|
BEA WebLogic Enterprise 4.2 Developer Center |
|
HOME | SITE MAP | SEARCH | CONTACT | GLOSSARY | PDF FILES | WHAT'S NEW |
||
|
C++ REFERENCE | TABLE OF CONTENTS | PREVIOUS TOPIC | NEXT TOPIC |
||
This chapter describes the client security as provided by the WLE environmental objects.
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.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.
This implementation of WLE client security has the following capabilities and limitations:
Capabilities and Limitations
You use the Bootstrap object to get an initial reference to the SecurityCurrent object. For a description of the Bootstrap object method, refer to "Tobj_Bootstrap::register_callback_port" on page 4-14.
A client that connects to a WLE domain must provide security information according to the security level required by the WLE domain. Table 6-1 defines the security levels supported by WLE domains.
This section describes the functional components of the Security Service.
The security model in the WLE software defines the overall framework for security. The WLE 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 WLE security model defines:
Getting Initial References to the SecurityCurrent Object
Basic Security-level Requirements for WLE Clients
Functional Components
Security Model
The WLE security model is a combination of the security reference model defined in the CORBAservices Security Service specification1and the value-added extensions that provide a focused, simplified form of the security found in BEA TUXEDO. The WLE security model allows application developers to choose to use the security model defined by CORBA or the BEA extensions when developing an application.
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:
Authentication of Principals
The WLE 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:
Controlling Access to Objects
The system administrator is responsible for setting security policies for client machines, server machines, and IIOP Listener/Handlers that interact with applications in their WLE 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 principals, the software provides a set of configuration parameters and utilities. Through these features, a system administrator can configure the WLE software to force the principals to be authenticated to access a system on which WLE software is installed.
This section provides a functional description of the security model.
The security model adopted in the WLE 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 WLE 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 In a security model, there are usually defined sets of specific security policies. The WLE security model defines policies that specify whether a principal must be authenticated to use the system.
WLE implements a delegated trust authentication model. In this model, clients authenticate to a trusted system gateway process. In the case of WLE, 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 WLE 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 WLE system.
Figure 6-1 shows the security the security environment components.
When a user or other principal wants to use the WLE 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 WLE servers.
The WLE 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 WLE domain, and is, therefore, responsible for providing the security mechanisms that will be used in secure invocations for a given object.
The following is a description of what happens when a client invokes on a target object in a WLE environment:
Administrative Control
Security Model Functional Description
Description
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 capability defined by CORBA. A programmer can choose to use the CORBA-defined security model or the BEA extensions when developing an application.
Figure 6-1 WLE Security Environment
Logging on to the System
Example of a Secure Object Invocation
This section provides a description of 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 the credentials can be used. In the WLE 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:
Authentication
Description of Authentication
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 describe 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.
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 WLE 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 WLE 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:
Authentication Mechanisms
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 advanced 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.
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 WLE 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.
Authentication Process
Figure 6-2 Authentication
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.
A Credentials object holds the security attributes of a principal. These security attributes include the principal's authenticated or unauthenticated identities. It also contains information for establishing security associations. The Credentials object provides methods to obtain the security attributes of the principals it represents.
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, asking for the invocation credentials. These default credentials are used in all invocations using object references.
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 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.
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.
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 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 was 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.
A Credentials object (see Figure 6-3) holds the security attributes of a principal. The Credentials object provides methods to obtain and the set 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:
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 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 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 security SecurityCurrent object is a singleton object; there is only a single instance allowed in a process address space. Multiple references to the SecurityCurrent object 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:
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.
CORBA::ORB::object_to_string, will result in the raising of the CORBA::MARSHAL exception.
SecurityCurrent Object
SecurityLevel1::Current, which derives from CORBA::Current
SecurityLevel2::Current, which derives from the SecurityLevel1::Current interface
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
When the 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 The following client security application programming interface (API) modules are implemented as pseudo-objects on the client:
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
Current::get_attributes method is invoked by a client application, the attributes returned from the Credentials object are those of the user (for example, the one that was created by the Principal Authenticator object).
CORBA::ORB::object_to_string, will result in the raising of the CORBA::MARSHAL exception.
Client Security API
The OMG Interface Definition Language (IDL) definitions for these modules are provided in the following sections.
The Object Management Group (OMG) added the Listing 6-1 shows the CORBA Module
CORBA::Current interface to the CORBA module to support the Current pseudo-object. The change enables the CORBA module to support Security Replaceability and Security Level 2.
CORBA::Current interface OMG IDL statements.
Listing 6-1
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.
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.
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.
| Data Type | Definition |
|---|---|
|
|
Data whose representation is known only to the Security Service implementation. |
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 Current 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.
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.
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
);
};
};
This section describes the Security Service methods.
Synopsis
Returns attributes for the Current interface.
OMG IDL Definition
Security::AttributeList get_attributes(
in Security::AttributeTypeList attributes
);
};Arguments
attributes- The set of security attributes (privilege attribute types) whose values are desired. If this list is empty, all attributes are returned.
Description
This method gets privilege (and other) attributes from the client's credentials for the Current interface.
Return Values
Table 6-4 describes the attribute values returned by
get_attributes.
Note: The other attribute types are never returned. The
defining_authorityfield is always empty.Note
This information is taken from CORBAservices: Common Object Services Specification, pp. 15-103, 104. Revised Edition: March 31, 1995. Updated: November 1997. Used with permission by OMG.
Synopsis
Authenticates the client.
OMG IDL Definition
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
);Arguments
method- Must be
Tobj::TuxedoSecurity. Ifmethodis invalid,authenticateraisesCORBA::BAD_PARAM.security_name- The WLE user name.
auth_data- As returned by
Tobj::PrincipalAuthenticator::build_auth_data. Ifauth_datais invalid,authenticateraisesCORBA::BAD_PARAM.privileges- As returned by
Tobj::PrincipalAuthenticator::build_auth_data. Ifprivilegesis invalid,authenticateraisesCORBA::BAD_PARAM.creds- Placed into the SecurityCurrent object.
continuation_data- Always empty.
auth_specific_data- Always empty.
Description
This method authenticates the client via the IIOP Server Listener/Handler so that it can access a WLE domain.
Return Values
Table 6-5 describes the values returned by authenticate.
Note: The client can use BEA TUXEDO style authentication and call
Tobj::PrincipalAuthenticator::logoninstead ofauthenticate.Note
This information is taken from CORBAservices: Common Object Services Specification, pp. 15-91, 92. Revised Edition: March 31, 1995. Updated: November 1997. Used with permission by OMG.
Synopsis
Always fails.
OMG IDL Definition
Security::AuthenticationStatus continue_authentication(
in Security::Opaque response_data,
inout Credentials creds,
out Security::Opaque continuation_data,
out Security::Opaque auth_specific_data
);Description
Because the WLE software does authentication in one step, this method always fails and returns
Security::AuthenticationStatus::SecAuthFailure.Return Values
Always returns
Security::AuthenticationStatus::SecAuthFailure.Note
This information is taken from CORBAservices: Common Object Services Specification, pp. 15-92, 93. Revised Edition: March 31, 1995. Updated: November 1997. Used with permission by OMG.
Synopsis
Gets the attribute list attached to the credentials.
OMG IDL Definition
Security::AttributeList get_attributes(
in AttributeTypeList attributes
);Argument
attributes- The set of security attributes (privilege attribute types) whose values are desired. If this list is empty, all attributes are returned.
Description
This method returns the attribute list attached to the client's credentials. In the list of attribute types, you are required to include only the type value(s) for the attributes you want returned in the AttributeList. Attributes are not currently returned based on attribute-family or identities. In most cases, this is the same result you would get if you called
SecurityLevel1::Current::get_attributes(), since there is only one valid set of credentials in the client at any instance in time. The results could be different if the credentials are not currently in use.Return Values
Returns attribute list.
Note
This is information taken from CORBAservices: Common Object Services Specification, p. 15-97. Revised Edition: March 31, 1995. Updated: November 1997. Used with permission by OMG.
Synopsis
Checks status of credentials.
OMG IDL Definition
boolean is_valid(
out Security::UtcT expiry_time
);Description
This method returns TRUE if the credentials used are active at the time; that is, you did not call
Tobj::PrincipalAuthenticator::logofforTobj_Bootstrap::destroy_current. If this method is called afterTobj::PrincipalAuthenticator::logoff(), FALSE is returned. If this method is called afterTobj_Bootstrap::destroy_current(), theCORBA::BAD_INV_ORDERexception is raised.Return Values
The expiration date returned will contain the
maximum unsigned long longvalue in C++ andmaximum longin Java. Until theunsigned long longdatatype is adopted, theulonglongdatatype is substituted. Theulonglongdatatype is defined as follows:// interim definition of type ulonglong pending the
// adoption of the type extension by all client ORBs.
struct ulonglong {
unsigned long low;
unsigned long high;
};Note
This information is taken from CORBAservices: Common Object Services Specification, p. 15-97. Revised Edition: March 31, 1995. Updated: November 1997. Used with permission by OMG.
Synopsis
Sets credentials type.
OMG IDL Definition
void set_credentials(
in Security::CredentialType cred_type,
in Credentials creds
);Arguments
cred_type- The type of credentials to be set; that is, invocation, own, or non-repudiation.
creds- The object reference to the Credentials object, which is to become the default.
Description
This method can be used only to set
SecInvocationCredentials; otherwise,-set_credentialsraisesCORBA::BAD_PARAM. The credentials must have been obtained from a previous call toSecurityLevel2::Current::get_credentialsorSecurityLevel2::PrincipalAuthenticator::authenticate.Return Values
None.
Note
This information is taken from CORBAservices: Common Object Services Specification, p. 15-104. Revised Edition: March 31, 1995. Updated: November 1997. Used with permission by OMG.
Synopsis
Gets credentials type.
OMG IDL Definition
Credentials get_credentials(
in Security::CredentialType cred_type
);Arguments
cred_type- The type of credentials to get.
Description
This call can be used only to get
SecInvocationCredentials; otherwise,get_credentialsraisesCORBA::BAD_PARAM. If no credentials are available,get_credentialsraisesCORBA::BAD_INV_ORDER.Return Values
Returns the active credentials in the client only.
Note
This information is taken from CORBAservices: Common Object Services Specification, p. 15-105. Revised Edition: March 31, 1995. Updated: November 1997. Used with permission by OMG.
Synopsis
Returns the PrincipalAuthenticator.
OMG IDL Definition
readonly attribute PrincipalAuthenticator
principal_authenticator;Description
The
PrincipalAuthenticatorreturned by theprincipal_authenticatorattribute is of actual typeTobj::PrincipalAuthenticator. Therefore, it can be used both as aTobj::PrincipalAuthenticatorand as aSecurityLevel2::PrincipalAuthenticator.Note: This method raises
CORBA::BAD_INV_ORDERif it is called on an invalid SecurityCurrent object.Return Values
Returns the PrincipalAuthenticator.
Synopsis
Gets the type of authentication expected by the WLE domain.
OMG IDL Definition
AuthType get_auth_type();Description
This method returns the type of authentication expected by the WLE domain. For the definition of
.Tobj::AuthTypevalues, see the section "Basic Security-level Requirements for WLE Clients" on page 6-3Note: This method raises
CORBA::BAD_INV_ORDERif it is called with an invalid SecurityCurrent object.Return Values
Returns the type of authentication required to access the WLE domain.
Synopsis
Authenticates the client.
OMG IDL Definition
Security::AuthenticationStatus logon(
in string user_name,
in string client_name,
in string system_password,
in string user_password,
in UserAuthData user_data
);Arguments
user_name- The WLE user name. The authentication level
is TOBJ_NOAUTH. Ifuser_nameis NULL or empty, or exceeds 30 characters,logonraisesCORBA::BAD_PARAM.client_name- The WLE client name. The authentication level is
TOBJ_NOAUTH. If theclient_nameis NULL or empty, or exceeds 30 characters, logon raises theCORBA::BAD_PARAMexception.system_password- The WLE client application password. The authentication level is
TOBJ_SYSAUTH. If the client name is NULL or empty, or exceeds 30 characters, logon raises theCORBA::BAD_PARAMexception.Note: The
system_passwordmust not exceed 30 characters.user_password- The user password (needed for use by the default WLE authentication service). The authentication level is
TOBJ_APPAUTH.user_data- Data that is specific to the client application (needed for use by a custom WLE authentication service). The authentication level is
TOBJ_APPAUTH.Note:
TOBJ_SYSAUTHincludes the requirements ofTOBJ_NOAUTHplus a client application password.TOBJ_APPAUTHincludes the requirements ofTOBJ_SYSAUTHplus additional information, such as a user password or user data.Note: The
user_passwordanduser_dataparameters are mutually exclusive, depending on the requirements of the authentication service used in the configuration of the WLE domain. The WLE default authentication service expects a user password. A customized authentication service may require user data. The logon call raises theCORBA::BAD_PARAMexception if bothuser_passwordanduser_dataare specified.Description
For remote WLE clients, this method authenticates the client via the IIOP Server Listener/Handler so that the remote client can access a WLE domain. This method is functionally equivalent to
SecurityLevel2::PrincipalAuthenticator::authenticate, but the parameters are oriented to WLE security.Note: This method raises
CORBA::BAD_INV_ORDERif it is called with an invalid SecurityCurrent object.Return Values
Table 6-6 describes the values returned by
logon.
Synopsis
Discards the WLE client authentication context.
OMG IDL Definition
void logoff();Description
This call discards the WLE client context, but does not close the network connections to the WLE domain.
Logoffalso invalidates the current credentials. After logging off, invocations using existing object references fail if the authentication type is notTOBJ_NOAUTH.If the client is currently authenticated to a WLE domain, calling
Tobj_Bootstrap::destroy_current()callslogoffimplicitly.Note: This method raises
CORBA::BAD_INV_ORDERif it is called with an invalid SecurityCurrent object.Return Values
None.
Synopsis
Creates authentication data and attributes for use by
SecurityLevel2::PrincipalAuthenticator::authenticate.OMG IDL Definition
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
);Arguments
user_name- The WLE user name.
client_name- The WLE client name.
system_password- The WLE client application password.
user_password- The user password (default WLE authentication service).
user_data- Client application-specific data (custom WLE authentication service).
auth_data- For use by
authenticate.privileges- For use by
authenticate.Note: If
user_name,client_name, orsystem_passwordis NULL or empty, or exceeds 30 characters, the subsequentauthenticatemethod invocation raises theCORBA::BAD_PARAMexception.Note: The
user_passwordanduser_dataparameters are mutually exclusive, depending on the requirements of the authentication service used in the configuration of the WLE domain. The WLE default authentication service expects a user password. A customized authentication service may require user data. If bothuser_passwordanduser_dataare specified, the subsequent authentication call raises theCORBA::BAD_PARAMexception.Description
This method is a helper function that creates authentication data and attributes to be used by
SecurityLevel2::PrincipalAuthenticator::authenticate.Note: This method raises
CORBA::BAD_INV_ORDERif it is called with an invalid SecurityCurrent object.Return Values
None.
Automation Method Descriptions
This section describes the Automation Security Service methods.
DISecurityLevel2_Current
The DISecurityLevel2_Current object is a BEA implementation of the CORBA Security model. In this release of the WLE software, the
get_attributes(),set_credentials(),get_credentials(), andPrincipal_Authenticator()methods are supported.
Synopsis
Returns attributes for the Current interface.
MIDL Mapping
HRESULT get_attributes(
[in] VARIANT attributes,
[in,out,optional] VARIANT* exceptionInfo,
[out,retval] VARIANT* returnValue);Automation Mapping
Function get_attributes(attributes, [exceptionInfo])Parameters
attributes- The set of security attributes (privilege attribute types) whose values are desired. If this list is empty, all attributes are returned.
exceptioninfo- An optional input argument that allows the client application to get additional exception data if an error occurs. For the ActiveX client, all exception data is returned in the OLE Automation Error Object.
Description
This method gets privilege (and other) attributes from the client's credentials for the Current interface.
Returns
A variant containing an array of DISecurity_SecAttribute objects. Table 6-4 describes the attribute values returned by
get_attributes.
Synopsis
Sets credentials type.
MIDL Mapping
HRESULT set_credentials(
[in] Security_CredentialType cred_type,
[in] DISecurityLevel2_Credentials* cred,
[in,out,optional] VARIANT* exceptionInfo);Automation Mapping
Sub set_credentials(cred_type As Security_CredentialType,
cred As DISecurityLevel2_Credentials,
[exceptionInfo])Description
This method can be used only to set
SecInvocationCredentials; otherwise,-set_credentialsraisesCORBA::BAD_PARAM. The credentials must have been obtained from a previous call toDISecurityLevel2_Current.get_credentials.Arguments
cred_type- The type of credentials to be set; that is, invocation, own, or nonrepudiation.
cred- The object reference to the Credentials object, which is to become the default.
exceptioninfo- An optional input argument that allows the client application to get additional exception data if an error occurs. For the ActiveX client, all exception data is returned in the OLE Automation Error Object.
Returns
None.
Synopsis
Gets credentials type.
MIDL Mapping
HRESULT get_credentials(
[in] Security_CredentialType cred_type,
[in,out,optional] VARIANT* exceptionInfo,
[out,retval] DISecurityLevel2_Credentials** returnValue);Automation Mapping
Function get_credentials(cred_type As Security_CredentialType,
[exceptionInfo]) As DISecurityLevel2_CredentialsDescription
This call can be used only to get
SecInvocationCredentials; otherwise,get_credentialsraisesCORBA::BAD_PARAM. If no credentials are available,get_credentialsraisesCORBA::BAD_INV_ORDER.Arguments
cred_type- The type of credentials to get.
exceptioninfo- An optional input argument that allows the client application to get additional exception data if an error occurs. For the ActiveX client, all exception data is returned in the OLE Automation Error Object.
Returns
A DISecurityLevel2_Credentials object for the active credentials in the client only.
Synopsis
Returns the PrincipalAuthenticator.
MIDL Mapping
HRESULT principal_authenticator([out, retval]
DITobj_PrincipalAuthenticator** returnValue);Automation Mapping
Property principal_authenticator As DITobj_PrincipalAuthenticatorDescription
The
PrincipalAuthenticatorreturned by theprincipal_authenticatorproperty is of actual typeDITobj_PrincipalAuthenticator. Therefore, it can be used as aDISecurityLevel2_PrincipalAuthenticator.Note: This method raises
CORBA::BAD_INV_ORDERif it is called on an invalid SecurityCurrent object.Returns
A DITobj_PrincipalAuthenticator object.
DITobj_PrincipalAuthenticator
The DITobj_PrincipalAuthenticator object is used to log in and log out of the WLE domain. In this release of the WLE software, the
authenticate,build_auth_data(),continue_authentication(),get_auth_type(),logon(),andlogoff()methods are implemented
Synopsis
Authenticates the client application.
MIDL Mapping
HRESULT authenticate(
[in] long method,
[in] BSTR security_name,
[in] VARIANT auth_data,
[in] VARIANT privileges,
[out] DISecurityLevel2_Credentials** creds,
[out] VARIANT* continuation_data,
[out] VARIANT* auth_specific_data,
[in,out,optional] VARIANT* exceptionInfo,
[out,retval] Security_AuthenticationStatus* returnValue);Automation Mapping
Function authenticate(method As Long, security_name As String,
auth_data, privileges, creds As DISecurityLevel2_Credentials,
continuation_data, auth_specific_data,
[exceptionInfo]) As Security_AuthenticationStatus
Arguments
method- Must be
Tobj::TuxedoSecurity. Ifmethodis invalid,authenticateraisesCORBA::BAD_PARAM.security_name- The WLE user name.
auth_data- As returned by
DITobj_PrincipalAuthenticator.build_auth_data. Ifauth_datais invalid,authenticateraisesCORBA::BAD_PARAM.privileges- As returned by
DITobj_PrincipalAuthenticator.build_auth_data.Ifprivilegesis invalid,authenticateraisesCORBA::BAD_PARAM.creds- Placed into the SecurityCurrent object.
continuation_data- Always empty.
auth_specific_data- Always empty.
exceptioninfo- An optional input argument that allows the client application to get additional exception data if an error occurs. For the ActiveX client, all exception data is returned in the OLE Automation Error Object.
Description
This method authenticates the client via the IIOP Server Listener/Handler so that it can access a WLE domain.
Returns
A
Security_AuthenticationStatusEnum value. Table 6-5 describes the values returned by authenticate.
Synopsis
Creates authentication data and attributes for use by
DITobj_PrincipalAuthenticator.authenticate.MIDL Mapping
HRESULT build_auth_data(
[in] BSTR user_name,
[in] BSTR client_name,
[in] BSTR system_password,
[in] BSTR user_password,
[in] VARIANT user_data,
[out] VARIANT* auth_data,
[out] VARIANT* privileges,
[in,out,optional] VARIANT* exceptionInfo);Automation Mapping
Sub build_auth_data(user_name As String, client_name As String,
system_password As String, user_password As String, user_data,
auth_data, privileges, [exceptionInfo])Arguments
user_name- The WLE user name.
client_name- The WLE client name.
system_password- The WLE client application password.
user_password- The user password (default WLE authentication service).
user_data- Client application-specific data (custom WLE authentication service).
auth_data- For use by
authenticate.privileges- For use by
authenticate.exceptioninfo- An optional input argument that allows the client application to get additional exception data if an error occurs. For the ActiveX client, all exception data is returned in the OLE Automation Error Object.
Note: If
user_name,client_name, orsystem_passwordis NULL or empty, or exceeds 30 characters, the subsequentauthenticatemethod invocation raises theCORBA::BAD_PARAMexception.Note: The
user_passwordanduser_dataparameters are mutually exclusive, depending on the requirements of the authentication service used in the configuration of the WLE domain. The WLE default authentication service expects a user password. A customized authentication service may require user data. If bothuser_passwordanduser_dataare specified, the subsequent authentication call raises theCORBA::BAD_PARAMexception.Description
This method is a helper function that creates authentication data and attributes to be used by
DITobj_PrincipalAuthenticator.authenticate.Note: This method raises
CORBA::BAD_INV_ORDERif it is called with an invalid SecurityCurrent object.Returns
None.
Synopsis
Always returns
Security::AuthenticationStatus::SecAuthFailure.MIDL Mapping
HRESULT continue_authentication(
[in] VARIANT response_data,
[in,out] DISecurityLevel2_Credentials** creds,
[out] VARIANT* continuation_data,
[out] VARIANT* auth_specific_data,
[in,out,optional] VARIANT* exceptionInfo,
[out,retval] Security_AuthenticationStatus* returnValue);Automation Mapping
Function continue_authentication(response_data,
creds As DISecurityLevel2_Credentials, continuation_data,
auth_specific_data, [exceptionInfo]) As
Security_AuthenticationStatusDescription
Because the WLE software does authentication in one step, this method always fails and returns
Security::AuthenticationStatus::SecAuthFailure.Returns
Always returns
SecAuthFailure.
Synopsis
Gets the type of authentication expected by the WLE domain.
MIDL Mapping
HRESULT get_auth_type(
[in, out, optional] VARIANT* exceptionInfo,
[out, retval] Tobj_AuthType* returnValue);Automation Mapping
Function get_auth_type([exceptionInfo]) As Tobj_AuthTypeArgument
exceptioninfo- An optional input argument that allows the client application to get additional exception data if an error occurs. For the ActiveX client, all exception data is returned in the OLE Automation Error Object.
Description
This method returns the type of authentication expected by the WLE domain. For the definition of
.Tobj::AuthTypevalues, see the section "Basic Security-level Requirements for WLE Clients" on page 6-3Note: This method raises
CORBA::BAD_INV_ORDERif it is called with an invalid SecurityCurrent object.Returned Result
A reference to the Tobj_AuthType enumeration. Table 6-1 defines the valid values.
Synopsis
Logs in to the WLE domain. The correct input parameters depend on the authentication level.
MIDL Mapping
HRESULT logon(
[in] BSTR user_name,
[in] BSTR client_name,
[in] BSTR system_password,
[in] BSTR user_password,
[in] VARIANT user_data,
[in,out,optional] VARIANT* exceptionInfo,
[out,retval] Security_AuthenticationStatus* returnValue);Automation Mapping
Function logon(user_name As String, client_name As String,
system_password As String, user_password As String,
user_data, [exceptionInfo]) As Security_AuthenticationStatusDescription
For remote WLE clients, this method authenticates the client via the IIOP Server Listener/Handler so that the remote client can access a WLE domain. This method is functionally equivalent to
DITobj_PrincipalAuthenticator.authenticate, but the parameters are oriented to WLE security.Arguments
- user_name
- The WLE user name. This parameter is required for
TOBJ_NOAUTH,TOBJ_SYSAUTH, andTOBJ_APPAUTHauthentication levels.- client_name
- The WLE client name. This parameter is required for
TOBJ_NOAUTH,TOBJ_SYSAUTH, andTOBJ_APPAUTHauthentication levels.system_password
The WLE client application password. This parameter is required for TOBJ_SYSAUTHandTOBJ_APPAUTHauthentication levels.
- user_password
- The user password (default WLE authentication service). This parameter is required for the
TOBJ_APPAUTHauthentication level.user_data
Application-specific data (custom authentication service). This parameter is required for the TOBJ_APPAUTHauthentication level.Note: If
user_name,client_name, orsystem_passwordis NULL or empty, or exceeds 30 characters, the subsequentauthenticatemethod invocation raises theCORBA::BAD_PARAMexception.Note: If the authorization Level is
TOBJ_APPAUTH, only one ofuser_passwordoruser_datamay be supplied.
exceptioninfo- An optional input argument that allows the client application to get additional exception data if an error occurs. For the ActiveX client, all exception data is returned in the OLE Automation Error Object.
Returns
Table 6-6 describes the values returned by
logon.
Synopsis
Discards the WLE client authentication context.
MIDL Mapping
HRESULT logoff([in, out, optional] VARIANT* exceptionInfo);Automation Mapping
Sub logoff([exceptionInfo])Description
This call discards the WLE client context, but does not close the network connections to the WLE domain.
Logoffalso invalidates the current credentials. After logging off, calls using existing object references fail if the authentication type is notTOBJ_NOAUTH.If the client is currently authenticated to a WLE domain, calling
Tobj_Bootstrap.destroy_current()callslogoffimplicitly.Argument
exceptioninfo- An optional input argument that allows the client application to get additional exception data if an error occurs. For the ActiveX client, all exception data is returned in the OLE Automation Error Object.
Returns
None.
DISecurityLevel2_Credentials
The DISecurityLevel2_Credentials object is a BEA implementation of the CORBA Security model. In this release of the WLE software, the
get_attributes()andis_valid()methods are supported.
Synopsis
Gets the attribute list attached to the credentials.
MIDL Mapping
HRESULT get_attributes(
[in] VARIANT attributes,
[in,out,optional] VARIANT* exceptionInfo,
[out,retval] VARIANT* returnValue);Automation Mapping
Function get_attributes(attributes, [exceptionInfo])Argument
attributes- The set of security attributes (privilege attribute types) whose values are desired. If this list is empty, all attributes are returned.
exceptioninfo- An optional input argument that allows the client application to get additional exception data if an error occurs. For the ActiveX client, all exception data is returned in the OLE Automation Error Object.
Description
This method returns the attribute list attached to the client's credentials. In the list of attribute types, you are required to include only the type value(s) for the attributes you want returned in the AttributeList. Attributes are not currently returned based on attribute-family or identities. In most cases, this is the same result you would get if you called
DISecurityLevel2.Current::get_attributes(), since there is only one valid set of credentials in the client at any instance in time. The results could be different if the credentials are not currently in use.Arguments
None.
Returns
A variant containing an array of DISecurity_SecAttribute objects. Table 6-4 describes the attribute values returned by
get_attributes.
Synopsis
Checks status of credentials.
MIDL Mapping
HRESULT is_valid(
[out] IDispatch** expiry_time,
[in,out,optional] VARIANT* exceptionInfo,
[out,retval] VARIANT_BOOL* returnValueAutomation Mapping
Function is_valid(expiry_time As Object,
[exceptionInfo]) As BooleanDescription
This method returns TRUE if the credentials used are active at the time; that is, you did not call
DITobj_PrincipalAuthenticator.logoffordestroy_current. If this method is called afterDITobj_PrincipalAuthenticator.logoff(), FALSE is returned. If this method is called afterdestroy_current(), theCORBA::BAD_INV_ORDERexception is raised.Returns
The output
expiry_timeas aDITimeBase_UtcTobject set to max.Programming Examples
This section provides programming examples that use the Security Service.
Note: In Listing 6-7 and Listing 6-8, notice that the
resolve_initial_references("SecurityCurrent")method is used to get a reference to the SecurityCurrent object. The reference is then narrowed, assigned tocur, and used to get PrincipalAuthenticator. Refer to "Tobj_Bootstrap::register_callback_port" on page 4-14 for a description of this method.C++ Example: Using WLE Extensions to Log on
Listing 6-7 shows how to program a Netscape Communicator client using the WLE extensions to CORBA security. The WLE 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_datamethod is a BEA-specific method used to prepare data for the OMG method.Listing 6-7 C++ Client Application Using WLE Extensions to CORBA Security to Log on (BEA TUXEDO Style Authentication)
/* 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_EXAMPLE.CPP
// Description: C++ Client Application Program.
//*****************************************************************************#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <CORBA.h>
#include <Tobj_Bootstrap.h>
#include <tobj_c.h>#define TMMAXPASSLEN 30 // Currently Supported password lengthvoid
main(int argc, char* argv[]){
const char *what = "Start of main";
try {
inti = 0;
const char *orbid = 0;
// look for the first arg that doesn't begin with
// a '-', that should be either an empty string
// indicating we should run as native client, or
// a URL (//host:port) for a gateway and to run
// as non-native
for( i = 1 ; i < argc ; i++ )
if( argv[i][0] != '-' ) {
if( argv[i][0] == '\0' )
orbid = OBB::BEA_TOBJ_ID;
else
orbid = OBB::BEA_IIOP_ID;
break;
}
// Initialize ORB
what = "Calling ORB_init";
CORBA::ORB_var orb = CORBA::ORB_init(argc, argv, orbid);
// Create bootstrap object
what = "Instantiating Tobj_Bootstrap object";
Tobj_Bootstrap Bs(orb, argv[1]);
// Get the SecurityCurrent Object
what = "Calling resolve_initial_references(SecurityCurrent)";
CORBA::Object_var sec_current_obj =
Bs.resolve_initial_references("SecurityCurrent");
SecurityLevel2::Current_var sec_current =
SecurityLevel2::Current::_narrow(sec_current_obj);
// Get a Principal Authenticator
what = "getting principal_authenticator";
SecurityLevel2::PrincipalAuthenticator_var Pa =
sec_current->principal_authenticator();
// Narrow to a BEA Principal Authenticator
Tobj::PrincipalAuthenticator_var BeaPa =
Tobj::PrincipalAuthenticator::_narrow(Pa);
// Get Authentication type
what = "calling get_auth_type";
Tobj::AuthType AuthType = BeaPa->get_auth_type();
// Set args according to security level
const char * userName = "guest";
const char * clientName = "simpclt";
char systemPassword[TMMAXPASSLEN + 1] = {'\0'};
char userPassword[TMMAXPASSLEN + 1] = {'\0'};
switch (AuthType)
{
case Tobj::TOBJ_NOAUTH:
printf(" No Passwords required\n");
break;
case Tobj::TOBJ_SYSAUTH:
printf("System Password required\n");
strcpy (systemPassword, "security");
break;
case Tobj::TOBJ_APPAUTH:
printf("Both System and User Password required\n");
strcpy (systemPassword, "security");
strcpy (userPassword, "hello");
break;
}
#ifdef USE_LOGON
what = "calling logon";
Security::AuthenticationStatus Status =
BeaPa->logon(userName, clientName, systemPassword,
userPassword, NULL);
if ( Status != Security::SecAuthSuccess){
printf("logon failed\n");
exit(1);
}
else {
printf("login succeeded\n");
}
// Security precautions
if ( systemPasswor
C++ Example: Using CORBA Security to Log on
The code shown in boldface type in the Listing 6-7 shows how to program a C++ client to log on to a WLE domain using OMG CORBA authentication.
Java Example: Using WLE Extensions to Log on
Listing 6-8 shows how to program a Netscape Communicator client using the WLE extensions to CORBA security. The WLE extensions enable you to use BEA TUXEDO style authentication.
Listing 6-8 Java Client Application Using WLE 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 {String HostPort = args[0];
// Initialize ORB
ORB orb = ORB.init();
// Create Bootstrap Object
Tobj_Bootstrap bs = new Tobj_Bootstrap(orb, null);
// Get the SecurityCurrent 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 =
(com.beasys.Tobj.PrincipalAuthenticator)
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);
System.out.println( "logon status =" + status);
if (status != 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);
}
}
}
Java Example: Getting Information from Privileges
Listing 6-9 shows how to use the Security Service to get information from privileges on a Java client.
Listing 6-9 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);
}
Java Example: Checking the Validity of the Credentials Expiration Time
Listing 6-10 shows how to use the Security Service to check the validity of the Credentials expiration time on a Netscape Communicator client.
Listing 6-10 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);
}
Java Example: 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);
}
}
}Java Example: 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
}Java Example: 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)
{
}
}Java Example: 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);
}Java Example: 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);
}Java Example: 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);Java Example: 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);
};Java Example: 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);
}Java Example: 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);
}Java Example: 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);
}Java Example: 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);
}Java Example: 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);
};Java Example: 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);
}Java Example: 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);
}Java Example: 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);
}Java Example: 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);Java Example: 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);
}Java Example: 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);
}Java Example: 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);
}
