Database Reference
In-Depth Information
Though the actual output is not formatted as cleanly as shown in the preceding
snippet, from this log fragment, we can extract some great information that
would have otherwise been unavailable had the logger levels not been in-
creased. In this example, we were able to confirm the following:
•
The location of the SOA keystore file
default-keystore.jks
that was
previously configured.
•
The status of the policy which is enabled.
•
The actual policy
oracle/
wss10_x509_token_with_message_protection_client_policy
is
used and in effect.
•
The assertion
Wss10MutualAuthWithCertsScenario
is enforced.
•
The
values
of
the
keystore.recipient.alias,
key-
store.sig.csf.key
, and
keystore.enc.csf.key
properties.
Often when configuring OWSM, you will run into many difficulties, and verifying
the actual values being used at runtime as shown proves incredibly valuable dur-
ing the set up and troubleshooting efforts.
Modifying the platform audit policy
It is easy to blankly set the log configuration to a higher level without much
thought and thereby have everything being written to the server log files.
However, this has its own implications as far as performance and active
troubleshooting are concerned. To save yourself from these perils, you can do
a couple of things like navigating the hierarchy of the
oracle.wsm
logger and
only increasing a selected few loggers within it. On the other hand, sometimes
you may be faced with unique scenarios that require conditional logging. Con-
sider a scenario where you need to log requests that are being successfully au-
thorized to access services on your platform and are not coming from a trusted
client (or only a registered IP). See the following screenshot, which explains how
this particular use case is catered for, by overriding the default audit policy set-
tings. To apply custom audit policy configurations, follow the next steps:
