test

Solaris WBEM Developer's Guide

Chapter 8 Administering Security

This chapter describes WBEM security mechanisms and the features that the CIM Object Manager (CIMOM) enforces.

This chapter includes the following information:

WBEM Security Mechanisms

WBEM employs several mechanisms to ensure secure access to its data:

Each mechanism is described in more detail in the sections that follow.

Client Authentication

When a client application connects to a CIMOM server, the client's user identity must be authenticated by the CIMOM on the WBEM server. The user's WBEM client must provide a Solaris OS user identity and its associated login password. The identity and credential are used in a security authentication exchange between the client and WBEM server. This exchange is to verify that the client is a valid Solaris OS user who is allowed to log in to the WBEM server system.

If the WBEM server cannot verify the user identity and credential and the user's identity is invalid, the WBEM server returns a CIM security exception. This exception includes the NO_SUCH_PRINCIPAL error.

If the WBEM server cannot verify the user's identity and credential and the user's password is invalid, the server returns a CIM security exception. This exception includes the INVALID_CREDENTIAL error.

Role Assumption

A role identity can be assumed only when a WBEM user selects the Remote Method Invocation (RMI) protocol. Role assumption is not supported by the XML over HTTP protocol.

The Solaris platform implementation of WBEM supports the ability of a client to assume the identity of a Solaris OS role. When a client assumes the identity of a Solaris OS role, the client is authenticated by the CIMOM on the WBEM server. To check RBAC authorizations, the WBEM server uses the permission that is granted to the assumed role rather than the permission that is granted to the underlying user identity.

RBAC roles are described in more detail in Role-Based Access Control (Overview) in System Administration Guide: Security Services.

The client must provide the Solaris OS role identity and password in addition to a Solaris OS user identity and password when the client attempts to connect.

If the WBEM server cannot verify the Solaris OS role identity, the WBEM server returns a CIM security exception that includes the NO_SUCH_ROLE error.

If the role password is invalid for the specified role identity, the WBEM server returns the INVALID_CREDENTIAL error in the CIM security exception.

If both the role identity and role password are valid, but the user is not allowed to assume the role, the WBEM server returns an exception. The CANNOT_ASSUME_ROLE error is returned in the CIM security exception.

Secure Messaging

In the CIM RMI protocol, each request from the client to the WBEM server contains a message authenticator that is constructed from the message data. A one-way digest is also created with a session key that is established during the authentication exchange.

The WBEM server verifies this message authenticator. This verification guarantees two things: The request came from the same client that was authenticated The message was not modified or replayed on its way to the server

If the message was modified, replayed, or created by a source that was not the original client, the WBEM server returns a CIM security exception. This exception contains the CHECKSUM_ERROR error. The WBEM server also writes a log message to the WBEM log.

Authorization

After connecting, the server uses the authenticated user or the role identity for all authorization checks on subsequent operations with the CIM client.

WBEM supports two types of authorization checking, using the following mechanisms:

The particular authorization checking mechanism that WBEM uses depends on how the MOF class provider is implemented. The particular authorization checking mechanism that WBEM uses for a specific MOF class operation depends on the following factors:

The classes defined in Solaris_Acl.mof implement WBEM ACL-based security. WBEM ACL-based security provides a default authorization scheme for Solaris WBEM Services. Under specific circumstances, WBEM-based security applies to a particular set of CIM operations. ACL-based security is uniquely provided by Solaris WBEM Services.

You use Sun WBEM User Manager (wbemadmin) to establish an ACL for a specific name space on the WBEM server. Sun WBEM User Manager enables you to add user, or role, names to the ACL for the name space. In addition, you can assign each user read or write permission. Sun WBEM User Manager is described in Using Sun WBEM User Manager to Set Access Control and in wbemadmin(1M).

Write permission allows a user to modify the class metadata, modify instances of MOF classes in that name space, and issue an invoke method on instances. The local WBEM server root user identity is always granted write permission to all name spaces on the server. All authenticated users without an explicit ACL entry are granted read permission by default.

Operations that include the accessing of MOF class metadata, such as getClass, use the WBEM ACLs. These operations check the permissions that are granted to the authenticated user by the ACL for the name space that contains the MOF class. You can set an RBAC role in an ACL entry. However, the ACL entry is always checked against the user identity rather than the role identity. In other words, you can set a role name in an ACL, but the CIMOM does not check the role name at runtime.

Operations that involve MOF class instances might include the checking of either WBEM ACLs or RBAC authorizations.

You can also grant permissions to a user, or role identity, which allow that user to access and modify the instances of MOF classes, whose providers use RBAC authorizations. You grant these permissions by using the Rights tool in the Solaris Management Console User tool. The granting of permissions to a user is described in Creating or Changing a Rights Profile in System Administration Guide: Security Services.

If the instances for a MOF class are stored in the WBEM persistent datastore, the CIMOM checks the WBEM ACL for the name space that contains the MOF class. Under the following conditions, the implementation of the MOF class provider almost always uses RBAC authorization checking:

In general, if a MOF class definition contains a Provider qualifier, the provider implementation usually makes RBAC authorization checks. If the MOF class definition does not contain a Provider qualifier, the CIMOM takes the following actions:

Auditing

The WBEM server writes audit records for certain events during processing. For example, the WBEM server writes audit records whenever client authentication succeeds or fails, and whenever an operation that modifies user information is executed.

The WBEM server uses the underlying Solaris Basic Security Module (BSM) to write its audit records. You must enable the BSM auditing mechanism (bsmconv) in the Solaris OS on the WBEM server to ensure that audit information is recorded. This command is described in bsmconv(1M).

Note –

If you are using the Trusted SolarisTM software, you do not need to enable the BSM auditing mechanism.

Logging

The WBEM server writes log records to the WBEM log for particular security events. Two examples are when an authenticated session for a client is established and when an authorization fails. You can review the WBEM log in the Solaris Management Console Log Viewer, which is described in Chapter 9, Troubleshooting.

You can identify security-related log events by the category Security log, which is listed in the Category column. You can view only security log messages by selecting the category Security in the Log Viewer filter dialog box. Most security log messages include the user identity of the client and the name of the client host.

Using Sun WBEM User Manager to Set Access Control

Sun WBEM User Manager (wbemadmin) enables you and other privileged users to perform the following tasks:

Note –

The user for whom you specify access control must have a Solaris OS user account.

What You Can and Cannot Do With Sun WBEM User Manager

You can set access privileges for individual name spaces or for a combination of a user and a name space. When you add a user and select a name space, the user is granted read access to CIM objects in the selected name space by default.

Note –

An effective way to combine user and name space access rights is to start by restricting access to a name space. Then grant individual users read, read and write, or write access to that name space.

You cannot set access rights on individual managed objects. However, you can set access rights for all managed objects in a name space as well as on a per-user basis.

If you log in as root, you can set the following types of access to CIM objects:

Using Sun WBEM User Manager

This section describes how to start and use Sun WBEM User Manager.

ProcedureHow to Start Sun WBEM User Manager

Steps

  1. Become superuser.

  2. In a command window, type the following command:


    # /usr/sadm/bin/wbemadmin

    Sun WBEM User Manager starts, and a Login dialog box opens.

    Note –

    Context-help information is available in the Context Help panel when you click on the fields in the Login dialog box.

  3. Fill in the fields on the Login dialog box.

    1. In the User Name field, type the user name.

      Note –

      You must have read access to the root\security name space to log in. By default, Solaris OS users have guest privileges, which grant them read access to the default name spaces. Users with read access can view but not change user privileges.

      You must log in as root or a user with write access to the root\security name space to grant access rights to users.

    2. In the Password field, type the password for the user account.

  4. Click OK.

    The User Manager dialog box opens. The dialog box contains a list of users and their access rights to WBEM objects within the name spaces on the current host.

ProcedureHow to Grant Default Access Rights to a User

Steps

  1. Start Sun WBEM User Manager.

  2. In the Users Access portion of the dialog box, click Add.

    A dialog box opens that lists the available name spaces.

  3. Type the name of a Solaris OS user account in the User Name field.

  4. Select a name space from the listed name spaces.

  5. Click OK.

    The user name is added to the User Manager dialog box.

  6. To save changes and close the User Manager dialog box, click OK. To save changes and keep the dialog box open, click Apply.

    The user that you specified is granted read access to CIM objects in the name space that you selected.

ProcedureHow to Change Access Rights for a User

Steps

  1. Start Sun WBEM User Manager.

  2. Select the user whose access rights you want to change.

  3. Set the user privileges. To grant the user read-only access, click the Read check box. To grant the user write access, click the Write check box.

  4. To save changes and close the User Manager dialog box, click OK. To save changes and keep the dialog box open, click Apply.

ProcedureHow to Remove Access Rights for a User

Steps

  1. Start Sun WBEM User Manager.

  2. In the Users Access portion of the dialog box, select the user name for which you want to remove access rights.

  3. Click Delete to delete the user's access rights to the name space.

    A confirmation dialog box opens. This dialog box prompts you to confirm your decision to delete the user's access rights.

  4. To confirm, click OK.

  5. To save changes and close the User Manager dialog box, click OK. To save changes and keep the dialog box open, click Apply.

ProcedureHow to Set Access Rights for a Name Space

