Sun OpenSSO Enterprise 8.0 Developer's Guide

Preparing to Use Virtual Federation Proxy

Before configuring and using the VFP, you will need to make some decisions regarding security, applicable keys, and applications. This section lists what you will need to do before configuring for VFP.


Note –

Because OpenSSO Enterprise currently uses SAML v2 for its implementation of SAE, you should familiarize yourself with SAML v2 concepts by running the useCaseDemo SAML v2 sample included with OpenSSO Enterprise.


  1. Establish trust between the application(s) and the instance of OpenSSO Enterprise on the identity provider side.

    Decide the application(s) on the identity provider side that will use SAE to push identity attributes to the local instance of OpenSSO Enterprise. You will need values for the following:

    Application Name

    This is used for easy identification and can be any string. Use of the application's URL is recommended.

    CryptoType

    Can be Symmetric or Asymmetric.

    Shared Secret or Private and Public Keys

    You need the shared secret if using Symmetric, and the private and public keys if using Asymmetric.


    Tip –

    Multiple applications can share the same application name only if they also share the same shared secret or key.


  2. Establish trust between the application(s) and the instance of OpenSSO Enterprise on the service provider side.

    Decide the applications on the service provider side that will receive the identity attributes from the local instance of OpenSSO Enterprise using SAE. You will need the following:

    Application Name

    This is used for easy identification and can be any string. Use of the application's URL is recommended because the default implementation of the SAE on the service provider side uses a prefix string match from the requested application URL to determine the parameters used to secure the communication.

    CryptoType

    Can be Symmetric or Asymmetric.

    Shared Secret or Private and Public Keys

    You need the shared secret if using Symmetric, and the private and public keys if using Asymmetric. If Asymmetric is chosen, use the same keys defined when the SAML v2 service provider was configured as an OpenSSO Enterprise service provider. You can find these keys in the service provider's metadata.


    Tip –

    Multiple applications can share the same application name only if they also share the same shared secret or key.


  3. OPTIONAL: The following steps are specific to using SAML v2 and auto-federation.

    1. Decide which identity attributes you want transferred as part of the SAML v2 single sign-on interaction.

      We choose the branch and mail attributes.


      Caution – Caution –

      If any attribute needs to be supplied from a local user data store, you must first populate the data store.


    2. Decide which attribute will be used to identify the user on the service provider side.

      In this instance, we choose the branch attribute for user identification.


      Note –

      The attribute may be one transferred in the SAML v2 assertion or it can be configured statically at the service provider.


  4. Decide which URL on the service provider side will be responsible for handling logout requests from the identity provider.

    The URL will be responsible for terminating the local session state. Only one is allowed per logical service provider configured on the service provider side.