1 — NetCrusader/CORBA Product Overview

[Previous] [Next] [Table of Contents] [Index]

The Gradient® NetCrusader/CORBA Security Service provides CORBA security for applications that use the ORB, including authentication, access control, confidentiality, delegation, and auditing.

This chapter describes how the Gradient NetCrusader™/CORBA ORB service works, and provides an overview of the security features it provides:

1.1 Support for Object Invocations over Secured IIOP (SECIOP)
1.2 Supported ORBs
1.3 Supported Protocols
1.4 NetCrusader/CORBA Components
1.5 CORBA Security Concepts
1.6 Application Security Features
1.7 Administration Overview
1.8 Application Development Overview

1.1 Support for Object Invocations over Secured IIOP (SECIOP)

NetCrusader/CORBA supports the Level 1 and Level 2 security functionality described in the Object Management Group's CORBA Security Service (Version 1.5) specification. This allows clients to invoke target objects over a Secure Inter-ORB Protocol (SECIOP) link, and servers to perform access control and auditing when a client invokes a target object.

NetCrusader/CORBA runtime components integrate into the client and server ORBs to establish security contexts, manage the state of those contexts, and provide the required security by reading policies and communicating with the security server.

NetCrusader/CORBA uses an underlying Kerberos framework for confidentiality and the generation of credentials for authentication and authorization.

Figure 1-1 illustrates how requests by an application client for objects on an application server are handled securely over the network.

Figure 1-1: Secure IIOP Transport

Clients authenticate to the security system through a login/password prompt by the application. Requests are encrypted using standard (V5) Kerberos and securely transmitted across the ORB. The target uses information in the client's credentials, such as the groups to which the client belongs, for auditing and to determine access rights.

1.1.1 VisiBroker Implementation

NetCrusader/CORBA currently supports secure invocations over SECIOP for the Inprise™ VisiBroker Java ORBs. This section discusses how NetCrusader/CORBA integrates with this environment.

As mandated by the CORBA security specification, ORBs must support an interceptor mechanism that allows the inspection and modification of traffic as it moves back and forth in an object invocation. VisiBroker™ supports this interceptor mechanism in its Java ORBs.

NetCrusader/CORBA registers its client- and server-side interceptors with the VisiBroker ORB at startup based on the command-line arguments you supply (see the NetCrusader/CORBA Installation and Operation Guide for information about these arguments). The ORB then calls these interceptors automatically to handle client requests.

As shown in Figure 1-2, when a client issues a request, the ORB forwards the request to the NetCrusader/CORBA interceptors to evaluate the level of security (if any) that the request requires before it traverses the network. The NetCrusader/CORBA security services:

Obtain an object reference to the correct server object.
Establish a secure channel (also called a security context) that the client and server use to interact securely. NetCrusader/CORBA uses the Generic Security Service API (GSSAPI) protocol to negotiate the security context.

Figure 1-2: VisiBroker Implementation

1.2 Supported ORBs

NetCrusader/CORBA supports the Inprise VisiBroker ORB for Java Version 3.3 for Windows NT.

Contact Inprise Corporation for information about obtaining client and server versions of this ORB (see Obtaining Additional Technical Information on page vii for contact information).

1.3 Supported Protocols

NetCrusader/CORBA supports the following protocols:

SECIOP (Secure Inter-ORB Protocol) — The underlying layer of NetCrusader/CORBA that provides security features like credential generation, encryption, and auditing.
IIOP — The ORB transport protocol that the Inprise ORB uses.

The NetCrusader/CORBA design leverages the existing Gradient security framework for application development environments other than CORBA. NetCrusader/CORBA securely interoperates with environments that use other Gradient NetCrusader products.

For more information about using NetCrusader/CORBA with other environments, refer to the NetCrusader/CORBA Application Developer's Guide.

1.4 NetCrusader/CORBA Components

NetCrusader/CORBA provides a one-button installation program that installs all of the components a system requires. You can easily configure clients by entering the hostname of your Security Server during the installation process.