Steps

  1. Start Sun WBEM User Manager.

  2. In the Namespace Access portion of the dialog box, click Add.

    A dialog box opens. The dialog box lists the available name spaces.

  3. Select the name space for which you want to set access rights.

    Note –

    By default, users have read-only access to a name space.

    • To allow no access to the name space, make sure that the Read and Write check boxes are not selected.

    • To allow write access, select Write.

    • To allow read access, select Read.

  4. To save changes and close the User Manager dialog box, click OK. To save changes and keep the dialog box open, click Apply.

ProcedureHow to Remove Access Rights for a Name Space

Steps

  1. Start Sun WBEM User Manager.

  2. In the Namespace Access portion of the dialog box, select the name space for which you want to remove access control, and then click Delete.

    Access control is removed from the name space, and the name space is removed from the list of name spaces on the Sun WBEM User Manager dialog box.

  3. To save changes and close the User Manager dialog box, click OK. To save changes and keep the dialog box open, click Apply.

Using the Solaris WBEM SDK APIs to Set Access Control

You can use the WBEM SDK's application programming interfaces (SDK APIs) to set access control on a name space or on a per-user basis. These security classes are stored in the root\security name space:

You can set access control for individual users to the CIM objects within a name space by creating an instance of the Solaris_UserACL class. Then use the APIs to change the access rights for that instance. Similarly, you can set access control for name spaces by first creating an instance of the Solaris_NameSpaceACL class. Then using APIs, such as the createInstance method, to set the access rights for that instance.

You can combine the use of these two classes. First, use the Solaris_NameSpaceACL class to restrict access to all users for the objects in a name space. Then, use the Solaris_UserACL class to grant selected users access to the name space.

Solaris_UserAcl Class

The Solaris_UserAcl class inherits the string property capability with a default value r (read only) from theSolaris_Acl class.

You can set the capability property to any one of these values for access privileges.

Access Right 

Description 

r

Read 

rw

Read and Write 

w

Write 

none 

No access 

The Solaris_UserAcl class defines the following two key properties. Only one instance of the name space and user-name ACL pair can exist in a name space.

Property 

Data Type 

Purpose 

nspace

string

Identifies the name space to which this ACL applies 

username

string

Identifies the user to which this ACL applies 

ProcedureHow to Set Access Control for a User

Steps

  1. Create an instance of the Solaris_UserAcl class.

    For example:

    ... 
/* Create a name space object initialized with root\security
(name of name space) on the local host. */

CIMNameSpace cns = new CIMNameSpace("", "root\security");

// Connect to the root\security name space as root. 
cc = new CIMClient(cns, user, user_passwd);

