Access and authentication for web services

BMC CMDB web services has several supported security policies that are consistent with the Web Services Security 1.0 standard. These policies facilitate authentication, integrity, and confidentiality of the information passed through BMC CMDB web services. You can use these supported policies and configuration settings to use BMC CMDB web services immediately after installation.

Complying with Web Services security policies

BMC CMDB web services has several supported security policies that are consistent with the Web Services Security 1.0 standard.

These policies facilitate authentication, integrity, and confidentiality of the information passed through BMC CMDB web services. You can use these supported policies and configuration settings to help you start using BMC CMDB web services immediately after installation.

BMC CMDB requires client authentication with wsse:Username. The wsse:Username authentication is the only default security policy.

Supported security policies for SOAP requests

BMC CMDB provides security policies for incoming Simple Object Access Protocol (SOAP) requests.

The wsse:UsernameToken element manages authentication to BMC CMDB. You cannot remove or disable this policy.
(optional ) XML Digital Signature manages authentication to the web service layer and verification of integrity of the content of the SOAP request.
(optional ) XML Encryption manages confidentiality of the content of the SOAP request.

Authenticating to BMC CMDB with web services

The security policy that manages authentication to BMC CMDB requires a Simple Object Access Protocol (SOAP) request that includes wsse:UsernameToken and wsse:Password as mandatory elements. The other elements are optional. The following table describes the authentication elements.

Authentication elements

Element	Requirements
`wsse:Username`	A username of a BMC CMDB user. Empty strings are invalid.
`wsse:Password`	A password corresponding to the username provided in the `wsse:Username` element. If you omit the password, use a single space to represent the password value. The `Type` attribute of the `wsse:Password` element must be: `http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText` BMC does not support the `Type` attribute of `PasswordDigest`.
`wsse:Nonce`	If nonce enforcement is enabled, BMC CMDB does the following: The nonce value must be unique within five minutes of the last time that particular nonce value was used. If a username is sent without a nonce value, the username token is not rejected. Nonce validation is an option in the WS-Security standard. If nonce enforcement is disabled, any nonce token sent with the username is ignored.
`wsu:Created`	If created date and time enforcement is enabled, BMC CMDB does the following: It checks for a valid date in the `xsd:dateTime` format. The date and time value can be in the past or present, but not in the future. If the date and time value is in the past, it must be less than five minutes in the past. If a username is sent without a created value, the username token is not rejected. Created time and date validation is an option in the WS-Security standard.

If created date and time enforcement is disabled, any created date and time token sent with the username is ignored.

The following is an example of the wsse:UsernameToken element:

<wsse:UsernameToken> <wsse:Username>Demo</wsse:Username> <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">DemoPswd</wsse:Password> <wsse:Nonce>LyEQw+0pSZr+a+CJVSuNgOvp9cY=</wsse:Nonce> <wsu:Created>2009-01-25T11:45:30Z</wsu:Created> </wsse:UsernameToken>

The following example assumes that the password Type is PasswordText:

<wsse:UsernameToken> <wsse:Username>Demo</wsse:Username> <wsse:Password>DemoPswd</wsse:Password> <wsse:Nonce>LyEQw+0pSZr+a+CJVSuNgOvp9cY=</wsse:Nonce> <wsu:Created>2009-01-25T11:45:30Z</wsu:Created> </wsse:UsernameToken>

Web services authentication and request message integrity

The security policy that manages web services authentication and request message integrity checks requires that you authenticate to the web services and validate that the content of the message was not altered in transit or at any other point in its lifetime.

This security policy requires the client to generate a public key and corresponding private key combination for use in one of the following supported asynchronous signing algorithms. The client's private keystore keeps private keys safe and signs messages using the signing algorithm.

Supported algorithm	Location of detailed description
DSAwithSHA1 (DSS)	http://www.w3.org/2000/09/xmldsig#dsa-sha1 (http://www.w3.org/2000/09/xmldsig#dsa\-sha1)
RSAwithSHA1 (PKCS1)	http://www.w3.org/2000/09/xmldsig#rsa-sha1 (http://www.w3.org/2000/09/xmldsig#rsa\-sha1)

Message validation

When validating the message, the incoming service validates the following items:

The signed content has been unchanged. It does this by validating the signature against the public key contained in the X509v3 certificate sent with the Simple Object Access Protocol (SOAP) request.
The certificate was signed by a trusted certificate authority. It does this to authenticate the client and allow the request to process further.

A trusted certificate authority must sign the X509v3 certificate before use. BMC CMDB web services authenticates the X509v3 certificate, contained in the wsse:BinarySecurityToken element, by validating the signature of the certificate issued by a trusted certificate authority.

Trusted certificate authorities

BMC CMDB web services uses a truststore file, which contains the public keys of common trusted certificate authorities, to validate X509v3 certificates. See the following table for details about the default truststore.

Important

Replace the default truststore and trusted CA or trusted ID certificates with those that meet your company's requirements. For more information about replacing the keystore, see Modifying the AR System server used as a web services userstore.

Truststore details

Truststore	Description
Filename	`<BMCAtriumCoreInstallationDirectory> /wsc/atriumws91/keystores/bmcatriumwscacerts.jks`
Type	Java KeyStore (JKS)
Password	atrium

For initial use and testing of BMC CMDB web services, you can use the client keystore (described in the following table), which contains a public and a private key, for proper signatures and authentication so that you can begin consuming BMC CMDB web services. The truststore contains a self-signed public certificate as a trusted certificate authority.

Client keystore details

Keystore	Description
Filename	`<BMCAtriumCoreInstallationDirectory> /wsc/atriumws91/keystores/bmcatriumwsclient.jks`
Type	Java KeyStore (JKS)
Password	atrium
Client key details within a keystore	Name--bmcatriumwsclient Private Password--atrium
Certificate file	BMC provides the client keystore file so that you can import it into your keystore. You can find this file in the following location: `<BMCAtriumCoreInstallationDirectory> /wsc/atriumws91/keystores/bmcatriumwsclient.cer`

Setting up security for web services

Enabling BMC CMDB web services 1

Modifying the AR System server used as a web services userstore