1 — Common Operations

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

This chapter describes how to implement the CORBA security specification Application Programming Interfaces (APIs) in the Java application you are developing. NetCrusader/CORBA includes security APIs for Java for Inprise VisiBroker.

NOTE: NetCrusader/CORBA supports the APIs in Version 1.5 of the CORBA Security Service. Some Version 1.7 operations are also supported.

This chapter describes some common operations that you may want to include in your application, and provides code samples for these operations.

This chapter contains the following sections:

1.1 Initializing the Security Service
1.2 Resolving Initial References
1.3 Obtaining a Client's Privilege Attributes
1.4 Obtaining the Client's Identity
1.5 Using the PrincipalAuthenticator Interface
1.6 Getting Effective Rights
1.7 Controlling Delegation in a Server

1.1 Initializing the Security Service

When your application starts, it must initialize the security service for any security functionality to work.

In the VisiBroker environment, NetCrusader/CORBA automatically registers its client- and server-side interceptors with the ORB when you include com.gradient.NetCCorba in the list of initial services.

Start the application with the following command-line option or set this parameter in the System properties prior to initializing the ORB:

-DORBservices=com.gradient.NetCCorba

No changes to the application source itself are necessary.

1.2 Resolving Initial References

Your application can use the Current object to obtain information about the state associated with the current execution context. To do so:

1. Use the ORB call resolve_initial_references and pass in the name SecurityCurrent.

2. When the object reference is returned, narrow it to SecurityLevel1::Current, SecurityLevel2::Current, or SecurityExtension::GradCurrent.

org.omg.SecurityLevel2.Current current = null;
try
{
    current = (org.omg.SecurityLevel2.Current)

orb.resolve_initial_references(org.omg.SecurityExtension.current_identifier.
value);
}
catch(org.omg.CORBA.ORBPackage.InvalidName in)
{
    //exception handling code 
}

A server application can use a client's credentials, which contain privilege attributes, to make access control decisions. Privilege attributes include security information such as a client's audit identity, the groups to which the client belongs, roles assigned to the client, and so on. Privilege attributes are maintained in the client's Credentials object.

Applications can retrieve a client's privilege attributes, or retrieve its own security attributes, using the operation get_attributes on the Current interface. This can allow security-unaware applications to enforce their own security policies without having to perform operations on the Credentials object.

This is the only operation supported on the SecurityLevel1::Current interface.

• If a match exists for the attribute type requested, the attribute is placed in the returned AttributeList.

• If you leave the inbound AttributeTypeList empty, all available attributes are returned.

• If none of the requested attribute types are available, the returned AttributeList is empty.

See Appendix A for details about attribute types.

Java

org.omg.Security.SecAttribute[] get_attributes(
    org.omg.Security.AttributeType[] attributes
    );

This section describes how a server obtains a client's identity (audit ID). This procedure is similar to the procedure for obtaining the client's privilege attributes (Section 1.3), but is more specific in that it retrieves only the audit ID from the client's Credentials object.

This operation is available to both SecurityLevel1 and SecurityLevel2 applications.

To obtain a client's identity:

1. Get a handle to the Current interface.

2. Build an attribute type list that tells the system that you want to get the client's audit ID.

3. Call get_attributes on Current.

4. If you want to print the name, clarify the opaque field. For Java, clarification is not required because opaques map to byte arrays.

org.omg.SecurityLevel2.Current current = null;
try
{
    current = (org.omg.SecurityLevel2.Current)

orb.resolve_initial_references(org.omg.SecurityExtension.current_identifier.
value);
}
catch(org.omg.CORBA.ORBPackage.InvalidName in)
{
    //exception handling code
}

org.omg.Security.AttributeType[] types = new 
org.omg.Security.AttributeType[1];
org.omg.Security.ExtensibleFamily family = new \ 
org.omg.Security.ExtensibleFamily(org.omg.SecurityExtension.SecFamilyDefiner
OMG.value, \ org.omg.SecurityExtension.SecFamilyOther.value);
types[0] = new org.omg.Security.AttributeType(family, 
org.omg.Security.AuditId.value);

SecAttribute[] attributes = current.get_attributes(types);

String auditName = new String(attributes[0].value);

Clients must have credentials before they can make requests in a secure system. In some cases, the client is authenticated and receives credentials by logging into the system.

In other cases, clients are unauthenticated at the time they call the application. You may want your application server to authenticate and provide default credentials for these clients.

Or, you may want to allow access to unauthenticated clients. In this case, the application must still create a Credentials object that the unauthenticated client uses during the session.

This section shows how to use the PrincipalAuthenticator interface to give your application server these capabilities.

To use the PrincipalAuthenticator interface:

1. Get a handle to the Current object.

2. Call the method principal_authenticator() on Current.

//get current handle code

org.omg.SecurityLevel2.PrincipalAuthenticator principalAuthenticator = 
    current.principal_authenticator();

This section describes how a security-aware application server would obtain a client's effective rights directly from the AccessPolicy object.

To obtain a client's effective rights:

1. Get a handle to Current.

2. Get a handle to the access policy object by calling get_policy(int policyType) on Current, with policy type = Access Policy.

3. Call get_all_effective_rights() on the Access Policy object.

//get current handle code

org.omg.SecurityAdmin.AccessPolicy policy = 
    (org.omg.SecurityAdmin.AccessPolicy)
current.get_policy(org.omg.Security.SecTargetInvocationAccess.value); 

org.omg.Security.Right[] rights = policy.get_effective_rights();

This section describes how an application server would control whether to use its own credentials or use the inititator's credentials.

To control a server's use of delegation:

1. Get a handle to Current.

2. Call own_credentials() or received_credentials() on current, to get the server's credentials or the received credentials, respectively.

3. Call set_credentials on current, using the credentials obtained in step 2.

// get current handle code

// to use own credentials

  org.omg.SecurityLevel2.Credentials[] own_creds =
        current.own_credentials();

  current.set_credentials(CredentialType.SecInvocationCredentials,
        own_creds, DelegationDirective.NoDelegate);

// to use received credentials

  org.omg.SecurityLevel2.Credentials[] received_creds =
        current.received_credentials();

  current.set_credentials(CredentialType.SecInvocationCredentials,
        received_creds, DelegationDirective.NoDelegate);

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

To make comments or ask for help, contact support@gradient.com.

Copyright © 1999 Gradient Technologies, Inc.