// Get the Solaris_UserAcl class 
cimclass = cc.getClass(new CIMObjectPath("Solaris_UserAcl");

// Create a new instance of the Solaris_UserAcl
class ci = cimclass.newInstance();
...

  2. Set the capability property to the desired access rights.

    For example:

    ...
/* Change the access rights (capability) to read/write for user Guest
on objects in the root\molly name space.*/
ci.setProperty("capability", new CIMValue(new String("rw")); 
ci.setProperty("nspace", new CIMValue(new String("root\molly")); 
ci.setProperty("username", new CIMValue(new String("guest"));
...

  3. Update the instance.

    For example:

    ...
// Pass the updated instance to the CIM Object Manager 
cc.createInstance(new CIMObjectPath(), ci);
...

Solaris_NamespaceAcl Class

The Solaris_NamespaceAcl inherits the string property capability with a default value r (read-only for all users) from the Solaris_Acl class. The Solaris_NamespaceAcl class defines this key property.

Property 

Data Type 

Purpose 

nspace

string

Identifies the name space to which this access control list applies. Only one instance of the name space ACL can exist in a name space. 

ProcedureHow to Set Access Control for a Name Space

Steps

  1. Create an instance of the Solaris_NamespaceAcl class.

    For example:

    ...
/* Create a name space object initialized with root\security
(name of name space) on the local host. */ 
CIMNameSpace cns = new CIMNameSpace("", "root\security");

// Connect to the root\security name space as root.
cc = new CIMClient(cns, user, user_passwd);

// Get the Solaris_namespaceAcl class 
cimclass = cc.getClass(new CIMObjectPath("Solaris_namespaceAcl");

// Create a new instance of the Solaris_namespaceAcl 
class ci = cimclass.newInstance();
...

  2. Set the capability property to the desired access rights.

    For example:

    ...
/* Change the access rights (capability) to read/write 
to the root\molly name space. */
ci.setProperty("capability", new CIMValue(new String("rw")); 
ci.setProperty("nspace", new CIMValue(new String("root\molly"));
...

  3. Update the instance.

    For example:

    // Pass the updated instance to the CIM Object Manager 
cc.createInstance(new CIMObjectPath(), ci);

Troubleshooting Problems With WBEM Security

This section describes what to do in the following situations:

If a Client (User) Cannot Be Authenticated by the CIMOM on the WBEM Server

If a client cannot be successfully authenticated by the CIMOM on the WBEM server, the WBEM server returns a CIM security exception. This exception is returned when the server attempts to establish the CIM client handle in the client application. The exception contains an error code that indicates why the authentication attempt failed.

If the WBEM server cannot verify the user identity and credential and the user's identity is invalid, the WBEM server returns a CIM security exception. This exception includes the NO_SUCH_PRINCIPAL error. If the WBEM server cannot verify the user's identity and credential and the user's password is invalid for that user's identity, the WBEM server returns a CIM security exception. This exception includes the INVALID_CREDENTIAL error.

If the WBEM server cannot verify the Solaris OS role identity, the WBEM server returns a CIM security exception that includes the NO_SUCH_ROLE error.

If the role password is invalid for the specified role identity, the WBEM server returns the INVALID_CREDENTIAL error in the CIM security exception.

If both the role identity and role password are valid but the user is not allowed to assume the role, the WBEM server returns the CANNOT_ASSUME_ROLE error in the CIM security exception.

These CIM security exceptions are described in more detail in the following table.

Error 

Probable Cause 

Solution 

NO_SUCH_PRINCIPAL

Specified user identity was not valid in the Solaris OS on the WBEM server.  

The user account for that user identity has no password. 

The user account for that user identity is locked. 

Check that the user has a valid user identity. In other words, ensure that the user can log in to the Solaris OS on the WBEM server machine. You might also need to check the name service tables. This check is to determine whether the Solaris WBEM server might be using user identities from a name service configured on the server. 

INVALID_CREDENTIAL

Password for the specified user, or assumed role, is not valid for that user in the Solaris OS on the WBEM server. 

Check that the user's password is correct. 

NO_SUCH_ROLE

Role identity that is used for authentication to the WBEM server is not a valid RBAC role in the Solaris OS on that server. 

The role identity might be valid in the passwd table on the server, but you cannot log into the server using that identity. The Solaris software does not allow you to log in directly to role identities. You must check the passwd table for the role identity, and check theuser_attrtable to ensure that the role is defined as type user. Role identities in the user_attr table contain an attribute in the syntax type=role.

You can also check for a valid user or valid role identity by using the Solaris Management Console User tool. You can use User Management to check for a user, and you can use Role Management to check for a role. However, when using the User tool, you must know the correct source of the tables on the CIMOM server. In other words, if the CIMOM server is using a name service such as NIS, you must access the master server for that name service.

CANNOT_ASSUME_ROLE

Role identity is valid, but the specified user identity in the authentication exchange is not configured to assume that role. 

Assign users to roles by using the Administrative Role tool in the Solaris Management Console User tool collection, which is described in How to Change the Properties of a Role in System Administration Guide: Security Services.

If Other CIM Security Exceptions Appear

The WBEM server can return other error indications in the CIM security exception. However, these indications typically identify a system failure in the authentication exchange. The WBEM client configuration might not be compatible with the WBEM server configuration for the security options in the authentication exchange.

If these error indications occur, check the client application CLASSPATH setting to ensure that sunwbem.jar and the extension directory are in the CLASSPATH.

If an Authorization Check Fails

If a client is not authorized to access or modify the data associated with a request to the WBEM server, that server returns a CIM security exception. This exception includes the ACCESS_DENIED error.

The ACCESS_DENIED error indicates that a request could not be completed because the user or role does not have access to the data managed by that request.

Check the security messages in the WBEM log for the failed request. For information about viewing log data, see Viewing Log Data Through Log Viewer. Authorization failure messages in the WBEM log specify Access denied in the Summary column. The User column lists the name of the authenticated user or the role name that was used in the check. The Source column lists the name of the provider that is making the check. Note that the provider name that is listed in this column is not the class of the provider implementation, but a user-friendly provider name.

The detailed message contains the name of the permission that was being checked, and that permission has not been granted to the user or role.

If the permission appears as namespace:right, the authorization check was using a name space ACL. The authenticated user has not been granted that permission (read or write) for that name space.

Use Sun WBEM User Manager (wbemadmin) to grant the user the appropriate permission. Sun WBEM User Manager is described in Using Sun WBEM User Manager to Set Access Control.

If the permission appears as solaris.application.right, the authorization check was using an RBAC authorization.

Use the Administrative Role tool in the Solaris Management Console User tool collection to grant the rights that you want to the user or role. This procedure is described in How to Change the Properties of a Role in System Administration Guide: Security Services.