Notes on OpenWBEM ACLs (Access Control Lists).
==============================================

ACLs are implemented with namespace granularity.  In order
to activate the ACLs:
 - Turn on the super-user. Edit the config file and enter your username
   for the owcimomd.ACL_superuser config item. Restart the daemon 
   (Sending a SIGHUP will work).
 - Create the root/security namespace.
   owcreatenamespace localhost root/security
 - import the file mof/OpenWBEM_Acl1.0.mof
   owmofc localhost root/security mof/OpenWBEM_Acl1.0.mof
 - Optional: turn off the super-user in the config file. Restart owcimomd.

This will make two concrete classes available: 
OpenWBEM_NamespaceACL and OpenWBEM_UserACL.
Each of these classes contain the string datatypes of "capability"
and "nspace".  The OpenWBEM_UserACL class also has a string datatype
"username".  If these classes are found, ACLs are enabled.  If they
are not present, anyone who can authenticate to the CIMOM has full 
access.  

Once enabled, ACLs can be bypassed by logging in as superuser.  This
user is specified in the configuration file (openwbem.conf).  

When ACLs are enabled, each access to the CIMOM is checked to see 
if the user is capable of performing the operation on the particular
namespace.  First, the CIMOM tries to obtain an instance of 
OpenWBEM_UserACL using "nspace" and "username" as keys.  If an instance
exists, the value of "capability" is checked to see if the user is able
to perform the operation.  "capability" can currently be "r", "w", "rw",
or "" (no capabilities).  The nspace property value must be lowercase.

If no instance of OpenWBEM_UserACL is found, the CIMOM looks for an instance
of OpenWBEM_NamespaceACL using "nspace" as the key.  If an instance is
found, the user is granted access based on the value of the "capability" 
property.

If no ACLs are found on a namespace, that namespace inherits the ACLs
of the parent namespace.  

A note about the owcimomd.allow_anonymous config item.  If this is turned
on, ACLs will still be checked. allow_anonymous influences how the http
server works, and whether it will request authorization from a client.
ACLs are checked in the CIM Server to see if a certain user has permissions
to perform an operation.  Turning on allow_anonymous doesn't make sense
when ACLs are used, since the client doesn't actually send a username
when allow_anonymous is enabled. Similarly, if allow_anonymous is turned on,
there is no point in using ACLs.

Examples:
Suppose the following namespaces exist: /root/foo, /root/bar, /root/foo/baz.
The following instances exist in /root/security:

	instance of OpenWBEM_UserACL
	{
		 nspace = "root/foo";
		 username = "fflintstone";
		 capability = "rw";
	};
	 
	instance of OpenWBEM_UserACL
	{
		 nspace = "root/bar";
		 username = "fflintstone";
		 capability = "w";
	};

	instance of OpenWBEM_NamespaceACL
	{
		 nspace = "root";
		 capability = "r";
	};

With these ACLs in place, fflintstone has read-write access to 
/root/foo, write access to /root/bar, read access to /root, and
read-write access to /root/foo/baz (since no ACLs exist for 
/root/foo/baz, the parent -- /root/foo -- is checked).

If we add these instances: 

	instance of OpenWBEM_UserACL
	{
		 nspace = "root";
		 username = "brubble";
		 capability = "";
	};

	instance of OpenWBEM_UserACL
	{
		 nspace = "root/foo/baz";
		 username = "brubble";
		 capability = "rw";
	};

The user brubble has no access to any namespace except for /root/foo/baz,
where he has read-write access.  The user wflintstone (not covered by
any OpenWBEM_UserACL instance), would have read-only access to all namespaces
based on the OpenWBEM_NamespaceACL instance for the /root namespace.  

