| Oracle® Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service 11g Release 1 (11.1.1) Part Number E15478-05 |
|
|
View PDF |
| Oracle® Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service 11g Release 1 (11.1.1) Part Number E15478-05 |
|
|
View PDF |
This chapter introduces how to manage components involved in the protection of Oracle Security Token Service endpoints. This chapter provides the following topics:
Defining Security Token Service Settings Using Oracle Access Manager Console
Managing and Migrating Oracle Security Token Service Policies
Introduction to Logging Oracle Security Token Service Messages
Auditing Oracle Security Token Service Administrative and Run-time Events
This section identifies requirements for tasks in this chapter.
Before you begin tasks in this chapter, be sure to review the following topics:
Oracle Security Token Service a Web Service co-existing with Oracle Access Manager 11g. Oracle Security Token Service invokes some Oracle Access Manager components to validate and issue security tokens. Typically, the Web client can use the Oracle 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.
Oracle Security Token Service is integrated with the Oracle Access Manager Console to provide a unified and consistent administration experience. All Oracle Security Token Service system configuration is done using the Oracle Access Manager Console.
Oracle Security Token Service provides:
Tokens:
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 (Oracle Access Manager SSO, Federation, Oracle Web Services Manager) and external services
This section provides the following topics:
See Also:
Oracle Fusion Middleware Security and Administrator's Guide for Web ServicesAfter installation and server startup, you can access the Oracle Access Manager Console on the OAM Server. For example, if the URL to the OAM Server is http://machine:14100/oam, you might access:
Oracle Access Manager Console at http://machine:7001/oamconsole
Oracle 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 OSTS is correctly installed
By default, OSTS is disabled and as such all runtime functionality as well as Web Service endpoints are disabled. To access those endpoints, OSTS must first be enabled using the Oracle Access Manager 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.
Task overview: Oracle Security Token Service configuration requires
Server Side Configuration: Use the Oracle Access Manager Console for the following tasks.
Service enablement "Enabling and Disabling Services for Oracle 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 OSTS, for a specific Relying Party "Managing Token Issuance Policies and Constraints with Oracle Access Manager"
Set up interactions with the Oracle WSM Agent as described in following topics:
Set up message logging, as described in "Introduction to Logging Oracle Security Token Service Messages".
Configure event auditing, as described in "Auditing Oracle Security Token Service Administrative and Run-time Events".
Configure lifecycle management
Register the Oracle Security Token Service trust endpoint, as described in item 1c.
Register the Requester or Relying Party Partner with Oracle Security Token Service, as described in "Managing Token Service Partners".
Monitor performance, as described in Chapter 26, "Monitoring Performance and Logs with Fusion Middleware Control".
With Oracle Access Manager 11g, all Oracle Security Token Service instances are installed on OAM Servers (also known as Managed Servers). Each server must be registered with Oracle Access Manager.
Oracle Security Token Service leverages the common infrastructure for shared services and the Oracle Access Manager 11g administration model.
Oracle 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
Kerberos
X.509
Note:
Managed servers hosting Oracle Access Manager with Oracle Security Token Service must be registered with Oracle Access Manager as described in Chapter 6, "Managing Common OAM Server Registration".Third-Party Servers: Oracle 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 Oracle Security Token Service.
Oracle 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 "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 Oracle 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 OSTS endpoint. In those cases, the OSTS administrator should extract the OSTS 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 Oracle Security Token Service.
Oracle WSM Agent: The Oracle Web Services Manager (Oracle WSM) Agent is integrated with Oracle Security Token Service. This agent provides the Web Services Security support for Oracle Security Token Service Web Services endpoints.
Protects Web Services endpoints of Oracle 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 Oracle Security Token Service to get a security token that will be presented to the Relying Party
Interacts with Oracle Security Token Service for token acquisition and token validation
Oracle 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 Oracle 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 Oracle Security Token Service to enforce message protection of the SOAP communication channel between Oracle 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 Oracle Security Token Service must be configured to protect the Oracle Oracle 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.
OAM Webgate: Oracle Security Token Service uses Webgate for the OAM 11g 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 Oracle Security Token Service endpoint. By default, Oracle Security Token Service is configured with the endpoints shown in Figure 17-1.
Figure 17-1 Default Endpoints, Policies, and Validation Templates
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 Oracle Security Token Service. Oracle Security Token Service leverages ORAPROVIDER for Web Services to:
publish Web Services endpoints dynamically
invoke Oracle 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. Oracle 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
See Also:
Managing Web Service Security policies for Oracle Security Token Service
Oracle Fusion Middleware Security and Administrator's Guide for Web Services for details about the policies for Oracle Security Token Service
Policy Assertions: Out of the box, Oracle 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 Web Service Security: SOAP Message Security and WS-Trust.
Oracle Security Token Service makes its associated security policy files publicly available by attaching them to its deployed WSDL.
Oracle 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 Oracle Security Token Service and the Oracle WSM Agent.
Message-level Security Not Required: When message level-security is not required, use an Oracle 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 17-1.
Table 17-1 Policies Transport Security when Message-level Security Not Required
| Policy | Description |
|---|---|
|
sts/wss_username_token_over_ssl_service_policy |
Maps users using credentials provided in UNT tokens in the WS-Security SOAP header. The credentials in the UNT token are mapped based on the rules specified in the validation template. Both plain text and digest mechanisms are supported.The policy verifies that the transport protocol provides SSL message protection. |
|
sts/wss_saml_token_over_ssl_service_policy sts/wss_saml20_token_over_ssl_service_policy |
Maps users using credentials provided in SAML SV tokens in the WS-Security SOAP header. The credentials in the SAML token are mapped based on the rules specified in the validation template. The policy verifies that the transport protocol provides SSL message protection |
|
sts/wss_saml_token_bearer_over_ssl_service_policy sts/wss_saml20_token_bearer_over_ssl_service |
Maps users using credentials provided in SAML tokens with confirmation method 'Bearer' in the WS-Security SOAP header. The credentials in the SAML token are mapped based on the rules specified in the validation template. The policy verifies that the transport protocol provides SSL message protection |
|
sts/wss_sts_issued_saml_bearer_token_over_ssl_service_policy |
Interoperability WS-Security 1.0 and 1.1 Policies: Use policies in Figure 17-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.
Figure 17-2 WS-Security 1.0 and 1.1 Policies
Task overview: Using and modifying WS-S policies
From the Oracle Access Manager Console, System Configuration tab, open the Security Token Services section.
From the Endpoints node, proceed as described in "Managing Oracle 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:
About Oracle Security Token Service and the Oracle Access Manager Console
Enabling and Disabling Services for Oracle Security Token Service
Elements in the Oracle Access Manager 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 Oracle Security Token Service system configuration is done using the Oracle Access Manager 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 Manager Console enables administrators to perform the following Oracle 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 OSTS. OSTS 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:
Claim Mapping
Token Types definition
Issuance and Validation templates defined for the token Types
Override Validation Template rules for Issuing Authorities(Other STS)
Manage Oracle 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)
Oracle Security Token Service Global Settings
Custom tokens
Users with administrative access to the Oracle Access Manager Console, have access to Oracle Security Token Services.
Initially, administrative users must log in to the Oracle Access Manager 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 Oracle Access Manager and another for Oracle Security Token Service.
When using Oracle Security Token Service with Oracle Access Manager, logging in to, and signing out of the Oracle Access Manager Console is the same.
See Also:
Chapter 3 for the following topics:To use Oracle Security Token Service, both it and Oracle Access Manager must be enabled, as shown in Figure 17-3. By default Oracle Security Token Service is disabled and needs to be enabled.
Figure 17-3 Oracle Access Manager with Oracle Security Token Service 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.
Prerequisites
Oracle Access Manager service must be enabled.
To enable or disable Oracle Security Token Service
Log in to the Oracle Access Manager Console, as usual
https://hostname:port/oamconsole/
From the System Configuration tab, Common Configuration section, click Available Services.
Enable OSTS: Beside Oracle Security Token Service, click Enable (or confirm that the Status check mark is green) and confirm that the Oracle Access Manager Service is also enabled.
Disable OSTS: Beside Oracle Security Token Service, click Disable (or confirm that the Status check mark is red).
This section provides the following information:
Security Token Service Settings can be viewed or altered from the Security Token Services section of the System Configuration tab. These settings are show in Figure 17-4.
Figure 17-4 Security Token Service Settings Page
Table 17-2 describes the elements on the Security Token Service Settings page.
Table 17-2 Security Token Service Settings
| Element | Description |
|---|---|
|
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 Oracle Security Token Service, the server might map the incoming token containing the requester's identity to a partner entry in the Oracle Security Token Service partner store. To do so, Oracle 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, Oracle Access Manager and Oracle Security Token Service use the default It is possible to configure Oracle Security Token Service to use a specific trust anchor file if necessary, that will contain trust anchors only used for Oracle Security Token Service operations and validations. In this case, this field should contain the location of the JKS keystore to use. Note the following:
See Also: Chapter 18, "Managing Oracle Security Token Service Certificates and Keys" |
|
Default Encryption Template |
A list from which you choose the default template for Oracle Security Token Service encryption:
See Also: Setting the Default Encryption Key. |
|
Proxy |
Outbound Connection Properties, HTTP Proxy Settings Use this section to configure Oracle Security Token Service to use a proxy for outgoing HTTP connections when optionally retrieving the WS-Sec Policy of Relying Parties at runtime:
|
|
Keystore |
Location: Path of the active keystore that was set up during Oracle 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 After an entry is defined an entry, it can be used in other Oracle 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.
Prerequisites
Both the Oracle Access Manager Service and the Oracle Security Token Service must be enabled.
To view or edit Security Token Service Settings
Log in to the Oracle Access Manager Console, as usual.
https://hostname:port/oamconsole/
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 17-2):
Partner Identification Attributes
Custom Trust Anchor File
Proxy details
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 Web Service Security policies to protect Oracle Security Token Service Web Service endpoints. For instance:
classpath mode: Existing Web Service Security 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 Oracle Security Token Service in the following topics:
Managing WSS Policies for Oracle Security Token Service: Classpath
Managing WSS Policies for Oracle Security Token Service: Oracle WSM Policy Manager
This section introduces WS-Security Policies used to protect Oracle Security Token Service WS Endpoint and how to modify these policies. TheWS-Security Policies that are provided by Oracle should cover most use cases.
See Also:
"About Oracle Security Token Service End Points and Policies"
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 Oracle 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:
$IDM_ORACLE_HOME/oam/server/policy/sts-policies.jar
When your environment is in classpath mode, perform the following tasks to Administrators confirm sts-policies.jar is located on the classpath.
See Also:
"About Oracle Security Token Service End Points and Policies"
Oracle WSM Predefined Policies and Assertion Templates in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services
Task overview: Managing WSS Policies for Oracle Security Token Service: Classpath
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
Confirm that sts-policies.jar is located in the following path to enable the policy URI to be available the Policy URI drop down list.
$IDM_ORACLE_HOME/oam/server/policy/sts-policies.jar
Restart the Managed Servers running Oracle Security Token Service.
Proceed to the OAM Admin Console to configure the Oracle 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 Settings using Oracle Web Services Manager.
Note:
All of Oracle WSM's functionality is accessible to administrators from Oracle Enterprise Manager Fusion Middleware Control.See Also:
Oracle Fusion Middleware Security and Administrator's Guide for Web ServicesPart II, "Basic Administration"
Part III, "Advanced Administration"
Task overview: Managing WSS Policies for Oracle Security Token Service: OWSM Policy Manager
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 Oracle Security Token Service.
Proceed to "Configuring OWSM for WSS Protocol Communication".
This section describes how to configure communication between WS-Sec Clients and the Oracle WSM Agent embedded with Oracle Security Token Service.
The Oracle WSM Agent protects the Web Service endpoints of Oracle 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 Oracle 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)
Task overview: Configuring communication with Oracle WSM agents
See "About Oracle WSM Agent WS-Security Policies for Oracle Security Token Service"
Extracting the Oracle STS/Oracle WSM Signing and Encryption Certificate
The Oracle WSM Agent requires a repository to retrieve the Web Services Security (WSS) policies it needs. Oracle Access Manager supports two types of repositories for Oracle 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 Oracle 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 Oracle Security Token Service endpoints.
See Also:
"About the Policy and Session Database Store" for details about the OAM 11g required database for OAM policy data and (optionally) OAM user session dataAdministrators 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.
To retrieve the Oracle WSM keystore password
Enter the WSLT scripting environment.
Connect to the WebLogic Server AdminServer, using the connect() command.
Execute the following command by providing the connection information to the AdminServer: listCred(map="OAM_STORE", key="jks").
Note the password.
Proceed to "Extracting the Oracle STS/Oracle WSM Signing and Encryption Certificate".
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 OSTS endpoint. In those cases, the OSTS administrator should extract the OSTS 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 Oracle 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.
Prerequisites
Retrieving the Oracle WSM Keystore Password
To export the signing and encryption certificate
Locate keytool.
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.
Proceed to "Adding Trusted Certificates to the Oracle WSM Keystore".
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.
Prerequisites
Retrieving the Oracle WSM Keystore Password
The administrator must have the certificate to import.
To add trusted certificates to the Oracle WSM keystore
Locate keytool.
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.
Proceed to "Validating Trusted Certificates in the Oracle WSM Keystore".
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
This section provides the following topics:
Oracle 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):
$DW_HOME/oam/server/policy
The sts-policies.jar contains the stspolicies.prop file at the following location in the JAR:
META-INF/policies/sts/
This file lists all the policies packaged in the directory as file names to allow the server to read the JAR entries programatically when migrating policies to destination repository.
Note:
Be sure to update policies and stspolicies.prop as needed before migration.The following procedure outlines the various scenarios for policy updates.
Task overview: Updating policies and stspolicies.prop
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 Oracle 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, Oracle 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 Oracle Security Token Service within the same domain, ensure smooth operations between SOA and Oracle Security Token Service as follows:
The Oracle WSM protocol must be set to 'remote'.
Oracle 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. Oracle Access Manager 11g components use 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 Oracle Access Manager components. The administrator controls the amount of information that is logged in a message by specifying log levels for each Oracle Access Manager component for which a logger is defined.
Note:
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 all Oracle Access Manager components 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).
Oracle Access Manager with Oracle 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
In Oracle Access Manager with Oracle Security Token Service, and Oracle Fusion Middleware 11g, 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 Oracle Security Token Service administrative and run-time events that can be audited. Configuring common auditing settings for Oracle 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.
Oracle Access Manager with Oracle Security Token Service uses the Oracle Fusion Middleware Common Audit Framework to support auditing for a number of user 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 for Oracle Access Manager with Oracle Security Token Service is based on configuration parameters set in the Oracle Access Manager 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.
Oracle Access Manager with Oracle Security Token Service integrates with Oracle Business Intelligence Publisher, which provides a pre-defined set of compliance reports.
Oracle Access Manager with Oracle 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, Oracle Access Manager with Oracle 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)
Audit Vault
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 Oracle Access Manager 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.
See Also:
The topic on audit logs in the chapter on configuring and managing auditing in the Oracle Fusion Middleware Security GuideOracle Security Token Service provides an independent audit configuration file, component_events.xml, that defines specific event types and events to audit.
This section provides the following topics:
The following data is part of each audit record, regardless of the event or event type that is audited:
Date and time of event
IP address of the client initiating event
Client identity
Processing time for the event
Oracle Security Token Service administrative events fall into several configuration management operations defined in component_events.xml. See details in Table 17-3.
Table 17-3 Oracle Security Token Service Configuration Management Operations
| OSTS Configuration Management Operations | Description |
|---|---|
|
Common Attributes |
|
|
Create Validation Template |
Audit event recorded for the creation of a Validation Template referenced by CreateValidationTemplate. Attributes:
|
|
Update Validation Template |
Audit event recorded for the update of a Validation Template referenced by UpdateValidationTemplate. Attributes:
|
|
Delete Validation Template |
Audit event recorded for the delete event of a Validation Template referenced by DeleteValidationTemplate. Attributes:
|
|
Create Issuance Template |
Audit event recorded for the creation of an Issuance Template referenced by CreateIssuanceTemplate. Attributes:
|
|
Update Issuance Template |
Audit event recorded for the update of an Issuance Template referenced by UpdateIssuanceTemplate. Attributes:
|
|
Delete Issuance Template |
Audit event recorded for the delete event of an Issuance Template referenced by DeleteIssuanceTemplate. Attributes:
|
|
Create Partner Profile |
Audit event recorded for the creation of Partner Profile referenced by CreatePartnerProfile. Attributes:
|
|
Update Partner Profile |
Audit event recorded for the update of a Partner Profile referenced by UpdatePartnerProfile. Attributes:
|
|
Delete Partner Profile |
Audit event recorded for the delete event of Partner Profile referenced by DeletePartnerProfile. Attributes:
|
|
Create Partner |
Audit event recorded for the creation of Partner Profile referenced by CreatePartner. Attributes:
|
|
Update Partner |
Audit event recorded for the update of a Partner Profile referenced by UpdatePartner. Attributes:
|
|
Delete Partner |
Audit event recorded for the delete event of Partner Profile referenced by DeletePartner. Attributes:
|
|
Generic Admin Creation |
Audit event recorded for the generic create administrative operation referenced by GenericAdminCreation. Attributes:
|
|
Generic Admin Update |
Audit event recorded for the update of a generic update administrative operation referenced by GenericAdminUpdate. Attributes:
|
|
Generic Admin Removal |
Audit event recorded for generic delete administrative operation referenced by GenericAdminDeletion. Attributes:
|
Oracle Security Token Service-specific run-time events for token operations are defined in component_events.xml. See details in Table 17-4.
Table 17-4 Oracle Security Token Service-specific Run-time Events
| Token Operations | Description |
|---|---|
|
Common Attributes |
|
|
Incoming Message |
Incoming RSTR message received by Oracle Security Token Service referenced by OutgoingMessage. Attributes populated for this event, if available:
|
|
Outgoing Message |
Outgoing RSTR message received by Oracle Security Token Service referenced by IncomingMessage. Attributes populated for this event, if available:
|
|
Token Validation |
Audit event for token validation in Oracle Security Token Service referenced by TokenValidation. The status attribute indicates whether or not the validation operation was successful. Attributes populated for this event, if available:
|
|
Token Generation |
Audit event for token generation in Oracle Security Token Service referenced by TokenGeneration. Attributes populated for this event, if available:
|
|
LDAP User Authentication |
Audit event for local user authentication with the LDAP Directory referenced by LDAPUserAuthentication. Attributes populated for this event, if available:
|
|
Generic Runtime Operation |
Audit event for a generic operation performed by Oracle Security Token Service referenced by GenericRuntimeOperation Attributes populated for this event, if available:
|
|
 Copyright © 2000, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|