Network Deployment (Distributed operating systems), v8.0 > Secure applications and their environment > Secure web services > Secure web services > Administer Web Services Security > Administer message-level security for JAX-WS web services


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 WAS 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 "Enabling 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:

Signing audit events. Use the signing audit event records to identify possible security breaches or weaknesses in the security configuration.

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:

Encryption audit events. Use the encryption audit event records to identify possible security breaches or weaknesses in the security configuration.

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:

Time stamp audit event. Use the time stamp audit event record to identify possible security breaches or weaknesses in the security configuration.

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:

Security header audit event. Use the security audit event record to identify possible security breaches or weaknesses in the security configuration.

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:

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

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:

Authentication audit event. Use the authentication audit event records to identify possible security breaches or weaknesses in the security configuration.

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 propogated 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:

Delegation audit event. Use the delegation audit event record to identify possible security breaches or weaknesses in the security configuration.

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.

Token exchange . Use the token exchange information to trace the token exchange process.

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.
Enable the security auditing subsystem
Secure JAX-WS web services using message-level security

+

Search Tips   |   Advanced Search