The following are the types of users involved in transactions using Web Services Security and Secure Token Service:
Developers
Developers are typically application owners who use the OpenSSO Enterprise Client SDK APIs to communicate with a local security token service instance, or with web service security providers, to secure the applications making web services calls.
System administrators
Administrators are responsible for the configuring the OpenSSO Enterprise secure token service.
End users
End users such as company employees are exposed to OpenSSO Enterprise when they access the published web services.
The following figure illustrates the process flow for a secured stock quotes web service using a Kerberos security token.
The Web Service Client authenticates to STS1 instance with the end user's Kerberos token .
The end user logs in to the Desktop at the Web Service Client. This can be viewed as a Kerberos token for the Web Service Client, too.
The Web Service Client gets the SAML token for the end user (Web Service Client).
The Web Service Client then talks to the STS2 (Token Mapping Service) .
The Web Service Client converts the end user's (Web Service Client) SAML token to a functional SAML token.
This is called an organizational SAML token, and used as an authentication token of the Web Service Client to STS2. Here the functional SAML token has the same identity or owner as the original SAML token, but with more attributes and privileges.
The Web Service Client then secures the web services request to the Web Service Provider with the functional SAML token.
The following are configuration suggestions for this use case:
STS client agent - profile name is STS1
Kerberos
of STS1 service
of STS1 service
STS client agent - profile name is STS2
STSSecurity
STS1
of STS2 service
of STS2 service
WSC agent - profile name is StockService or WSC
STSSecurity
STS2
Default
The following figure illustrates the process flow for a bank loan web service using a SAML 1 security token.
WSC1 authenticates to STS1 with its X509 token.
WSC1 gets to SAML1 token (owner is WSC1).
WSC1 secures web service to WSP1 with its SAML1 token.
WSP1 then authenticates to STS2 with its X509 token, and sends the SAML1 token of WSC1.
The SAML1 token is sent on behalf of the X509 token in order to convert it to SAML2 token for WSC1.
WSC2 just passes through this SAML2 token of WSC1 to WSP2.
WSC2 secures the web service to WSP2 with the SAML2 token of WSC1.
The following are configuration suggestions for the Bank Loan use case:
WSC agent - profile name is LoanRequestorService for WSC1
STSSecurity
SecurityTokenService
WSP agent - profile name is wsp for WSP1
Default
ldapService
SAML2 token
WSC agent - profile name is LoanProcessorService for WSC2
Enabled
The following figure illustrates the process flow for a bank loan web service using a X509 security token.
WSC1 authenticates to STS1 with its X509 token.
WSC1 gets the SAML1 token (owner is WSC1).
WSC1 secures web service to WSP1 with its SAML1 token.
WSP1/WSC2 passes through just this SAML1 token of WSC1 to WSP2.
Secures web service to WSP2 with SAML1 token of WSC1.
WSP2 then authenticates to STS2 with its X509 token.
Sends SAML1 token of WSC1 as On Behalf Of token in order to convert it to SAML2 token for WSC1.
STS2 sends back to WSP2 the converted SAML token for WSC1.
The following are suggested configurations:
Web Service Client agent - profile name is LoanRequestorService for WSC1
STSSecurity
SecurityTokenService
Web Service Provider agent - profile name is wsp for WSP2
Default
ldapService
SAML2 token
WSC agent - profile name is LoanProcessorService for WSC2
Enabled