41.7 Deploying Security Token Service
The following topics describe the deployment options in detail:
41.7.1 About the Centralized Token Authority Deployment
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 this is an intranet portal integration with an external Web service provided by a partner or another organization within the same company. The portal needs a way to securely access the service but the difficulty of security integration in this case stems from the fact that the 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 standard and proprietary tokens and, in most cases, local translation of token is required to achieve integration between the two tiers. Additionally, the WS performing the translation must contact the authority by which the token was issued (Oracle Adaptive Access Manager) to decompose the token before it can be translated. Decomposition 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.
Figure 41-3 shows the translation of tokens can be done at the centralized authority with the introduction of Security Token Service.
Figure 41-3 Token Translation at a Centralized Authority
Description of "Figure 41-3 Token Translation at a Centralized Authority"
41.7.2 About Tokens Behind a Firewall Deployment
The Security Token Service provides the administrator with a control over the token translation process by performing it behind the firewall.
The situation when applications rely on special form of credentials for their business logic is common in deployments of Oracle access products. Integrations of WAC systems with both Oracle and custom applications almost always require extensive coding for:
-
Decomposing tokens issued by one token authority (such as OAM or SiteMinder) by calling a proprietary vendor API (SM agent API or ASDK).
-
Composing a new token format (PSFT, Siebel), that the application requires for its internal business logic.
Although such translations are often handled through application coding, it introduces the risk of exposing user names and passwords when the code is deployed on multiple application instances in the DMZ. Thus, Security Administrators need an ability to control the translation process by externalizing it from the application. Introducing the Security Token Service provides significant relief in this situation.
Figure 41-4 shows the Security Token Service plays the role of a centralized token authority by performing token translation behind the firewall.
Figure 41-4 Translating Tokens Behind a Firewall
Description of "Figure 41-4 Translating Tokens Behind a Firewall"
Application 1 and Application 2 are protected by Access Manager. Application 2 relies on a different type of token for its internal business logic. It has a client-side connector that contacts Security Token Service for exchanging the OBSSO token for a username token. The Security Token Service relies on Access Manager for decomposing the OBSSO token and generates the new token required by Application 2. This is more secure, because the same authority (Access Manager) performs both operations (composing and decomposing the OBSSO token) thus, there is no need to decompose the token on the application side.
41.7.3 About Web Services SSO Deployment
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 SSO environment, the Security Administrator benefits.
With Web services SSO different Web services have different token requirements (that change often). Externalizing the exchange to Security Token Service enables the application to simply supply the target and the current token in its possession. Security Token Service takes charge of determining the token type for each requested service. When one or more Web services change their authentication requirements, 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 41-5 illustrates Web services SSO.
