This chapter introduces how to manage components involved in the protection of Security Token Service endpoints. This chapter provides the following topics:
This section identifies requirements for tasks in this chapter.
Before you begin tasks in this chapter, be sure to review the following topics:
Security Token Service a Web Service co-existing with Access Manager. Security Token Service invokes some Access Manager components to validate and issue security tokens. Typically, the Web client can use the Security Token Service to request an outbound token, such as SAML, by providing a security token, like a Username Token or an X.509 Token.
Security Token Service is integrated with the Oracle Access Management Console to provide a unified and consistent administration experience. All Security Token Service system configuration is done using the Oracle Access Management Console.
Security Token Service provides:
Validation Tokens: Standard (Username, X.509, Kerberos, SAML 1.1/2.0) and custom tokens. OnBehalfOf use cases (OAM Session ID Propagation Token and custom tokens through the integration engine) also supports the following standard tokens along with OAM sessionID propagation token and custom token (Username, X.509, SAML 1.1/2.0).
Issuance Tokens: Standard (Username, SAML 1.1/2.0) and custom tokens through the integration engine
Configuration-driven token issuance and validation
Enhanced auditing through identity propagation across multiple tiers and domains
Consolidated shared-platform service interacts with internal (Access Manager SSO, Federation, Oracle Web Services Manager) and external services
This section provides the following topics:
Oracle Fusion Middleware Security and Administrator's Guide for Web Services
After installation and server startup, you can access the Oracle Access Management Console on the OAM Server. For example, if the URL to the OAM Server is http://machine:14100/oam, you might access:
Oracle Access Management Console at http://machine:7001/oamconsole
Security Token Service: http://machine:14100/sts/wss11user?wsdl to view the WSDL of the /sts/wss11user endpoint that is available by default, to ensure that Security Token Service is available.
By default, Security Token Service is disabled and as such all runtime functionality as well as Web Service endpoints are disabled. To access those endpoints, Security Token Service must first be enabled using the Oracle Access Management Console. Afterwards, the endpoints might be accessed
Post-installation configuration includes the tasks in the following outline, which point to other areas in this book for details.
Server Side Configuration: Use the Oracle Access Management Console for the following tasks.
Service enablement "Enabling and Disabling Services for Security Token Service"
Settings configuration "Managing Security Token Service Settings"
Endpoint registration "Managing EndPoints"
Token Issuance Template configuration "Managing Token Issuance Templates"
Token Validation Template configuration "Managing Token Validation Templates"
Partner Profile creation "Managing Token Service Partner Profiles"
Partner configuration "Managing Token Service Partners"
Token Issuance Policies to define an authorization rule for issuing tokens with Security Token Service, for a specific Relying Party "Managing Token Issuance Policies, Conditions, and Rules"
Set up interactions with the Oracle WSM Agent as described in following topics:
Set up message logging, as described in "Introduction to Logging Security Token Service Messages".
Configure event auditing, as described in "Setting Up Auditing for Oracle Access Management".
Configure lifecycle management
Register the Security Token Service trust endpoint, as described in item 1c.
Register the Requester or Relying Party Partner with Security Token Service, as described in "Managing Token Service Partners".
Monitor performance, as described in Chapter 10, "Monitoring Performance and Logs with Fusion Middleware Control".
With Oracle Access Management, all Security Token Service instances are installed on OAM Servers (also known as Managed Servers). Each server must be registered with Access Manager.
Security Token Service leverages the common infrastructure for shared services and the Oracle Access Management administration model.
Security Token Service support Web Services Security protocol 1.0 and 1.1 and process the following tokens, if present in the Security SOAP headers:
Username token (UNT)
SAML 1.1 or SAML 2.0 Assertion
Managed servers hosting Security Token Service must be registered with Access Manager as described in Chapter 5, "Managing Server Registration".
Third-Party Servers: Security Token Service interoperates with third party security token servers. For instance, a third party Security Token Service can create a valid Security Assertion Markup Language (SAML) Assertion that can be consumed by Security Token Service.
Security Token Service provides services to various Oracle clients (Oracle Web Services Manager client) or third party clients (Microsoft and IBM are two).
Oracle WSM Client: Oracle Web Services Manager client bindings are the responsibility of Oracle Web Services Manager (and out of scope for this book). For more information, see "Configuring Oracle WSM Agent for WSS Kerberos Policies".
"WS-Trust Policies and Configuration Steps" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services
Third Party Clients: Require a secure key exchange between the Oracle WSM client and server. You simply import the Security Token Service certificate to the client.
During SOAP interactions, the WS-Security protocol might require the client to trust the signing/encryption certificate used for WSS operations by the OWSM Agent protecting the Security Token Service endpoint. In those cases, the Oracle Access Management Administrator should extract the Security Token Service OWSM signing/encryption certificate used for WSS operations and provide it to the WS Client. For more information, see "Extracting the Oracle STS/Oracle WSM Signing and Encryption Certificate".
Oracle Web Services Manager communicates through agents. This topic introduces the agents that operate with Security Token Service.
Oracle WSM Agent: The Oracle Web Services Manager (Oracle WSM) Agent is integrated with Security Token Service. This agent provides the Web Services Security support for Security Token Service Web Services endpoints.
Protects Web Services endpoints of Security Token Service
Provides WS-Security support for sending SOAP messages to Relying Parties. As part of that process, the OWSM Client might interact with Security Token Service to get a security token that will be presented to the Relying Party
Interacts with Security Token Service for token acquisition and token validation
Security Token Service supports token acquisition and token validation by Oracle Web Services Manager (Oracle WSM) agents. Oracle Web Services Manager Agents are not required to use Security Token Service as part of their inbound or outbound security policy enforcement. Oracle Web Services Manager client bindings are the responsibility of Oracle Web Services Manager Administrators.
The Oracle WSM Agent is used by Security Token Service to enforce message protection of the SOAP communication channel between Security Token Service and the client. The Oracle WSM Agent caches the OPSS Keystore (by default the default-keystore.jks keystore located in $DOMAIN_HOME/config/fmwconfig directory) which contains the trusted certificates involved when validating the WSS clients' certificates. Subsequent changes to the contents of the keystore or to its name, require a restart of the Managed Server using Oracle Enterprise Manager Fusion Middleware Control or WebLogic Server console, or NodeManager.
The Oracle WSM Agent available to Security Token Service must be configured to protect the Security Token Service endpoints, to perform the following tasks:
Decrypt the request, if necessary
Verify any digital signatures present in the request
Validate any certificate used to create the request's digital signatures, if the signatures were created with a private key
Validate any X.509 token, if present, in the SOAP headers
Validate the Kerberos token, if present, in the SOAP headers
Sign the outgoing response, if needed
Encrypt the outgoing response, if required
Oracle WSM Agent Keystore: The Oracle WSM Agent uses a keystore for various cryptographic operations. For these operations, the Oracle WSM Agent uses the keystore configured for Oracle WSM tasks.
Webgate: Security Token Service uses Webgate for the Access Manager session propagation token. This, identity propagation, use case is more advanced. It requires the Identity Assertion Provider in WebLogic Server and some custom integration.
When you add an endpoint, you can choose from a list of Policy URI's and validation templates with which to associate the Security Token Service endpoint. By default, Security Token Service is configured with the endpoints shown in Figure 32-1.
The ORAPROVIDER is integrated with the Oracle WSM Agent, which provides Web Services Security support on the SOAP messages being exchanged between the client and Security Token Service. Security Token Service leverages ORAPROVIDER for Web Services to:
publish Web Services endpoints dynamically
invoke Security Token Service to process SOAP messages
publish a WSDL file for each WS endpoint
Oracle WSM Agent WSS Policy Stores: The Oracle WSM Agent requires a repository to retrieve the Web Services Security (WSS) policies it needs. Security Token Service supports two types of repositories:
JAR file with WSS Policies: Used when the WLS Domain is configured for classpath.
Oracle WSM Policy Manager available from the SOA deployment
Managing Oracle Workspace Studio policies for Security Token Service
Oracle Fusion Middleware Security and Administrator's Guide for Web Services for details about the policies for Security Token Service
Policy Assertions: Out of the box, Security Token Service provides a set of security policy assertions for use with the WS-Policy framework to describe how messages are to be secured in the context of Oracle Workspace Studio: SOAP Message Security and WS-Trust.
Security Token Service makes its associated security policy files publicly available by attaching them to its deployed WSDL.
Security Token Service runtime uses the private key and X.509 certificate pairs, stored in the keystores defined by the jps-config.xml file, for its WS-Security encryption and digital signature operations.
The following paragraphs and tables identify the policies that are available out of the box for Security Token Service and the Oracle WSM Agent.
Message-level Security Not Required: When message level-security is not required, use an Security Token Service policy that does not specify message_protection in its name. This authenticates users using credentials provided in tokens in the WS-Security SOAP header. The credentials in the Fusion Applications token are mapped based on the rules specified in the validation template. Both plain text and digest mechanisms are supported.
Transport Security when Message-level Security Not Required: You can configure two-way SSL where both the client applications and WebLogic server present certificates to each other. To configure two-way or one-way SSL for the core WebLogic Server security see "Configuring SSL" in Oracle Fusion Middleware Securing Oracle WebLogic Server guide. Use the policies described in Table 32-1.
Interoperability WS-Security 1.0 and 1.1 Policies: Use policies in Figure 32-2 if you require interoperability with WS-Security 1.0 or 1.1 (depending on your authentication requirements and credential availability). Use WS-Security 1.1 policies if you have strong security requirements.
From the Oracle Access Management Console, System Configuration tab, open the Security Token Service section.
From the Endpoints node, proceed as described in "Managing Security Token Service Endpoints" to locate or create the endpoint to be protected.
From the Policy URI list, choose a specific WS Security policy to protect the endpoint, as described in:
This topic includes the following topics:
Elements in the Oracle Access Management Console enable Administrators to easily configure the Token Service to exchange WS Trust tokens with partners. Token Service elements provide for creation, viewing, modification, and removal of partners, endpoints, validation templates, issuance templates, and data store connections.
All Security Token Service system configuration is done using the Oracle Access Management Console. This includes the following common tasks covered in Part II of this book:
Registering and managing common OAM Servers and proxy information
Registering and managing the common Default User Identity Store
Configuring the OAM Keystore, which differs from the OWSM Keystore used for WSS processing
Certificate Validation and Revocation
The Oracle Access Management Console enables Administrators to perform the following Security Token Service-specific tasks:
Manage validation token templates: The validation templates include configuration properties to validate a Web Services Security/WSTrust token, and map it to a Requester Partner or a User record in the Default User Identity Store.
Manage issuance templates: The issuance templates contain rules on how a token will be created
Manage Partner Data: A partner represents a partner trusted by Security Token Service. Security Token Service defines three types of partners: Requester, Relying Party and Issuing Authority. Each partner entry is associated to a partner profile. The partner entry contains signing and encryption certificates and identifiers used to uniquely identify a partner
Manage Partner Profile: A partner profile contains configuration properties that are common to a set of partners:
Token Types definition
Issuance and Validation templates defined for the token Types
Override Validation Template rules for Issuing Authorities(Other STS)
Manage Security Token Service Endpoints
Manage Token Issuance Policies (authorization policies that will be evaluated to determine if a Requester Partner can request a token based on the Relying Party referenced in the request)
Security Token Service Global Settings
Users with administrative access to the Oracle Access Management Console, have access to Security Token Services.
Initially, administrative users must log in to the Oracle Access Management Console using the WebLogic Administrator credentials set during initial configuration. However, your enterprise might require independent sets of Administrators: one set of users responsible for Access Manager and another for Security Token Service.
When using Security Token Service with Access Manager, logging in to, and signing out of the Oracle Access Management Console is the same.
Chapter 2 for the following topics:
To use Security Token Service, both it and Access Manager must be enabled, as shown in Figure 32-3. By default Security Token Service is disabled and needs to be enabled.
A green check mark in the Status field beside the service name indicates the service is enabled. A red circle with a line through it indicates that the corresponding service is disabled.
Oracle Access Manager service must be enabled.
Log in to the Oracle Access Management Console, as usual
From the System Configuration tab, Common Configuration section, click Available Services.
Enable Security Token Service: Beside Security Token Service, click Enable (or confirm that the Status check mark is green) and confirm that the Access Manager Service is also enabled.
Disable Security Token Service: Beside Security Token Service, click Disable (or confirm that the Status check mark is red).
This section provides the following information:
Security Token Service can be viewed or altered from the Security Token Service section of the System Configuration tab. These settings are show in Figure 32-4.
Table 32-1 describes the elements on the Security Token Service Settings page.
Partner Identification Attributes
A field where you list attributes, other than the standard ones available by default, that should be available in "Identity Attributes" Table in the Partner page. These attributes can be used to identify a partner by matching their values against those in the incoming request.
When a Requester sends a WS-Trust request to Security Token Service, the server might map the incoming token containing the requester's identity to a partner entry in the Security Token Service partner store.
To do so, Security Token Service will use the mapping settings configured in a validation template and will attempt to map the token data to a partner entry by performing a lookup by matching the token data to a Partner Identification Attribute.
By default, each requester partner contains three identification attributes that can be set: username, HTTP Basic Username, SSL Client Certificate DN.
It is possible to define additional Identification Attributes that could be set for each requester partner entry.
This section allows new attributes to be set. After defining a new attribute, it becomes available in the Requester Partner entry section, and it can be used in mapping rules in the WSS Validation Templates.
Custom Trust Anchor File
By default, Access Manager and Security Token Service use the default
It is possible to configure Security Token Service to use a specific trust anchor file if necessary, that will contain trust anchors only used for Security Token Service operations and validations. In this case, this field should contain the location of the JKS keystore to use.
Note the following:
Default Encryption Template
A list from which you choose the default template for Security Token Service encryption:
See Also: Setting the Default Encryption Key.
Outbound Connection Properties, HTTP Proxy Settings Use this section to configure Security Token Service to use a proxy for outgoing HTTP connections when optionally retrieving the WS-Sec Policy of Relying Parties at runtime:
Location: Path of the active keystore that was set up during Security Token Service installation.
The Keystore table includes the following information for each of the templates in the table, which are available for use as the Default Encryption Template:
The keystore section defines key entries that exist in the Security Token Service keystore:
After an entry is defined an entry, it can be used in other Security Token Service templates (like SAML Issuance Templates).
Users with valid Administrator credentials can use this procedure to confirm or alter Security Token Service Settings.
Both the Access Manager Service and the Security Token Service must be enabled.
Log in to the Oracle Access Management Console, as usual.
From the System Configuration tab, open the Security Token Service Settings section.
Double-click the Security Token Service Settings
On the Security Token Service Settings page view (or modify) the following information (see Table 32-1):
Partner Identification Attributes
Custom Trust Anchor File
Keystore Table: View, add, or remove new encryption templates
Click Apply to submit changes (or Revert to cancel changes).
Close the page when finished.
You can use existing Oracle Workspace Studio policies to protect Security Token Service Web Service endpoints. For instance:
classpath mode: Existing Oracle Workspace Studio policies defined in
$ORACLE_IDM_HOME/oam/server/policy/sts-policies.jar are used in this mode
SOA deployment: Policies defined in the Oracle WSM Policy Manager available from a SOA deployment are used
This section describes how to manage Web Service Security Policies for Security Token Service in the following topics:
This section introduces WS-Security Policies used to protect Security Token Service WS Endpoint and how to modify these policies. TheWS-Security Policies that are provided by Oracle should cover most use cases.
Attaching Policies to Web Services in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services
Predefined Oracle Web Services Manager policies are constructed using assertions based on predefined assertion templates. For WSS Policy classpath mode, the OWSM Agent retrieves policies from sts-policies.jar located on the classpath.
If SOA is not deployed in the WebLogic Server domain, the Security Token Service installer configures the WebLogic Server domain for WSS Policy classpath mode. The JAR file containing the WSS Policies used when the WLS Domain is configured for classpath is located at:
When your environment is in classpath mode, perform the following tasks to Administrators confirm sts-policies.jar is located on the classpath.
Oracle WSM Predefined Policies and Assertion Templates in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services
Define an OWSM Assertion Template.
Proceed as follows, depending on your need:
Modify an OWSM Policy
Define a Policy using the OWSM Assertion Template
Bundle the Assertion Template and policy in the sts-policies.jar file:
META-INF/assertiontemplates/oracle of the $IDM_ORACLE_HOME/oam/server/policy/ sts-policies.jar
sts-policies.jar is located in the following path to enable the policy URI to be available the Policy URI drop down list.
Restart the Managed Servers running Security Token Service.
Proceed to the Oracle Access Management Console to configure the Security Token Service Endpoints.
The Oracle WSM Policy Manager is the security linchpin for Oracle Fusion Middleware Web services and SOA applications. For more information about how the Oracle WSM Policy Manager manages the policy framework, see "Understanding Oracle WSM Policy Framework" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
At design time, you attach Oracle WSM and WebLogic Web service policies to applications programmatically using your favorite IDE, such as Oracle JDeveloper. Alternatively, at deployment time you attach policies to SOA composites, ADF, and WebCenter applications using the Oracle Enterprise Manager Fusion Middleware Control, and to WebLogic Web services (Java EE) using the WebLogic Server Administration Console.
System Administrators can leverage the Oracle WSM through the Oracle Enterprise Manager Fusion Middleware Control to:
Centrally define policies using the Oracle WSM Policy Manager.
Enforce Oracle WSM security and management polices locally at run time.
When your environment is integrated with the OWSM Policy Manager, perform the following tasks to add or modify WSS policies for Security Token Service using Oracle Web Services Manager.
All of Oracle WSM's functionality is accessible to Administrators from Oracle Enterprise Manager Fusion Middleware Control.
Part II, "Basic Administration"
Part III, "Advanced Administration"
From the OWSM Policy Manager, locate and open the desired policy.
Refer to the Oracle Fusion Middleware Security and Administrator's Guide for Web Services and make any required changes to the policy.
Restart all Managed Servers running Security Token Service.
This section describes how to configure communication between WS-Sec Clients and the Oracle WSM Agent embedded with Security Token Service.
The Oracle WSM Agent protects the Web Service endpoints of Security Token Service, and provides support for WSS protocol exchanges. To ensure a client is communicating successfully with the Oracle WSM Agent:
The client might need to be aware of the signing and encryption certificates used by the Oracle WSM Agent (this will require extracting and distributing the signing and encryption certificates used by the OWSM Agent embedded with Security Token Service).
The Oracle WSM Agent might need to be aware, depending on the policies, of the signing certificate used by the client (this will require adding the client's certificate as a trusted certificate for the Oracle WSM Agent)
The Oracle WSM Agent requires a repository to retrieve the Web Services Security (WSS) policies it needs. Access Manager supports two types of repositories for Security Token Service:
JAR file with WSS Policies: Used when the WLS Domain is configured for classpath. The required JAR file is located in $IDM_ORACLE_HOME/oam/server/policy/ sts-policies.jar.
Oracle WSM Policy Manager available from the SOA deployment
During Security Token Service installation, the installer detects if the Oracle Web Services Manager Policy Manager is present and deployed in the WebLogic Security domain.
If not deployed in the WebLogic Security domain, the installer configures the WebLogic Security domain for the Web Services Security Policy classpath mode, where the WSM Agent will retrieve the policies from a JAR file.
If present, the installer connects to the Oracle Web Services Manager Policy Manager and uploads the policies that are used to protect Security Token Service endpoints.
"About the Database Store for Policy, Password Management, and Sessions" for details about the required database for Access Manager policy data and (optionally) Access Manager session data.
Administrators need to retrieve the keystore password and key entry password from CSF for certain activities. Otherwise, keystore or key entry cannot be changed. Having access to the keystore is sometimes required to:
Extract the signing/encryption certificate to distribute to clients if necessary
Update or replace the signing/encryption key entry
Add trusted certificates
The following procedure displays the password used to protect the Oracle WSM keystore as well as the key entry.
Enter the WSLT scripting environment.
Connect to the WebLogic Server AdminServer, using the
Execute the following command by providing the connection information to the AdminServer:
Note the password.
During SOAP interactions, the WS-Security protocol might require the client to trust the signing/encryption certificate used for WSS operations by the OWSM Agent protecting the Security Token Service endpoint. In those cases, the Oracle Access Management Administrator should extract the Security Token Service OWSM signing/encryption certificate used for WSS operations and provide it to the WS Client.
The Administrator must export the signing and encryption certificate used by Security Token Service for WSS cryptographic operations. The following procedure guides as you do this by:
Replacing $DOMAIN_HOME with the path to the Domain directory
CERT_FILE with the location of the file where the certificate will be saved
If you are prompted to enter a password, simply press the Enter key.
Execute the following command.
keytool -exportcert -keystore $DOMAIN_HOME/config/fmwconfig/default-keystore.j ks -storetype JKS -alias orakey -file $CERT_FILE
Enter the keystore password retrieved in the previous section if prompted.
To add a trusted certificate to the OWSM keystore for WSS cryptographic operations:
perform the command in the following procedure
replace the $DOMAIN_HOME with the path to the Domain directory
replace the $TRUSTED_CERT_FILE with the location of the file containing the trusted certificate
replace the TRUSTED_CERT_ALIAS with the alias under which the trusted certificate will be stored
When prompted to enter a password, enter the password of the OWSM keystore that you retrieved earlier.
The Administrator must have the certificate to import.
Execute the following command.
keytool -importcert -trustcacerts -keystore $DOMAIN_HOME/config/fmwconfig/de fault-keystore.jks -storetype JKS -alias $TRUSTED_CERT_ALIAS -file $TRUSTED_ CERT_ALIAS
Observe messages on the screen, enter a password if requested.
When the Oracle WSM Agent performs a certificate validation, it uses the keystore configured for Oracle WSM tasks, and will validate the certificate against the trusted certificate entries contained in the keystore. For those operations, it might be required to add trusted certificate entries (the certificate itself or the issuer's certificate) in the OWSM keystore.
When receiving a SOAP requester, the Oracle WSM Agent processes the request for message protection. Part of the steps might include a certificate validation operation if the incoming message:
is of type WSS 1.0, and includes a digital signature created with a private key, without the certificate being present. In this case:
Remedy: The Oracle WSM keystore must contain the signing certificate.
is of type WSS 1.0, and includes a digital signature created with a private key, with the certificate being present.
Remedy: The Oracle WSM keystore must contain either the signing certificate or the issuer's certificate of the signing certificate.
is of type WSS 1.1, and includes a digital signature created with a private key, without the certificate being present.
Remedy: The Oracle WSM keystore must contain the signing certificate.
is of type WSS 1.1, and includes a digital signature created with a private key, with the certificate being present. In this case, the OWSM keystore will need to contain either the signing certificate or the issuer's certificate of the signing certificate
Remedy: The Oracle WSM keystore must contain either the signing certificate or the issuer's certificate of the signing certificate
Security Token Service provides services to various Oracle clients (Oracle Web Services Manager client) or third party clients (Microsoft and IBM are two). the Oracle WSM Agent performs only message protection (not authentication) on the incoming request. The Oracle WSM agent does not attempt to map the incoming Kerberos ticket to a user record in the OPSS Identity Store.
If Oracle WSM is the client that will interact with Security Token Service using WSS Kerberos policies, then the entire Oracle WSM Kerberos setup section in Oracle Fusion Middleware Security and Administrator's Guide for Web Services applies.
However, if the client is not Oracle WSM, see Table 32-2 and disregard sections on how to configure the client, sections related to authenticating the user referenced in the Kerberos ticket.
|Perform Tasks for Non-Oracle Client||Skip These Tasks for Non-Oracle Client|
Configure the KDC
Initialize and Start the MIT Kerberos KDC
Configure the Web Service Client to Use the Correct KDC
Set the Service Principal Name In the Web Service Client
Set the Service Principal Name In the Web Service Client at Design Time
Configure the Web Service to Use the Right KDC
Use the Correct Keytab File in Enterprise Manager
Extract and Export the Keytab File
Modify the krb5 Login Module to use the Keytab File
Authenticate the User Corresponding to the Service Principal
Create a Ticket Cache for the Web Service Client
Use Active Directory with Kerberos and Message Protection
Set Up the Web Service Client
Create a User Account
Create a Keytab File
Set the Service Principal Name
Set Up the Web Service
This section provides the following topics:
Security Token Service packages policies for endpoints in sts-policies.jar file. This jar is copied to following location under WLS_HOME ($WL_HOME/Oracle_IDM1, for example):
The sts-policies.jar contains the stspolicies.prop file at the following location in the JAR:
This file lists all the policies packaged in the directory as file names to allow the server to read the JAR entries programmatically when migrating policies to destination repository.
Be sure to update policies and stspolicies.prop as needed before migration.
The following procedure outlines the various scenarios for policy updates.
Add a Policy to sts-policies jar: Before creating the new jar, you must also update the stspolicies.prop file at META-INF/policies/sts/ to include this new policy file name.
Delete a Policy from sts-policies jar: You must also delete the entry from file META-INF/policies/sts/stspolicies.prop.
Update Existing Policy File Name: When re-naming a policy file at META-INF/policies/sts/, you must also update the corresponding entry in the file META-INF/policies/sts/stspolicies.prop file.
Update Existing Policy Content: When updating the content of a policy file, without touching the file name, there is no need to do anything else.
During installation a check is performed to establish whether SOA is deployed within the domain where Security Token Service is being installed:
If SOA is not installed, the Oracle WSM protocol is set to classpath and policies are read from the JAR on the class path.
If SOA is present within the domain, Security Token Service reads the policies from sts-policies.jar and migrates them to the Oracle WSM PM repository by calling Oracle WSM Mbeans.
If SOA is installed after Security Token Service within the same domain, ensure smooth operations between SOA and Security Token Service as follows:
The Oracle WSM protocol must be set to 'remote'.
Security Token Service policies from sts-policies jar must be migrated to Oracle WSM PM repository using Oracle WSM provided tools.
Logging is the mechanism by which components write messages to a file. Administrators can use the logging mechanism to capture critical component events. Access Manager uses the same logging infrastructure and guidelines as any other component in Oracle Fusion Middleware 11g. This is accomplished by using the package
java.util.logging, which is standard and available in all Java environments. The logging system writes output to flat files only. Logging to an Oracle Database instance is not supported.
Configuring logging and locating log files are the focus of this section. Diagnosing problems using the information in log files is outside the scope of this manual.
Log messages are used for problem diagnosis. The logging infrastructure records messages from Access Manager. The Administrator controls the amount of information that is logged in a message by specifying log levels for each component or service for which a logger is defined.
Generally, you enable logging to produce files that you send to Oracle Technical Support for problem diagnosis. Documentation for log messages is not available. In some cases, you might be able to diagnose problems on your own by reading log files.
By default, the log level for Access Manager is the Notification level. Logging at the Error level produces a small amount of output while other log levels can result in voluminous logging output, which can impact OAM performance. In production environments, logging is usually either disabled or the log level is set to a level that results in a small volume of logging output (the error level, for example).
Access Manager and Security Token Service uses the WebLogic container's logging defaults:
Logging File: DOMAIN_HOME/servers/SERVER-NAME/logs/SERVER-NAME-diagnostics.log
Logging Configuration File: Provides logging level and other configuration information for logging. This file is stored in the following path: DOMAIN_HOME/config/fmwconfig/servers/SERVER-NAME/logging.xml
Oracle Fusion Middleware auditing provides a measure of accountability and answers to the "who has done what and when" types of questions. Audit data can be used to create dashboards, compile historical data, and assess risks. Analyzing recorded audit data allows compliance officers to perform periodic reviews of compliance policies.
This section introduces the Security Token Service administrative and run-time events that can be audited. Configuring common auditing settings for Security Token Service and validating your auditing configuration is a subject of this chapter. However, analyzing and using audit data is outside the scope of this book.
The Oracle Fusion Middleware Common Audit Framework supports auditing for a number of run-time events, and administrative events (changes to the system). The Oracle Fusion Middleware Common Audit Framework provides uniform logging and exception handling and diagnostics for all audit events.
While auditing can be enabled or disabled, it is normally enabled in production environments. Auditing has minimal performance impact, and the information captured by auditing can be useful (even mission-critical).
Auditing is based on configuration parameters set in the Oracle Access Management Console that enable data capture for a user or set of users.
Audit data can be written to either a single, centralized Oracle Database instance or to flat files. Regardless of where the audit record is stored, it contains a sequence of items that can be configured to meet particular requirements. The audit log file helps the audit Administrator track errors and diagnose problems if the audit framework is not working properly.
Security Token Service integrates with Oracle Business Intelligence Publisher, which provides a pre-defined set of compliance reports.
Security Token Service can be configured to write audit records to a variety of targets supported by the Common Audit Framework:
Local flat files: By default, Security Token Service records audit data to a file.
Central database: In production environments, Oracle recommends using a database audit store to provide scalability and high-availability for the Common Audit Framework. Audit data is cumulative and grows over time. Ideally this is a database for only audit data; not used by other applications.
Platform-specific log (Linux Syslog and Windows Event Log)
To switch to a database as the permanent store for your audit records, you must first use the Repository Creation Utility (RCU) to create a database schema for audit data. The RCU seeds that database store with the schema required to store audit records in a database. After the schema is created, configuring a database audit store involves:
Creating a data source that points to the audit schema you created
Configuring the audit store to point to the data source
The data in the database audit store is exposed through pre-defined reports in Oracle Business Intelligence Publisher. These reports allow you to drill down the audit data based on various criteria, such as user name, time range, application type, and execution context identifier (ECID).
Out-of-the-box, there are several sample audit reports available with Security Token Service and accessible with Oracle Business Intelligence Publisher. You can also use Oracle Business Intelligence Publisher to create your own custom audit reports.
An audit log file helps the audit Administrator track errors and diagnose problems when the audit framework is not working properly. An audit log file records several fields including: Date, Time, Initiator, EventType, EventStatus, MessageText, ECID, RID ContextFields, SessionId, TargetComponentType, ApplicationName, and EventCategory to name a few.
The topic on audit logs in the chapter on configuring and managing auditing in the Oracle Fusion Middleware Security Guide
Specific administrative and run-time events that you can audit for Security Token Service are grouped together in Chapter 8, "Auditing Administrative and Run-time Events". Included with the events are the common instructions for setting up and validating auditing. For details, see: