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, using the following mechanisms:

• 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 following factors:

• The particular operation that WBEM executes

• How the MOF class provider is implemented

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 namespace on the WBEM server. Sun WBEM User Manager enables you to add user, or role, names to the ACL for the namespace. 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 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 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, 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 CIMOM checks the WBEM ACL for the namespace that contains the MOF class. Under the following conditions, the implementation of the MOF class provider almost always uses RBAC authorization checking:

• The MOF class provider implementation accesses the provider's datastore

• The MOF class provider implementation accesses system data in the Solaris operating environment

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:

• 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