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. You can analyze the audit event records
to identify possible security breaches or potential weaknesses in
the security configuration of your 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 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:
Table 1. 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:
Table 2. 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:
Table 3. 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:
Table 4. 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:
Table 5. 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 |
|
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:
Table 6. 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 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:
Table 7. 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.
Table 8. 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.