| Oracle® Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service 11g Release 1 (11.1.1) Part Number E15478-06 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service 11g Release 1 (11.1.1) Part Number E15478-06 |
|
|
PDF · Mobi · ePub |
This chapter provides a high-level overview of Oracle Access Manager 11g and Oracle Security Token Service with links to more information. This chapter contains the following sections:
Oracle Access Manager 11g provides a full range of Web perimeter security functions that include Web single sign-on; authentication and authorization; policy administration; auditing, and more.
Single sign-on (SSO) enables users, and groups of users, to access multiple applications after authentication. SSO eliminates multiple sign-on requests. Oracle Access Manager 11g is the Oracle Fusion Middleware 11g single sign-on solution. Oracle Access Manager 11g operates independently as described in this book and also operates with the Oracle Access Manager Authentication Provider as described in the Oracle Fusion Middleware Application Security Guide
Oracle Access Manager 11g is a Java Platform, Enterprise Edition (Java EE)-based enterprise-level security application that provides restricted access to confidential information and centralized authentication and authorization services. All existing access technologies in the Oracle Identity Management stack converge in Oracle Access Manager 11g.
A Web server, Application Server, or any third-party application must be protected by a Webgate or mod_osso instance that is registered with Oracle Access Manager as an agent. To enforce policies, the agent acts as a filter for HTTP requests. Oracle Access Manager enables administrators to define authentication and authorization policies.
Note:
Webgates are agents provided for various Web servers by Oracle as part of the product. Custom access clients, created using the Access Manager SDK, can be used with non-Web applications. Unless explicitly stated, information in this book applies equally to both.You can also integrate with OAM 11g, any Web applications currently using Oracle ADF Security and the OPSS SSO Framework, as described in Appendix C.
The remainder of this section provides the following topics:
Introduction to Oracle Access Manager Deployment Types and Installation
Comparing Oracle Access Manager 11g, 10g, and OracleAS SSO 10g
There are several important differences between Oracle Access Manager 11g and Oracle Access Manager 10g,, and OSSO 10g, as described in "Comparing Oracle Access Manager 11g, 10g, and OracleAS SSO 10g".
This topic provides an overview of Oracle Access Manager 11g, which sits on Oracle WebLogic Servers and is part of the Oracle Fusion Middleware Access Management architecture.
While providing backward compatibility and co-existence with existing solutions, Oracle Access Manager 11g replaces and converges the following earlier technologies:
Oracle Access Manager 10g
Oracle Application Server SSO (OSSO) 10g
Figure 1-1 illustrates the primary Oracle Access Manager 11g components and services. The Protocol Compatibility Framework interfaces with OAM Webgates, mod_osso agents, and custom Access Clients created using the Access Manager Software Developer Kit (SDK).
Figure 1-1 Oracle Access Manager 11g Components and Services
Figure 1-2 illustrates the distribution of Oracle Access Manager components.
Figure 1-2 Oracle Access Manager 11g Component Distribution
The Oracle Access Manager Console resides on the Oracle WebLogic Administration Server (known as AdminServer). WebLogic Managed Servers hosting OAM runtime instances are known as OAM Servers.
Shared information consists of:
Agent and server configuration data
Oracle Access Manager policies
User session data is shared among all OAM Servers
This section provides a brief overview of OAM deployments and installation:
Table 1-1 describes the types of deployments you might have within your enterprise, even though these might be named differently in your enterprise.
Table 1-1 Deployment Types
| Deployment Type | Description |
|---|---|
|
Development Deployment |
Ideally a sandbox-type setting where the dependency on the overall deployment is minimal |
|
QA Deployment |
Typically a smaller shared deployment used for testing |
|
Pre-production Deployment |
Typically a shared deployment used for testing with a wider audience |
|
Fully shared and available within the enterprise on a daily basis |
During initial installation and configuration you can create a new WebLogic Server domain (or extend an existing domain) and define information for OAM Servers, Database Schemas, optional WebLogic Managed Servers and clusters, and the embedded LDAP Server.
See Also:
The "Understanding Oracle WebLogic Server Domains" chapter in the Oracle Fusion Middleware Understanding Domain Configuration for Oracle WebLogic Server guide provides information about Oracle WebLogic Server administration domains.Regardless of the deployment size or type, in a new WebLogic Server domain the following OAM-related components are deployed using the Oracle Fusion Middleware Configuration Wizard:
WebLogic Administration Server
Oracle Access Manager Console deployed on the WebLogic Administration Server
A WebLogic Managed Server for Oracle Access Management
Application deployed on the Managed Server
Note:
In an existing WebLogic Server domain, the WebLogic Administration Server is already installed and operational.While using the Oracle Fusion Middleware Configuration Wizard, the with-DB config template was chosen to set up the database for application domain metadata. The database must be extended with the OAM-specific schema using the Repository Creation Utility (RCU). The policy store bootstrap occurs on the initial AdminServer startup after running the Configuration Wizard. For more information, see the Oracle Fusion Middleware Installation Guide for Oracle Identity Management.
The default Embedded LDAP is set as the primary user identity store for OAM 11g.
A Java keystore is set up to be used for certificates for Simple or Certificate-based communication between OAM Servers and Webgates during authorization. The keystore bootstrap also occurs on the initial AdminServer startup after running the Configuration Wizard.
During initial deployment, the WebLogic Administrator userID and password are set for use when signing in to both the Oracle Access Manager Console and WebLogic Server Administration Console. A different administrator can be assigned for Oracle Access Management (Oracle Access Manager and Oracle Security Token Service, as described in "Introduction to Administrators".
Oracle Access Management administrators can log in and use the Oracle Access Manager Console to manage:
User identity stores
OAM Server registration
Partner (agent and partner application) registration
Application domains and policies to protect resources
User sessions
Common Server Properties
Oracle Security Token Service Settings and configuration as introduced in "Introduction to Oracle Security Token Service".
The Oracle Fusion Middleware Supported System Configurations document provides certification information on supported installation types, platforms, operating systems, databases, JDKs, and third-party products related to Oracle Identity Management 11g. You can access the Oracle Fusion Middleware Supported System Configurations document by searching the Oracle Technology Network (OTN) Web site:
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
Following installation, you can configure Oracle Access Manager in a new WebLogic Server domain or in an existing WebLogic Server domain. Using the Oracle Fusion Middleware Configuration Wizard, the following components are deployed for a new domain:
WebLogic Administration Server
Oracle Access Manager Console deployed on the WebLogic Administration Server (sometimes referred to as the OAM Administration Server, or simply AdminServer)
A Managed Server for Oracle Access Manager
An application deployed on the Managed Server
See Also:
Patching Oracle Identity and Access Management 11.1.1.3.0 to 11.1.1.5.0 in the Oracle Fusion Middleware Patching Guide
Oracle Fusion Middleware Installation Guide for Oracle Identity Management
OracleAS 10g SSO deployments can be upgraded to use Oracle Access Manager 11g SSO. After upgrading and provisioning OSSO Agents with OAM 11g, authentication is based on OAM 11g Authentication Policies. However, only OAM Agents (Webgates/Access Clients) use OAM 11g Authorization Policies. Over time, all mod_osso agents in the upgraded environment should be replaced with Webgates to enable use of OAM 11g Authorization policies.
For details about co-existence after the upgrade, see:
Oracle Fusion Middleware Upgrade Planning Guide
Oracle Fusion Middleware Upgrade Guide for Oracle Identity Management (E10129-02)
This section provides the following topics:
Oracle Access Manager 10g Functionality Not Available with 11g
Comparing Oracle Access Manager 11g, 10g, and OracleAS SSO 10g
Oracle Access Manager 11g includes several important enhancements that were not available with Oracle Access Manager 10g. Enhancements are listed in Table 1-2.
See Also:
"What's New"Table 1-2 Enhancements in Oracle Access Manager 11g
| New Functionality for Oracle Access Manager 11g |
|---|
|
|
Built-in support for OracleAS 10g SSO partner applications, and for single sign-on across OSSO 10g-protected applications and OAM 10g Webgate protected applications. See Part IV. Per-agent-based shared secret key increases security and performance by moving cookie encryption and description to the agent. See Chapter 9 and Chapter 11. |
|
Embedded LDAP for user and group information is described in Chapter 5. Integration with Oracle Entitlement Server MicroSM to enable database storage of policies. See Chapter 5. |
|
|
A new OAM 11g Access Tester replaces the OAM 10g Access Tester for on-the-fly evaluation of Oracle Access Manager policies. See Chapter 14. |
|
Session Management functions are provided, as described in Chapter 7:
|
|
Events can be audited using the underlying Oracle Fusion Middleware Common Audit Framework, as described in Chapter 24. |
|
Windows Native Authentication is supported with applications protected with either an OSSO Agent or OAM Agent. For more information, see Oracle Fusion Middleware Integration Guide for Oracle Access Manager. |
|
Extensibility framework required for building custom authentication plug-ins. For more information, see Oracle Fusion Middleware Developer's Guide for Oracle Access Manager and Oracle Security Token Service. |
|
Complex policy constructs (AND, OR semantics for multiple rules) |
|
Impersonation support |
Oracle Access Manager 10g provides several functions that are not included with Oracle Access Manager 11g. Table 1-3 provides an overview.
Table 1-3 OAM 10g Functionality Not Available with Oracle Access Manager 11g
| Unavailable or Unsupported Functions |
|---|
|
Extensibility framework required for building custom authorization plug-ins. |
|
Application-domain-level delegated administration |
|
LDAP filter-based authorization and response calculations |
|
Authorization for mod_osso-protected resources |
|
Identity Server, WebPass, Identity System Console, User Manager, Group Manager, Organization Manager. Replaced by Oracle Fusion Middleware Identity Manager. |
This topic provides a comparison against the 10g architecture for Oracle Access Manager and OSSO. Included are the following topics:
Oracle Access Manager 11g differs from Oracle Access Manager 10g in that the identity administration features have been transferred to Oracle Identity Manager 11g (including user self-service and self registration, workflow functionality, dynamic group management, and delegated identity administration).
Oracle Access Manager 10g supported Single Sign-on using a single session cookie (the ObSSOCookie) that contained the user identity and user session information required to access target resources that had the same or lower authentication level. The ObSSOCookie was encrypted and decrypted using a global shared secret key, the value of which was stored in the directory server. The ObSSOCookie was consumed by Access System components to verify the user identity and allow or disallow access to protected resources.
To close any possible security gaps, Oracle Access Manager 11g provides new server-side components that maintain backward compatibility with existing Oracle Access Manager 10g policy-enforcement agents (Webgates) and OSSO 10g agents (mod_osso). New Oracle Access Manager 11g Webgates are enhanced versions of 10g Webgates, that support a per-agent secret key for the Single Sign-on (SSO) solution. Thus, cookie-replay type of attack are prevented. The 11g Webgates are all trusted at the same level; a cookie specific for the Webgate is set and cannot be used to access any other Webgate-protected applications on a user's behalf.
Unless explicitly stated, the term "Webgate" refers to both an out of the box Webgate or a custom Access Client.
Oracle Access Manager 11g uses technology from Oracle Coherence to provide centralized, distributed, and reliable session management.
Table 1-4 provides a comparison of Oracle Access Manager 11g, OAM 10g, and OracleAS SSO 10g. For a list of names that have changed with Oracle Access Manager 11g, see "Product and Component Name Changes".
Table 1-4 Comparison: OAM 11g versus OAM 10g versus OSSO 10g
| OAM 11g | OAM 10g | OSSO 10g | |
|---|---|---|---|
|
Architecture Components |
Note: Eight Administrator languages are supported. |
Note: Eight Administrator languages are supported. |
|
|
Cookies |
Host-based authentication cookie:
|
|
|
|
Cryptographic keys The protocols used to secure information exchange on the Internet. |
|
One global shared secret key for all Webgates |
|
|
Key storage |
|
Global shared secret stored in the directory server only (not accessible to Webgate) |
|
|
Encryption / Decryption (The process of converting encrypted data back into its original form) |
Introduces client-side cryptography and ensures that cryptography is performed at both the agent and server ends:
|
|
Cryptography is performed at both mod_osso and OSSO server:
|
|
Session Management |
|
|
|
|
Client IP |
|
|
|
|
Response token replay prevention |
|
N/A |
|
|
Centralized log-out |
For more information, see Chapter 15. |
|
The OSSO server cookie includes a list of partner IDs. When a user logs off from one partner application:
|
Oracle Security Token Service is deployed with Oracle Access Manager and must be activated as a service.
See Also:
Patching Oracle Identity and Access Management 11.1.1.3.0 to 11.1.1.5.0 in the Oracle Fusion Middleware Patching Guide
Oracle Security Token Service provides the foundation to the current security infrastructure to facilitate a consistent and streamlined model for token acquisition, renewal, and cancellation that is protocol and security infrastructure agnostic.
Oracle Security Token Service is a Web Service (WS) Trust-based token service that allows for policy-driven trust brokering and secure identity propagation and token exchange between Web Services. Oracle Security Token Service can be deployed as a Security and Identity Service needed to simplify the integration of distributed or federated Web services within an enterprise and its service providers.
Oracle Security Token Service is primarily based on the OASIS WS-Trust protocol. However, Oracle Security Token Service delegates the processing of other WS-* protocols present in the SOAP message.
Oracle Security Token Service brokers trust between a Web Service Consumer (WSC) and a Web Service Provider (WSP) and provides security token lifecycle management services to providers and consumers. Oracle Security Token Service can help simplify the effort needed to bridge access to various systems using a standardized set of interfaces.
Oracle Security Token Service (Oracle STS) augments Oracle Identity Federation (OIF), which facilitates Federated Single Sign-on (SSO) and Single Logout (SLO) for users coming through a Web browser to access resources across different security domains or across administrative boundaries through various federation protocols like SAML, WS-Federation, Liberty, or OpenID.
Security tokens contain claims or statements that are used to assert trust. To secure communication between a Web service client and a Web service, the two parties must exchange security credentials. These credentials can be obtained from a trusted Security Token Service (STS). To provide interoperable security tokens, the STS must be trusted by both the Web service client and the Web service.
Modern IT environments have numerous types of security tokens, most of them based on browser cookies to facilitate SSO and application session management for Web applications. Additional tokens include Kerberos (primarily for Windows Native Authentication), Security Assertion Markup Language (SAML) assertions, and even digital certificates.
For more information, see the following topics:
Table 1-5 identifies common Oracle Security Token Service terminology.
Table 1-5 Oracle Security Token Service Terms
| Term | Description |
|---|---|
|
Security Token |
A security mechanism that protects messages using a token issued by a trusted Secure Token Service for message integrity and confidentiality protection. The issued tokens contain a key, which is encrypted for the server and which is used for deriving new keys for signing and encrypting. Service providers and consumers in potentially different managed environments can use a single Security Token Service to establish a chain of trust. The service does not trust the client directly, but instead trusts tokens issued by a designated Security Token Service. The Security Token Service is taking on the role of a second service with which the client must securely authenticate. |
|
Security Token Service |
A trusted third party in an explicit trust relationship with the server (and a trust relationship with the client). Oracle Security Token Service is one example. |
|
Secure Token Service |
A shared Web service that provides a standards-based consolidated mechanism of trust brokerage between different identity domains and infrastructure tiers. The service implements the protocol defined in the WS-Trust specification by making assertions based on evidence that it trusts, to whoever trusts it (or to specific recipients). This protocol defines message formats and message exchange patterns for issuing, renewing, canceling, and validating security tokens. To communicate trust, a service requires something to prove knowledge of a security token or set of security tokens. An XML Signature binds the sender's identity (or “signing entity”) to an XML document, for example. The document is signed using the sender's private key, the signature is verified using the sender's public key. |
|
Request Security Token (RST) |
Request for a security token. |
|
Request Security Token Response (RSTR) |
Response generated by Oracle Security Token Service in response to the Request for Security Tokens with claims for the requested user. |
|
On Behalf Of (OBO) |
An OBO Request Security Token (RST) is used when only the identity of the original client is important. An OBO RST indicates that the requestor wants a token containing claims about only one entity:
|
|
ActAs |
An ActAs RST requires composite delegation. The final recipient of the issued token can inspect the entire delegation chain (not just the client). An ActAs RST indicates that the requestor wants a token that contains claims about distinct entities:
|
|
Token Exchange |
The exchange of one security token for another. The requestor (in order to invoke a web service) requires a particular token. It uses Oracle Security Token Service to exchange the incoming token with a token required by the service. |
|
WS-Security |
Web Services Security (WS-Security) specifies SOAP security extensions that provide confidentiality using XML Encryption and data integrity using XML Signature. The most prevalent security tokens used with WS-Security are Username, X.509 Certificates, SAML assertions, and Kerberos tickets (all supported by Oracle Web Service Manager). WS-Security also includes profiles that specify how to insert different types of binary and XML security tokens in WS-Security headers for authentication and authorization purposes: WS-* specifications often depend on each other. For example, WS-Policy is used in conjunction with WS-Security. WS-* specifications also leverage non-WS-* specifications; for example, WS-Security uses XML Encryption and XML Signature. For WS-Security, only SAML assertions are used. The protocols and bindings are provided by the WS-Security framework. Note: WS-Security, WS-Trust, WS-Policy have been transferred over to standards bodies such as the Organization for the Advancement of Structured Information Standards (OASIS) or the World Wide Web Consortium (W3C). |
|
WS-Trust |
Web Services Trust Language (WS-Trust) is a specification that uses the secure messaging mechanisms of WS-Security to facilitate trust relationships. WS-Trust defines a request and response protocol that enables applications to construct trusted SOAP message exchanges. Trust is represented through the exchange and brokering of security tokens. In a message exchange using WS-Security only, it is assumed that both parties involved in the exchange have a prior agreement on which type of security tokens they must use for sharing security information. However, there are cases where these parties do not have such an agreement, as a result trust must be established before exchanging messages. Trust between two parties exchanging SOAP / WS-Security-based messages is established by implementing the WS-Trust specification. |
|
WS-Policy |
Web Services Policy (WS-Policy). Together with WS-Security, WS-Policy is another key industry standard for Oracle Fusion Middleware security. WS-Policy is used in conjunction with WS-Security. A web service provider may define conditions (or policies) under which a service is to be provided. The WS-Policy framework enables one to specify policy information that can be processed by web services applications, such as Oracle Web Services Manager. A policy is expressed as one or more policy assertions representing a web service's capabilities or requirements. For example, a policy assertion may stipulate that a request to a web service be encrypted. Likewise, a policy assertion can define the maximum message size that a web service can accept. |
|
Certificates |
The certificates used by Oracle Security Token Service are self signed. The subject and the issuer field are identical. Out of the box, the OAM Server hosting Oracle Security Token Service is uniquely identified: |
|
Keystore |
Oracle Security Token Service key stores include:
See Also: Chapter 18, "Managing Oracle Security Token Service Certificates and Keys" |
|
User Name Token (UNT) |
Identifies the requestor by their username, and optionally using a password (or shared secret, or password equivalent) to authenticate that identity. When using a username token, the user must be configured in the Default User Identity Store., |
|
X.509 Certificates |
A signed data structure designed to send a public key to a receiving party. A certificate includes standard fields such as certificate ID, issuer's Distinguished Name (DN), validity period, owner's DN, owner's public key, and so on. Certificates are issued by certificate authorities (CA), for example Verisign. A CA verifies an entity's identity and grants a certificate, signing it with the CA's private key. The CA publishes its own certificate which includes its public key. Each network entity has a list of the certificates of the CAs it trusts. Before communicating with another entity, a given entity uses this list to verify that the signature of the other entity's certificate is from a trusted CA. |
|
Security Assertion Markup Language (SAML) SAML Assertion |
An open framework for sharing security information on the Internet through XML documents. SAML provides:
For WS-Security, only SAML assertions are used. However, the protocols and bindings are provided by the WS-Security framework. SAML assertions can include three types of statements:
|
|
Kerberos |
A cross-platform authentication and single sign-on system. The Kerberos protocol provides mutual authentication between two entities relying on a shared secret (symmetric keys). Kerberos authentication requires a client, a server, and a trusted party to mediate between them called the Key Distribution Center (KDC). Also required:
The Kerberos Token profile of WS-Security allows business partners to use Kerberos tokens in service-oriented architectures (SOAs). |
Oracle Security Token Service is compliant and co-exists with Oracle Access Manager (using Oracle Access Manager as the primary authenticator for Web clients requesting tokens).
Oracle Security Token Service is installed with Oracle Access Manager 11g on Managed Servers. Each Managed Server must be registered with Oracle Access Manager to open communication channels. All Oracle Security Token Service system configuration is done using the Oracle Access Manager Console. Oracle Security Token Service inter-operates with third party security token servers.
Oracle Security Token Service uses Oracle Web Services Manager Agents. Webgate is used as an Agent for identity propagation. The Webgate must be registered with Oracle Access Manager 11g to open a communication channel.
Oracle Security Token Service leverages the common infrastructure for shared services and the Oracle Access Manager 11g administration model. In addition, Oracle Security Token Service is integrated with the Oracle Access Manager Console to provide a unified and consistent administration experience.
Oracle Security Token Service adopts the same frameworks, guidelines, and practices for diagnostics, monitoring, auditing, and high availability used by Oracle Access Manager 11g. For more information, see Part VI, "Common Logging, Auditing, Performance Monitoring".
Oracle Security Token Service processing:
Integrates with STS Audit events
Publishes, in the Oracle Access Manager Console and WLST scripts, available Oracle Security Token Service methods to manage partner data
Performs validation operations specific to the Oracle Security Token Service use cases and configuration model
The Oracle Security Token Service 11g infrastructure is described in Table 1-6.
Table 1-6 Oracle Security Token Service 11g Infrastructure
| Component | Description |
|---|---|
|
Default Trust Keystore |
Oracle Security Token Service private keys used for Signing/Encryption are stored in the common keystore used with Oracle Access Manager. Oracle Security Token Service and Oracle Access Manager use the common infrastructure certification validation module. Trusted Certificates and Certificate Revocation Lists (CRLs) used during certificate validation are stored in Trust Keystore and CRL ZIP file. The Oracle Security Token Service configuration stores the OCSP/CDP settings. The token security key pair is populated to Oracle Access Manager/Oracle Security Token Service keystore. Note: When the Oracle WSM Agent is used as the WS_Trust client in the OSTS deployment, Oracle strongly recommends that the Oracle WSM Agent keystore and the OSTS/OAM keystore always be different. Do not merge the two. Otherwise, OAM/OSTS keys could be available to any modules authorized by OPSS to access the keystore and OAM keys might be accessed. |
|
Default User Identity Store |
Oracle Security Token Service authenticates and maps users against the User Identity stores configured through the Common Configuration section of System Configuration in the Oracle Access Manager Console. Oracle Security Token Service maps the incoming token to user records and attributes in the default User Identity Store, which operates with both Oracle Access Manager and Oracle Security Token Service. See Also: "About Setting the Default Store and System Store". |
|
Certificates |
The certificates used by Oracle Security Token Service are self signed. The subject and the issuer field are identical. Out of the box, the OAM Server hosting Oracle Security Token Service is uniquely identified:
This ensures that two servers are not identical in terms of cryptographic materials and identifiers. The trust granted to one server by third-party modules is not granted to the other server because the identifiers and cryptographic keys differ. There are no identical keys, no identical identifiers, and authorization policies are in denial mode. |
|
Oracle Coherence |
Oracle Security Token Service integrates with the Oracle Coherence module to store and share run time WS-Trust data across all the physical instances of Oracle Security Token Service. The UserNameToken Nonce are stored in the Coherence store. This implementation supports the following requirements, which might be specific to Oracle Security Token Service:
|
In the 11g release, Oracle Web Services Manager (WSM) security and management has been integrated into the Oracle WebLogic Server along with Oracle WSM Agent functionality. Table 1-7 describes these components.
Table 1-7 Integrated Oracle Web Services Manager
| Component | Description |
|---|---|
|
Java Keystore (JKS) |
Required to store the signature and encryption keys required by the X.509 token on the client. JKS the proprietary keystore format defined by Sun Microsystems. Trusted certificates and public and private keys are stored in the keystore. To create and manage the keys and certificates in the JKS, use the keytool utility. Keys are used for a variety of purposes, including authentication and data integrity. If the client and Web service are in the same domain with access to the same keystore, they can share the same private/public key pair:
|
|
Policy Interceptors |
In Oracle Fusion Middleware 11g, Oracle WSM Agents are managed by the security and management policy interceptors. Policy Interceptors enforce policies, including reliable messaging, management, addressing, security, and Message Transmission Optimization Mechanism (MTOM). The Oracle WSM Agent manages the enforcement of policies using the Policy Interceptor Pipeline. For complete Oracle Web Services Manager details, including the differences between release 10g and 11g, see Oracle Fusion Middleware Security and Administrator's Guide for Web Services. |
|
Oracle WSM Agent |
The OWSM agent is the certified WS-Trust client that can be used to communicate with OSTS. The OWSM agent is embedded and used by Oracle Security Token Service for message protection only (to publish WS Policy and to enforce message protection on inbound and outbound WS messages). Oracle Security Token Service performs token validation/request authentication.
Note: Embedded means that the OWSM Agent is available as part of the JRF layer on the WebLogic Server that OSTS uses: |
|
Message/Token Protection |
Oracle Security Token Service/Oracle Access Manager manages its own keystore and trust store. For Oracle WSM to enforce message protection for Oracle Security Token Service, the OWSM key store is seeded with its own self-signed certificate; passwords for its corresponding keys are stored in CSF. It does not work with OSTS keystore. Note: Conversely, Oracle WSM requires Oracle Access Manager/Oracle Security Token Service to store keys related to message protection in the OPSS Keystore. For cases where the client uses schemes such as SKI, Thumbprint, and so on to refer to its certificate, Oracle WSM requires that client certificate(s) are present in the OPSS Keystore. |
|
Token Signing Key |
Oracle Security Token Service has strong security requirements around its token signing key and uses the token signing key to broker trust between a client and a relying party. Therefore, this key must be stored in an exclusive partition that only Oracle Security Token Service can access. |
|
Security Key Pairs |
Oracle Security Token Service creates separate key pairs for issued token security and message security to provide security of token signing keys and eliminate the need for Oracle WSM agents to work with Oracle Access Manager/Oracle Security Token Service keystore:
|
|
OPSS Keystore |
The message security key pair is populated to OPSS Keystore. For special cases where clients use referencing schemes such as SKI (not a certificate token being received as part of the Web service request), Oracle Security Token Service populates OPSS Keystore with the requesting party's certificates. This is an uncommon scenario. Oracle Security Token Service can provide instructions on manually provisioning the keys to OPSS keystore to make it work. |
Oracle STS, is a centralized token service that supports WS-Trust protocol, which defines extensions to the WS-Security specification for issuing and exchanging security tokens and establishing trust relationships. The Oracle STS is hosted as a web service endpoint and coordinates security based interactions between a WSC and a WSP. All communication with the Oracle STS occurs through a WS_Trust client, as shown in Figure 1-3.
When a WSC makes a call to the WSP, it gets the WS-Security policy that will indicate that a security token issued by Oracle STS should be presented. The policy will contain the location of Oracle STS, and the WSC will use that location to contact Oracle STS, and get the token expected by the WSP (Alternately, the WSP could register its acceptable security mechanisms with the Security Token Service and, before validating the incoming SOAP request, could check with the Security Token Service to determine its security mechanisms). When an authenticated WSC (carrying credentials that confirm either the identity of the end user or the application) requests a token for access to a WSP, the Security Token Service verifies the credentials and, in response, issues a security token that provides proof that the WSC has been authenticated. The WSC presents the security token to the WSP which verifies that the token was issued by a trusted Security Token Service.
Figure 1-4 shows the token support matrix for Oracle STS.
This section provides the following topics to introduce several different deployment options:
The need for a token exchange for security integration between Web SSO and Web service security tiers is in demand in a deployment where a Web application makes internal or external Web service calls.
An example of such application is an intranet portal integration with external Web service provided by a partner or another organization within the same company. The portal needs a way to securely access the service.
The difficulty of security integration in this case stems from the fact that web SSO tier and WS tier use different methods of user authentication. In the Web SSO environment, the Web application can accept WAC-issued session tokens (SMSESSION, OBSSO), SAML assertions or proprietary tokens to authenticate the users.
The WS* security tier also uses a variety of tokes, standard and proprietary, and in most cases to achieve integration between the two tiers, local translation of token is required. In most cases, the WS performing the translation, needs to contact the authority by which the token was issued (Oracle Adaptive Access Manager) in order to decompose the token, before it can be translated. That requires every WS service to maintain trust with WAC systems. This is complex and not very secure because of multiple trust links that need to be maintained.
With the introduction of Oracle Security Token Service, the translation of tokens can be done at the centralized authority, as shown in Figure 1-5.
Figure 1-5 Token Translation at a Centralized Authority
The situation when applications rely on special form of credentials for their business logic is very common in deployments of Oracle access products. Integrations of WAC systems with both Oracle and custom applications almost always require extensive coding for (1) decomposing token issued by one token authority (such as OAM or SiteMinder) by calling a proprietary vendor API (SM agent API or ASDK) and (2) composing a new token format (PSFT, Siebel), that the application requires for its internal business logic.
Such translations are often handled through application coding, which introduces an element of risk of exposing user names and passwords when the code is deployed on multiple application instances in the DMZ.
Security administrators need an ability to control the translation process by externalizing it from the application. Introduction of Oracle Security Token Service provides significant relieve in this situation. Oracle Security Token Service plays a role of a centralized token authority, performing a translation of tokens behind the firewall, as shown in Figure 1-6.
Figure 1-6 Translating Tokens Behind a Firewall
Application 1 and Application 2 are protected by Oracle Access Manager. The Application 2 relies on a different type of token for its internal business logic. It has a client-side connector that contacts Oracle Security Token Service for exchanging the OBSSO token for a username token. The Oracle Security Token Service relies on Oracle Access Manager for decomposing the OBSSO token and generates a new token, required by Application 2.
This is more secure, because the same authority (Oracle Access Manager) performs both operations (composing and decomposing the OBSSO token). There is no need to decompose the token on the application side.
As in the Web SSO case, Web services SSO is a convenience feature. The difference is that in the case of Web SSO the party who benefits from the feature is a user. In the WS environment:
Web SSO: The user benefits
Web Services SSO: Security administrators benefit.
With Web services SSO different Web services have different token requirements, which change often. Externalizing the exchange to Oracle Security Token Service, however, enables the application to simply supply the target and the current token in its possession. Oracle Security Token Service takes charge of determining the token type for each requested service.
When one or more Web services change their authentication requirements, Oracle Security Token Service can seamlessly verify the token type submitted by the application. If the token is not of the requested type, the old token is revoked and the new one of the correct type is issued.
Figure 1-7 illustrates Web services SSO.
This section provides the following topics as a brief overview to various installation options:
You can leverage clustering across Oracle Security Token Service instances deployed in different managed servers within a single WebLogic domain. This deployment topology facilitates High Availability capabilities through a load balancer. By default, Oracle Access Manager co-exists on the same managed server as Oracle Security Token Service. However, Oracle Security Token Service is disabled by default and must be manually enabled before it can be used.
This deployment topology means that you:
Deploy multiple instances of Oracle Security Token Service through the suite installer.
Deploy a load balancer to support the High Availability and failover scenarios on the front of the Oracle Security Token Service cluster.
For more information, see the Oracle Fusion Middleware High Availability Guide.
This installation option provides inter-operability of Requester and Relying Party with Third-party STS Servers. At runtime, Oracle Security Token Service supports interoperability with Requesters and Relying Parties of third-party security token servers using the OPSS WS-Trust-Provider. For instance, a third-party security token service can create a valid SAML Assertion that can be consumed by Oracle Security Token Service.
All run-time scenarios for Requesters and Relying Parties are supported by other Oracle WS-Trust Clients, including: WLSClient, MetroClient, and Oracle Web Services Manager (Oracle WSM).
All Web services clients are supported with Oracle Security Token Service only through the WS-Trust binding.
Oracle Access Manager and Oracle Security Token Service are installed together from a single ear file. Oracle Access Manager and Oracle Security Token Service are deployed on the same managed server in a WebLogic domain.
The Oracle WSM Agent uses a keystore for various cryptographic operations. For those tasks, the Oracle WSM Agent uses the keystore configured for Oracle WSM tasks. During installation, if the Oracle WSM keystore service has not been configured, the installer:
Creates a new keystore in the $DOMAIN_HOME/config/fmwconfig folder (default name is default-keystore.jks
Creates a key entry with the corresponding certificate to be used by OWSM for signature and encryption operations. This key entry is stored in the OWSM Keystore under the orakey alias
Stores the passwords of the key entry and of the keystore in CSF
Having access to the keystore is sometimes required, to:
Extract the signing or encryption certificate to distribute to clients, if needed
Update or replace the signing or encryption key entry
Add trusted certificates
For more information, see the Oracle Fusion Middleware Installation Guide for Oracle Identity Management.
Any server hosting Oracle Access Manager with Oracle Security Token Service must be registered with Oracle Access Manager. This can occur automatically during installation, or manually after installation.
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 previously covered topics:
Look for information through out this manual. Pay close attention to Oracle Security Token Service details in Part V, "Oracle Security Token Service".
A single default LDAP group, the WebLogic Server "Administrators" group, is set by default.
During initial deployment, using the Oracle Fusion Middleware Configuration Wizard, the administrator userID and password are set. Administrators can log in and use the Oracle Access Manager Console (and WebLogic Server Administration Console).
For more information, see Chapter 3, "Getting Started with Common Administration and Navigation".
|
 Copyright © 2000, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
