Security Token Service, a Web Service co-existing with Access Manager, 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
The following topics describe how to configure the Security Token Service settings:
See Administering Web Services for more information.
After you completed the installation and started the server, 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 can 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
You need to perform the following post-installation configuration tasks::
For the Server Side Configuration on the Oracle Access Management Console, use the following:
Token Issuance Template configuration
Token Validation Template configuration
Partner Profile creation
Token Issuance Policies to define an authorization rule for issuing tokens with Security Token Service, for a specific Relying Party.
Set up interactions with the Oracle WSM Agent as described in following topics:
Set up message logging.
Configure event auditing.
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.
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 that host Security Token Service must be registered with Access Manager.
Third-Party Servers: Security Token Service interoperates with third party security token servers.
For example, 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 not in scope).
See "WS-Trust Policies and Configuration Steps" in Administering 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.
Oracle Web Services Manager communicates through 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.
Figure 43-1shows the default settings for the Security Token Service with endpoints.
Figure 43-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 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
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.
You can configure two-way or one-way SSL for the core WebLogic Server security.
See Testing OWSM Security Policies in Oracle Fusion Middleware Administering Web Services guide.
See Table 43-1 for policies.
Interoperability WS-Security 1.0 and 1.1 Policies:
if you require interoperability with WS-Security 1.0 or 1.1 (depending on your authentication requirements and credential availability), you need to use the following policies:
See Figure 43-2.
If you have strong security requirements, you need to use WS-Security 1.1 policies.
Figure 43-2 WS-Security 1.0 and 1.1 Policies
You can use and modify a specific WS Security policy to protect the endpoint.
You need to perform the following tasks to use and modify WS-S policies: