This chapter describes the security features enforced by the CIM Object Manager, including the following topics:
The CIM Object Manager validates a user's login information for the machine on which the CIM Object Manager is running. A validated user is granted some form of controlled access to the entire Common Information Model (CIM) Schema. The CIM Object Manager does not provide security for system resources such as individual classes and instances. However, the CIM Object Manager does allow control of global permissions on namespace and access control on a per-user basis.
All security-related information is represented by instances of security classes located in the root\Security namespace and must remain there permanently.
The following security features protect access to CIM objects on a WBEM-enabled system:
Authentication - The process of verifying the identity of a user, device, or other entity in a computer system, often as a prerequisite to allowing access to the resources in a system.
Authorization - The granting to a user, program, or process the right of access.
Replay protection - A client cannot copy another client's last message sent to a CIM Object Manager. The CIM Object Manager uses the client keys to guarantee that all subsequent communication in the client-server session is with the same client that initiated the session and participated in the client-server authentication.
The CIM Object Manager protects against a client picking up and sending another client's message to the server by validating digitally signed secret session keys. The CIM Object Manager will not accept an identical byte stream from a client without a valid secret session key.
Digital signature - The CIM Object Manager uses Java digital signature classes to digitally sign the clients response to the server, however it does not digitally sign the server's response to a client.
When a user logs in and enters a user name and password, the client encrypts the password and sends the encrypted password to the CIM Object Manager. When the user is authenticated, the CIM Object Manager sets up a client session. All subsequent operations occur within that secure client session.
The CIM Object Manager creates two user accounts:
wbemadmin - The administrative account used to access LDAP schema in the CIM Object Manager Repository. The wbemadmin account is created and its password is set during installation.
guest - The default account used when no user name is specified during login.
Once the CIM Object Manager has authenticated the user's identity, that identity can be used to verify whether the user should be allowed to execute the application or any of its tasks. The CIM Object Manager supports capability-based authorization, which allows an administrator to assign read and write access to specific users. These authorizations are added to existing Solaris user accounts.
We do not recommend logging in as root because successful login to the root account depends on how name services (for example, DNS, NIS, or NIS+) are set up on your system.
The Sun WBEM User Manager allows administrators to add and delete authorized users and to set their access privileges. Use this application to manage user authentication and access to CIM objects on a WBEM-enabled system. A user must have a Solaris user account.
You can set access privileges on individual users, on namespaces, or on both. When you add a user, you select a namespace. This action grants the user read access to CIM objects in the selected namespace.
Administrators are users who are logged in to the WBEM administrative account, wbemadmin. Administrators can set the following types of access to CIM objects:
Read Only - Allows read-only access to CIM Schema objects. Users with this privilege can retrieve instances and classes, but cannot create, delete, or modify CIM objects.
Read/Write - Allows full read/write/delete access to all CIM classes and instances.
Write - Allows write and delete, but not read access to all CIM classes, and instances.
None - Allows no access to CIM classes and instances.
In a command window, type the command:
% /opt/SUNWconn/wbem/bin/cimadmin |
The Sun WBEM User Manager is started. The User Manager and Login dialog boxes are displayed at the same time. The Login dialog box shows the name of the current host. Context-help information is available on the fields in the dialog box.
In the Login dialog box, do the following:
In the Host Name field, type the name of a host running the CIM Object Manager.
In the User Name field, type wbemadmin. You must log in to the administrative account to administer WBEM user accounts.
In the Password field, type the password for the wbemadmin account.
Click OK.
The User Manager dialog box opens with a list of users and their access rights to WBEM objects within the namespaces on the current host.
Start Sun WBEM User Manager.
In the Users Access portion of the dialog box, click Add.
A dialog box opens that lists the available namespaces.
Type the name of a Solaris user account in the User Name text entry field.
Select a namespace from the listed namespaces.
Click OK.
This action grants this user read access to CIM objects in the selected namespace. The user is added to the User Manager dialog box.
Click OK again to close the User Manager dialog box.
Start Sun WBEM User Manager.
Select the user whose access rights you want to change.
To grant the user read-only access, click the Read check box. To grant the user write access, click the Write check box.
Click OK.
Start Sun WBEM User Manager.
In the Users Access portion of the dialog box, select the user name for which you want to remove access rights.
Click Delete to delete the user's access rights to the namespace.
A confirmation dialog box asks you to confirm your decision to delete the user's access rights. Click OK to confirm.
Click OK again to close the User Manager dialog box.
Start Sun WBEM User Manager.
In the Namespace Access portion of the dialog box, click Add.
A dialog box opens that lists the available namespaces.
Select the namespace for which you want to set access rights.
By default, users have read-only access to a namespace.
To allow no access to the namespace, make sure the Read and Write check boxes are not selected. To allow write access, click the Write check box. To allow read access, click the Read check box.
Click OK to close the User Manager dialog box.
Start Sun WBEM User Manager.
In the Namespace Access portion of the dialog box, select the namespace for which you want to remove access control, and then click Delete.
Access control is removed from the namespace, and the namespace is removed from the list of namespaces on the User Manager dialog box.
Click OK to close the User Manager dialog box.
You can use the Sun WBEM SDK APIs to set access control on a namespace or on a per-user basis. During installation, the MOF compiler compiles the security classes defined in the Solaris_Acl1.0.mof file into the /root/Security namespace. The Solaris_Acl1.0.mof file defines the following classes:
Solaris_Acl - Base class for Solaris Access Control Lists (ACL). This class defines the string property capability and sets its default value to r (read only).
Solaris_UserAcl - Represents the access control that a user has to the CIM objects within the specified namespace.
Solaris_NamespaceAcl - Represents the access control on a namespace.
You can set access control on individual users to the CIM objects within a namespace by creating an instance of the Solaris_UserACL class and then using the APIs to change the access rights for that instance. Similarly, you can set access control on namespaces by creating an instance of the Solaris_NameSpaceACL class and then using APIs, such as the setInstance method, to set the access rights for that instance.
An effective way to combine the use of these two classes is to first use the Solaris_NameSpaceACL class to restrict access to all users to the objects in a namespace. Then use the Solaris_UserACL class to grant selected users access to the namespace.
Access Control Lists (ACL) are governed by a standard being developed by the DMTF. Although the Solaris ACL schema are currently CIM-compliant, they will need to change when the DMTF finalizes the ACL standard. Programs you write using the Solaris ACL schema classes are subject to that risk.
The Solaris_UserAcl class extends the Solaris_Acl base class, from which it inherits the string property capability with a default value r (read only).
You can set the capability property to any of the following 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 namespace-username ACL pair can exist in a namespace.
Property | Data Type | Purpose |
---|---|---|
nspace |
string |
Identifies the namespace to which this ACL applies. |
username |
string |
Identifies the user to which this ACL applies. |
Create an instance of the Solaris_UserAcl class. For example:
// Get the Solaris_UserAcl class cimclass = cc.getClass(newCIMObjectPath("Solaris_UserAcl"); // Create a new instance of the Solaris_UserAcl class ci = cimclass.newInstance();
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 namespace. ci.updatePropertyValue("capability",new CIMValue("rw")); ci.updatePropertyValue("nspace",new CIMValue("root\molly")); ci.updatePropertyValue("username",new CIMValue("guest"));
Update the instance. For example:
// Pass the updated instance to the CIM Object Manager cc.setInstance(new CIMObjectPath(), ci);
The Solaris_NamespaceAcl extends the Solaris_Acl base class, from which it inherits the string property capability with a default value r (read-only for GUEST and all users). The Solaris_NamespaceAcl class defines the following key property.
Property | Data Type | Purpose |
---|---|---|
nspace |
string |
Identifies the namespace to which this access control list applies. Only one instance of the namespace ACL can exist in a namespace. |
Create an instance of the Solaris_namespaceAcl class. For example:
// Get the Solaris_namespaceAcl class cimclass = cc.getClass(newCIMObjectPath("Solaris_namespaceAcl"); // Create a new instance of the Solaris_namespaceAcl class ci = cimclass.newInstance();
Set the capability property to the desired access rights. For example:
/* Change the access rights (capability) to read/write to the root\molly namespace. */ ci.updatePropertyValue("capability",new CIMValue("rw")); ci.updatePropertyValue("nspace",new CIMValue("root\molly"));
Update the instance. For example:
// Pass the updated instance to the CIM Object Manager cc.setInstance(new CIMObjectPath(),ci);
For a description of error messages, see Chapter 9, Error Messages.