NetCrusader/CORBA includes the following components:

NetCrusader/CORBA Security Server
CORBA Application Server and Client Components
NetCrusader Commander

1.5 CORBA Security Concepts

This section describes the main concepts related to CORBA security.

1.5.1 Policy Domains

A security policy domain is a group of application objects to which you apply common security policies. Creating domains is the principal method you use to structure and administer your CORBA security environment. Domains simplify administration by allowing you to apply access control, authentication, delegation, and auditing policies to groups of objects at once.

Application objects are added to domains on the application side using command line options. For example, to add application server objects to a domain called foo, use the option -GradPolicy foo during application startup. All objects created by this server will be members of domain foo and subject to the security policies you apply to this domain.

NetCrusader/CORBA supports hierarchical domains as described in the CORBA Security specification. Hierarchical structuring of domains allows you to implement security policies globally by nesting subdomains within domains (Figure 1-3). Subdomains inherit the parent domain's security policies, but a subdomain's policies can differ from and override the parent domain's policies.

Figure 1-3: Domains and Subdomains

NetCrusader/CORBA allows you to grant management rights on a domain basis. In this way, suborganizations can control their own security policies while still operating under the security requirements of the parent organization.

1.5.2 Security Policies

Security policies are the levels of access and other kinds of controls that you apply to objects and operations in a domain. Policies are your primary means of securing and regulating access to your resources.

Because CORBA Security Management supports hierarchical domains, you can apply a policy to multiple domains simultaneously. Security policies applied to a parent domain are inherited by the parent domain's subdomains.

The security policies you can apply are:

Access policies — Control access to the objects within a domain based on the attributes of the requesting principal (for example, group membership or user ID).
Delegation policies — Control whether objects in a domain, when acting as an intermediate in a call chain, delegate the credentials they receive or pass both their own credentials and the client's credentials to the target object.
Client and target secure invocation policies — Specify the confidentiality and authentication requirements for connections between a client and target, determine if a client allows its credentials to be delegated, and determine if a target accepts credentials that have been delegated.
Audit policies — Specify the security-related operations and object invocations that you want to track.

Section 1.6 discusses the NetCrusader/CORBA implementation of each of these policies in detail.

1.5.3 Rights and Rights Families

Each operation in the interface of a secure object must have some set of rights associated with it so that access control decisions can be made. If a client's rights are sufficient to fulfill the operation's requirements, the client's request is granted.

By default, NetCrusader/CORBA supports the corba rights family, which contains four standard rights: get, set, manage, and use. NetCrusader/CORBA also supports extensible rights families, so that you can create your own custom rights families to suit the needs of your environment.

1.6 Application Security Features

NetCrusader/CORBA supports secure object invocation — object invocation over a secure channel. The characteristics of a secure channel between the target object and the client are:

Authenticated access — Authentication is a process by which one entity (such as a client) proves its identity to second entity (such as a target object) and vice-versa. In this way, the target knows the identity of the client issuing the request, and the client verifies the authenticity of the target. (Section 1.6.1)

Secure Message Transport — Secure message transport includes confidentiality (this is optional), which protects messages from electronic eavesdropping through the use of encryption, and replay detection, which allows the detection and denial of duplicated requests.

Message integrity is also supported, which means that the data stream is inspected for changes and message order is verified. This prevents data corruption and unauthorized, malicious, or accidental changes to information. (Section 1.6.2)

Delegation — Delegation allows a target object to impersonate a client when issuing requests to other target objects. (Section 1.6.3)

Authorization/Access Control — Authorization ensures that only authorized use of resources is allowed by matching an authenticated entity to established access control privileges. The target uses these methods to determine a client's access to an object. (Section 1.6.4)

Auditing and Logging — Auditing records unauthorized access or attempts to violate security. (Section 1.6.5)

1.6.1 How NetCrusader/CORBA Performs Authentication

A principal can authenticate to the NetCrusader/CORBA Security Server using a variety of methods, including Username/Password pair or Public Key credentials. Authentication is performed with standard (V5) Kerberos.

