Chapter 4

Administering Security (Tasks)

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

Here is a list of the information in this chapter.

WBEM Security Mechanisms

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

Authentication - The process of specifying a client's user identity to the WBEM server, and then demonstrating that that client really is that particular user by specifying the user's credentials.
Role assumption - The process of assuming that a Solaris Role-Based Access Control (RBAC) role identity is to be used by the WBEM server when it checks authorization.
Secure messaging - The process of adding a secure message authenticator to each client request message. This authenticator enables the WBEM server to check the origin of the message and to determine if that message was modified during its delivery to the WBEM server.
Authorization - The process of verifying that an authenticated user or a role identity has been granted access to the WBEM data that is managed by each WBEM method call. You use the Solaris Management Console User tool and Sun WBEM User Manager for authorization management.
Auditing - The process of writing an audit record of a specific operation that was performed by the WBEM server. These records track the changes that an authenticated user makes to the management data on the WBEM server system.
Logging - The writing of particular security-related events in the WBEM log. You can view the WBEM log by using the Solaris Management Console Log Viewer.

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

Authentication

When a client application connects to a CIM Object Manager server, the client's user identity must be authenticated by the CIM Object Manager on the WBEM server. The user's WBEM client must provide a Solaris user identity and its accompanied login password. The identity and credential are used in a security authentication exchange between the client and WBEM server to verify that the client is a valid Solaris 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 that 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 that 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/HTTP protocol.

The Solaris implementation of WBEM supports the ability of a client to assume the identity of a Solaris role when that client is authenticated by the CIM Object Manager on the WBEM server. When the WBEM server uses RBAC authorizations to check authorization permission, the WBEM server checks 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 role identity and password, in addition to a Solaris user identity and password when the client attempts to connect.

If the WBEM server cannot verify the Solaris 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.

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 data parameters in the message. A one-way digest is also created with a session key established during the authentication exchange.

The WBEM server verifies this message authenticator, which guarantees that the request came from the same client that was authenticated and that the message was not modified or replayed during its communications 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 that contains the CHECKSUM_ERROR error. The WBEM server also writes a log message to the WBEM log.

Authorization

After the WBEM server connects, the WBEM 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, based on:

Access control lists (ACLs) that are maintained by the WBEM server for specific namespaces
RBAC authorizations that are configured as part of the Solaris operating environment

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 particular operation that WBEM executes
How the MOF class provider is implemented

The classes defined in Solaris_Acl1.0.mof implement WBEM ACL-based security. WBEM ACL-based security provides a default authorization scheme for Solaris WBEM Services, and, under specific circumstances, 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 namespace on the WBEM server. Sun WBEM User Manager enables you to add user names, or role names, to the ACL for the namespace, and to 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 namespace, and issue an invoke method on instances. The local WBEM server root user identity is always granted write permission to all namespaces 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 include the checking of permissions that are granted to the authenticated user by the ACL for the namespace that contains the MOF class. You can set an RBAC role in an ACL entry, but 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 CIM Object Manager 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, that allow that user to access and modify the instances of MOF classes whose providers use the 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 CIM Object Manager checks the WBEM ACL for the namespace that contains the MOF class. If the MOF class provider implementation accesses the provider's datastore, or accesses system data in the Solaris operating environment, the MOF class provider implementation 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 CIM Object Manager:

Stores the instances of that class in the WBEM persistent datastore
Checks the ACL that controls access to the namespace for the class to ensure that access is granted


	Chapter 4 Administering Security (Tasks) This chapter describes WBEM security mechanisms and the features that the CIM Object Manager enforces. Here is a list of the information in this chapter. "Using Sun WBEM User Manager (Task Map)" "WBEM Security Mechanisms" "Using Sun WBEM User Manager to Set Access Control" "Troubleshooting Problems With WBEM Security" WBEM Security Mechanisms WBEM employs several mechanisms to ensure secure access to its data, including: Authentication - The process of specifying a client's user identity to the WBEM server, and then demonstrating that that client really is that particular user by specifying the user's credentials. Role assumption - The process of assuming that a Solaris Role-Based Access Control (RBAC) role identity is to be used by the WBEM server when it checks authorization. Secure messaging - The process of adding a secure message authenticator to each client request message. This authenticator enables the WBEM server to check the origin of the message and to determine if that message was modified during its delivery to the WBEM server. Authorization - The process of verifying that an authenticated user or a role identity has been granted access to the WBEM data that is managed by each WBEM method call. You use the Solaris Management Console User tool and Sun WBEM User Manager for authorization management. Auditing - The process of writing an audit record of a specific operation that was performed by the WBEM server. These records track the changes that an authenticated user makes to the management data on the WBEM server system. Logging - The writing of particular security-related events in the WBEM log. You can view the WBEM log by using the Solaris Management Console Log Viewer. Each mechanism is described in more detail in the sections that follow. Authentication When a client application connects to a CIM Object Manager server, the client's user identity must be authenticated by the CIM Object Manager on the WBEM server. The user's WBEM client must provide a Solaris user identity and its accompanied login password. The identity and credential are used in a security authentication exchange between the client and WBEM server to verify that the client is a valid Solaris 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 that 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 that 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/HTTP protocol. The Solaris implementation of WBEM supports the ability of a client to assume the identity of a Solaris role when that client is authenticated by the CIM Object Manager on the WBEM server. When the WBEM server uses RBAC authorizations to check authorization permission, the WBEM server checks 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 role identity and password, in addition to a Solaris user identity and password when the client attempts to connect. If the WBEM server cannot verify the Solaris 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. 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 data parameters in the message. A one-way digest is also created with a session key established during the authentication exchange. The WBEM server verifies this message authenticator, which guarantees that the request came from the same client that was authenticated and that the message was not modified or replayed during its communications 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 that contains the `CHECKSUM_ERROR` error. The WBEM server also writes a log message to the WBEM log. Authorization After the WBEM server connects, the WBEM 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, based on: Access control lists (ACLs) that are maintained by the WBEM server for specific namespaces RBAC authorizations that are configured as part of the Solaris operating environment 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 particular operation that WBEM executes How the MOF class provider is implemented The classes defined in `Solaris_Acl1.0.mof` implement WBEM ACL-based security. WBEM ACL-based security provides a default authorization scheme for Solaris WBEM Services, and, under specific circumstances, 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 namespace on the WBEM server. Sun WBEM User Manager enables you to add user names, or role names, to the ACL for the namespace, and to 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 namespace, and issue an invoke method on instances. The local WBEM server `root` user identity is always granted write permission to all namespaces 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 include the checking of permissions that are granted to the authenticated user by the ACL for the namespace that contains the MOF class. You can set an RBAC role in an ACL entry, but 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 CIM Object Manager 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, that allow that user to access and modify the instances of MOF classes whose providers use the 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 CIM Object Manager checks the WBEM ACL for the namespace that contains the MOF class. If the MOF class provider implementation accesses the provider's datastore, or accesses system data in the Solaris operating environment, the MOF class provider implementation 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 CIM Object Manager: Stores the instances of that class in the WBEM persistent datastore Checks the ACL that controls access to the namespace for the class to ensure that access is granted