Understanding Typical Business Use Cases

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.

Use Case 1

The following figure illustrates the process flow for a secured stock quotes web service using a Kerberos security token.

Figure 11–6 Process Flow for a Stock Quote Web Service Using Kerberos Security Token

1. 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.

2. The Web Service Client gets the SAML token for the end user (Web Service Client).

3. The Web Service Client then talks to the STS2 (Token Mapping Service) .

4. 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.

5. 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:

1. STS client agent - profile name is STS1

   Security Mechanism:

   Kerberos

   STS End Point:

   of STS1 service

   STS Max End Point:

   of STS1 service

2. STS client agent - profile name is STS2

   Security Mechanism:

   STSSecurity

   STS config:

   STS1

   STS End Point:

   of STS2 service

   STS Max End Point:

   of STS2 service

3. WSC agent - profile name is StockService or WSC

   Security Mechanism:

   STSSecurity

   STS config:

   STS2

   WSP End Point:

   Default

Use Case 2

The following figure illustrates the process flow for a bank loan web service using a SAML 1 security token.

Figure 11–7 Process Flow for a Bank Loan Web Service Using SAML1 Security Token

1. WSC1 authenticates to STS1 with its X509 token.

2. WSC1 gets to SAML1 token (owner is WSC1).

3. WSC1 secures web service to WSP1 with its SAML1 token.

4. WSP1 then authenticates to STS2 with its X509 token, and sends the SAML1 token of WSC1.

5. The SAML1 token is sent on behalf of the X509 token in order to convert it to SAML2 token for WSC1.

6. 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:

1. WSC agent - profile name is LoanRequestorService for WSC1

   Security Mechanism:

   STSSecurity

   STS config:

   SecurityTokenService

2. WSP agent - profile name is wsp for WSP1

   WSP End Point:

   Default

   Authentication Chain:

   ldapService

   Token Conversion Type:

   SAML2 token

3. WSC agent - profile name is LoanProcessorService for WSC2

   Use Pass Through Security Token

   Enabled

Use Case 3

The following figure illustrates the process flow for a bank loan web service using a X509 security token.

Figure 11–8 Process Flow for a Bank Loan Web Service Using an X509 Security Token

1. WSC1 authenticates to STS1 with its X509 token.

2. WSC1 gets the SAML1 token (owner is WSC1).

3. WSC1 secures web service to WSP1 with its SAML1 token.

4. WSP1/WSC2 passes through just this SAML1 token of WSC1 to WSP2.

   Secures web service to WSP2 with SAML1 token of WSC1.

5. 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.

6. STS2 sends back to WSP2 the converted SAML token for WSC1.

The following are suggested configurations:

1. Web Service Client agent - profile name is LoanRequestorService for WSC1

   Security Mechanism:

   STSSecurity

   STS Configuration:

   SecurityTokenService

2. Web Service Provider agent - profile name is wsp for WSP2

   Web Service Provider End Point:

   Default

   Authentication Chain:

   ldapService

   Token Conversion Type:

   SAML2 token

3. WSC agent - profile name is LoanProcessorService for WSC2

   Use Pass Through Security Token:

   Enabled