An application can use two methods to obtain credentials for a principal:

The application calls the NetCrusader/CORBA security services to create credentials and privilege attributes for the principal to use during the session.

During application startup, you use command-line arguments to pass in the principal name and password and request credentials for the principal (Figure 1-4). For more information, refer to the NetCrusader/CORBA Installation and Operation Guide.

Figure 1-4: Command-line Argument Authentication

The application can also obtain credentials for an unauthenticated principal at runtime by making an authenticate call to the ORB PrincipalAuthenticator interface (Figure 1-5). For more information, refer to the NetCrusader/CORBA Application Developer's Guide.

Figure 1-5: Authentication Through API Call

1.6.2 How NetCrusader/CORBA Ensures Secure Message Transport

NetCrusader/CORBA detects duplicated messages (replay detection), and provides message integrity by detecting changes to the data stream between the client and the target. NetCrusader/CORBA checks the order of messages to ensure that they all arrive, and that they arrive in the order in which they were sent.

NetCrusader/CORBA supports confidentiality by encapsulating each message with an authenticator. The entire authenticator is then Kerberos-encrypted with the current session key for transmission. Confidentiality is optional.

1.6.3 How NetCrusader/CORBA Performs Delegation

Delegation allows objects to access other objects on behalf of the client. You can set delegation policies for clients and for targets. The client's delegation policy determines whether the client will allow its identity to be used by a target. The target object's delegation policy determines whether the target uses its own identity when accessing other services, or uses the identity of the client.

NetCrusader/CORBA supports the following kinds of delegation:

Simple delegation (also called impersonation) — The intermediate object assumes the client's privileges, which it uses for access control decisions. The intermediate object can delegate the client's privileges to other objects. Only the client's privileges are passed to the target object, so that the intermediate objects remain unknown:
Composite delegation — The intermediate object can use the client's credentials and delegate the credentials to other objects. All intermediate objects' privileges are added to the client's privileges and passed to the target object, so that the chain of credentials is traced:
No delegation — You can also set the delegation mode to None, which means that an intermediate object in the call chain can use only its own credentials, not the client's credentials:

1.6.4 How NetCrusader/CORBA Performs Access Control

Access control means restricting or allowing user access to objects within a domain. Access control decisions occur on the target side by evaluating a client's access policy against an object's required rights.

The client's security attributes include access identification, audit identification, primary group identification, and other group identifications. These attributes are contained in the client's credentials.

Figure 1-6 illustrates how a client's access is determined when the client invokes a target object.

Figure 1-6: How Access is Determined

When a client makes a request, the security layer on the target side invokes the AccessDecision object. The client's effective rights are obtained from the domain's AccessPolicy object, and the interface's required rights are obtained from the interface's RequiredRights object.

Effective rights are the rights granted to a user or a group of users by the domain administrator. Effective rights are assigned to a policy, which is assigned to a domain.

Required rights are the rights that a client must have in order to access a particular operation on a CORBA interface. Required rights are properties that you assign to an interface's operations.

If the client's effective rights are sufficient to fulfill the interface's required rights, the client's request is granted.

You can create your own customized rights and rights families in addition to the standard rights NetCrusader/CORBA provides by default.

1.6.5 How NetCrusader/CORBA Performs Auditing

Auditing, shown in Figure 1-7, provides a means of monitoring the activity in a secure environment, allowing you to detect unauthorized access or attempts to violate security.

NetCrusader/CORBA supports auditing of principal authentication events, binding for a session, authorization events, and changes to security policies.

You can refine the conditions in which an event is audited by specifying selectors, such as the type of operation executed, the principal that initiated the event, the time or day of the week in which the event occurred, or whether the request succeeded or failed.

In addition, an application developer can add application-specific auditing calls so that the application manages its own security based on criteria that has meaning inside the application.

NetCrusader/CORBA determines whether an event should be audited by querying the domain's audit policies, and for auditable events, creates an audit record and forwards it to an audit log, which is written to a local file.