Openwsman uses an ini style configuration file for all components (server, client and plugins). Currently, the following options are supported

The example below shows a typical server configuration.

[server]
port = 8889
#ssl_port = 8888
ssl_cert_file = /etc/openwsman/servercert.pem
ssl_key_file = /etc/openwsman/serverkey.pem
digest_password_file = /etc/openwsman/digest_auth.passwd
basic_password_file = /etc/openwsman/simple_auth.passwd
min_threads = 1
max_threads = 4
#use_digest is OBSOLETED, see below.
#
# Authentication backend for BASIC authentication. Default is to read a configuration file defined with 'basic_password_file'
#
#basic_authenticator = libwsman_pam_auth.so
#basic_authenticator_arg = openwsman

The password files for BASIC and DIGEST can be created with the htpasswd and htdigest utilities. Both utilities usually come with Apache packages on Linux distributions.

The realm for openwsman has to be OPENWSMAN. An example password file for DIGEST with one entry:

wsman:OPENWSMAN:5a659df1ac36d2f4eb84092145532919

If both password files for basic and digest authentication are defined then both methods will be offered by the service. The client will automatically connect using the strongest authentication method.

Authentication plug-ins support only Basic authentication. DIGEST authentication support is only available using a password file created with htdigest or similar utilities.

Is the default plug-in used in Openwsman and provides access to a password file generated with htpasswd or similar utilities.

To activate PAM authentication, enable the PAM authentication plug-in the configuration file and provide the name of the PAM service. The service configuration has to be provided as a file in the /etc/pam.d directory and can for example have the following contents:

/etc/pam.d/openwsman:

#%PAM-1.0
auth       required     pam_unix2.so    nullok
auth       required     pam_nologin.so
account    required     pam_unix2.so
password   required     pam_pwcheck.so  nullok
password   required     pam_unix2.so    nullok use_first_pass use_authtok
session    required     pam_unix2.so    none

[client]
port = 8889
agent = openwsman 0.3.2

Until recently, the namespace in the resource URI (the part of the url before the class name) was very flexible. You could request something like that:

http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ComputerSystem (valid) and http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/Linux_ComputerSystem (invalid)

and both would work.

Now this does not work anymore. For CIM base classes you should use the DMTF namespace, for others you can specify the namespace in the configuration file. Depending on your CIM providers there might be no CIM/WSMan namespace available, so you can make something up, the list of namespaces I have as an example:

vendor_namespaces =
OpenWBEM=http://schema.openwbem.org/wbem/wscim/1/cim-schema/2,
Linux=http://sblim.sf.net/wbem/wscim/1/cim-schema/2,
OMC=http://schema.omc-project.org/wbem/wscim/1/cim-schema/2,
REEF=http:///reef.sblim.sf.net/wbem/wscim/1/cim-schema/2,
CWS=http:///cws.sblim.sf.net/wbem/wscim/1/cim-schema/2

So the above Linux_ComputerSystem resource URI should actually be:

http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_ComputerSystem

[cim]
default_cim_namespace = root/cimv2
# The following are in part fake namespaces for some publicly  available CIM implementations.
vendor_namespaces = OpenWBEM=http://schema.openwbem.org/wbem/wscim/1/cim-schema/2,Linux=http://sblim.sf.net/wbem/wscim/1/cim-schema/2,OMC=http://schema.omc-project.org/wbem/wscim/1/cim-schema/2