Auditing the Web Services Security runtime

Security auditing provides tracking and archiving of auditable events for the web services runtime operations. When security auditing is enabled for web services, the event generator utility collects and logs signing, encryption, security, authentication, and delegation events in audit event records. We can analyze the audit event records to identify possible security breaches or potential weaknesses in the security configuration of the environment.

The audit security subsystem must be enabled for WebSphere Application Server before the event generator can collect auditing records for the Web Services Security runtime. The recording of auditable security events is achieved by enabled the security auditing subsystem. For more information about enabling security auditing, read the topic "Enable the security auditing subsystem."

Web Services Security auditing is enabled for the JAX-WS runtime only. Several auditing events can occur when a SOAP message is received. Auditing data is collected during various Web Services Security runtime operations, such as validating the digital signature of a SOAP message, decrypting the message, or checking the message security header. The auditing data is stored and managed by the event generator, and stored in audit logs for later analysis.

Auditable events for web services include:

Signing

As the digital signature in each SOAP message part is validated, a SECURITY_SIGNING event is sent to the event generator, along with an outcome, which can be SUCCESS or ERROR. Reason codes, either VALID_SIGNATURE or INVALID_SIGNATURE, are also sent. The integrity of the message is audited, also with a SECURITY_SIGNING event, with the outcome of SUCCESS or DENIED. Reason codes are INTEGRITY or INTEGRITY_BAD. The following table summarizes the signing events:

events. Use the signing audit event records to identify

Event type	Possible outcomes	Reason codes
SECURITY_SIGNING (digital signature)	SUCCESS ERROR	VALID_SIGNATURE INVALID_SIGNATURE
SECURITY_SIGNING (integrity)	SUCCESS DENIED	INTEGRITY INTEGRITY_BAD

If the SECURITY_SIGNING event outcome is DENIED, and the reason code is INTEGRITY_BAD, this means that at least one message part, which must be signed by the security policy, failed signature validation. If the SECURITY_SIGNING event outcome is ERROR, and the reason code is INVALID_SIGNATURE, this means that the digital signature validation failed. This could lead to an INTEGRITY_BAD reason code in the audit record, depending on whether the digital signature is required by the security policy.

Encryption

Encryption auditing is performed in two parts: first, the encrypted parts of the SOAP message are processed, then the confidentiality of the message is audited. To audit each encrypted part of the message, a SECURITY_ENCRYPTION event is sent. An event record is created only if the outcome of the event is ERROR, meaning that an exception is encountered. The reason code is DECRYPTION_ERROR. Next, the confidentiality of the message is checked with another SECURITY_ENCRYPTION event, which has possible outcomes of SUCCESS or DENIED. Reason codes for this event are CONFIDENTIALITY or CONFIDENTIALITY_BAD. The following table summarizes the encryption events:

event records to identify possible security breaches or weaknesses

Event type	Possible outcomes	Reason codes
SECURITY_ENCRYPTION (encrypted message parts)	ERROR	DECRYPTION_ERROR
SECURITY_ENCRYPTION (confidentiality)	SUCCESS DENIED	CONFIDENTIALITY CONFIDENTIALITY_BAD

If the SECURITY_ENCRYPTION event outcome is DENIED and the reason code is CONFIDENTIALITY_BAD, this means that at least one message part, which is required to be encrypted, is not correctly encrypted. A DECRYPTION_ERROR in the audit record could lead to a CONFIDENTIALITY_BAD reason code, depending on whether message encryption is required.

Time stamp

For each SOAP message, the time stamp is audited when a SECURITY_RESOURCE_ACCESS event is sent to the event generator. The possible outcomes of this event are SUCCESS or DENIED. Reason codes are TIMESTAMP or TIMESTAMP_BAD. The following table summarizes the time stamp events:

event record to identify possible security breaches or weaknesses

Event type	Possible outcome	Reason code
SECURITY_RESOURCE_ACCESS	SUCCESS DENIED	TIMESTAMP TIMESTAMP_BAD

Security header

The security header is audited to make sure it is not missing from the SOAP message. A SECURITY_RESOURCE_ACCESS event is sent, and if the header is missing, the outcome is DENIED, with the reason code SECURITY_HEADER_MISSING. The following table summarizes the security header event:

event record to identify possible security breaches or weaknesses

Event type	Possible outcome	Reason code
SECURITY_RESOURCE_ACCESS	DENIED	SECURITY_HEADER_MISSING

Authentication

The security token used to authenticate a message is audited to determine if authentication is successful, and information about the authentication type, provider name and provider status are saved in the audit event record. The token ID is also recorded, along with information that is specific to the token type, such as username or keystore. Sensitive information such as the token itself, or the token password, is not recorded in the audit event record. Information recorded for each token type is described in the following table:

information recorded in audit event record. Use the authentication audit event records to identify possible security breaches or weaknesses

Token type	Recorded information
Username token	Username Password (null or not-null) Token ID
LTPA	Principal Expiration Token ID
LTPAPropagate	Principal Expiration Token ID
SecureConversation	UUID Instance UUID Token ID
DerivedKey	Reference ID Token ID
Kerberos	Principal SPN pSHA1 Token ID
X509	Certificate Subject Issuer Keystore Token ID TrustAny
PKP Path (public key infrastructure)	Certificate Subject Issuer Keystore Token ID TrustAny
PKCS7 (Public Key Cryptography Standards)	Certificate Subject Issuer Keystore Token ID TrustAny
SAML token	Principal SAML Token Issuer Name Confirmation Method

Message authentication is audited using a SECURITY_AUTHN event. Possible outcomes of the event are SUCCESS, DENIED or FAILURE. Reason codes are AUTHN_SUCCESS, AUTHN_LOGIN_EXCEPTION or AUTHN_PRIVILEDGE_ACTION_EXCEPTION. The following table summarizes the authentication events:

the authentication audit event records to identify possible security

Event type	Possible outcomes	Reason codes
SECURITY_AUTHN	SUCCESS DENIED FAILURE	AUTHN_SUCCESS AUTHN_LOGIN_EXCEPTION AUTHN_PRIVILEDGE_ACTION_EXCEPTION

Delegation

Authentication of a SOAP message can be delegated, and the delegation function is audited using a SECURITY_AUTHN_DELEGATION event. This event is sent when the client identity is propagated or when delegation involves the use of a special identity. In the Web Services Security runtime, auditing events are recorded only when the delegation type is set to Identity Assertion. Possible outcomes are SUCCESS or DENIED, with reason codes AUTHN_SUCCESS or AUTHN_DENIED. Additional information, such as delegation type, role name and identity name, is collected and stored in the audit event record. The following table summarizes the delegation events:

event record to identify possible security breaches or weaknesses

Event type	Possible outcomes	Reason codes
SECURITY_AUTHN_DELEGATION	SUCCESS DENIED	AUTHN_SUCCESS AUTHN_DENIED

Validation

As part of the generic security token login module support, a Security Token Service can validate a token using a WS-Trust Validate request. This validation operation can return a token in exchange for a token that is being validated. The information that is exchanged is located in the documentation on auditing for a generic security token. The following table shows the token exchange information that is recorded.

Event	Description
TokenSentForExchangeId	This information identifies the token that is sent for validation and is exchanged.
TokenSentForExchangeType	This information identifies the type of the token that is sent for validation and is exchanged.
ExchangedTokenId	This information identifies the token that is received in exchange during the validation request.
ExchangedTokenType	This information identifies the type of the token that is received in exchange during the validation request.

If the token is validated without a token exchange, only the Token ID is recorded.

Related tasks

Enable the security auditing subsystem