6 Additional Server Configuration

6.1.1 OracleAS Single Sign-On with Liberty 1.x/SAML 2.0

OracleAS Single Sign-On can be configured to trigger a Liberty 1.x or SAML 2.0 SSO operation when requesting a resource protected by mod_osso.

To achieve this, the OracleAS Single Sign-On partner application must be defined and must be protected by mod_osso. The partner application must also be configured to use the SSO Security level associated with the SASSO Authentication plug-in. You do this by editing the ORACLE_HOME/sso/conf/policy.properties file of the Oracle SSO deployment, and setting the partner application (defined by its hostname and port) to the same security level as the SASSOAuthLevel property.

For example:

MediumHighSecurity_AuthPlugin = oracle.security.sso.server.auth.SASSOAuth
MediumSecurity_AuthPlugin = oracle.security.sso.server.auth.SSOServerAuth
...
www.app.com\:7890 = MediumHighSecurity
...
SASSOAuthnUrl = http\://oif_host\:oif_port/sso/authn
SASSOLogoutUrl = http\://oif_host\:oif_port/sso/jsp/sasso_logout_success.jsp
SASSOAuthLevel = MediumHighSecurity

Save the file and restart OC4J_SECURITY to apply the changes.

The next time a user attempts an unauthenticated access to the protected resource, the user is redirected to Oracle Identity Federation where a Liberty 1.x/SAML 2.0 SSO operation occurs.

6.1.2 Oracle Access Manager with Liberty 1.x/SAML 2.0

Oracle Access policies can be set up to initiate a Liberty 1.x/SAML 2.0 SSO when the user requests a resource protected by the Oracle Access Manager WebGate agent.

To do this, use the Oracle Access Policy Manager to set up a policy domain or policy that protects the resource. When creating the authentication rule for the policy domain or policy, select the Fed SSO – SAML 2.0/Liberty 1.x authentication scheme. Oracle Identity Federation automatically creates this authentication scheme when it is configured to use Oracle Access. The scheme initiates the Liberty 1.x or SAML 2.0 single sign-on when the resource is accessed, resulting in a session for the local user associated with the federated user. Set up the authorization rules and expression for the policy domain or policy to allow access for the resulting local user.

6.1.3 Oracle Access Manager with SAML 1.x/WS-Federation

Oracle Access Manager policies can be set up to initiate a SAML 1.x or WS-Federation SSO when a user requests a resource protected by the Oracle Access Manager WebGate agent.

To do this, use the Oracle Access Policy Manager to set up a policy domain or policy that protects the resource. When creating the authentication rule for the policy domain or policy, select the Fed SSO – SAML 1.x or Fed SSO – WS-Federation authentication scheme. Oracle Identity Federation automatically creates these authentication schemes when it is configured to use Oracle Access Manager. The schemes use SAML 1.x or WS-Federation to initiate a federated SSO when the resource is accessed, resulting in a session for the local user associated with the federated user. Set up the authorization rules and expression for the policy domain or policy to allow access for the resulting local user.

This section contains these topics:

• Using the Fed SSO - SAML 1.x Authentication Scheme

• Using the Fed SSO - WS-Federation Authentication Scheme

6.1.4 eTrust SiteMinder with Liberty 1.x/SAML 2.0

Liberty 1.x/SAML 2.0 SSO can be triggered by requesting a resource protected by eTrust SiteMinder policy.

To do this, create a policy under eTrust SiteMinder, which will protect a resource using the Form Authentication scheme. You will need to add a Form Authentication scheme through the eTrust SiteMinder Admin Console. While adding the Authentication scheme, select the scheme type as HTML Form Template, then make these changes:

1. Set Protection level to 1.

2. Under the Scheme Setup tab:

   1. Set Server name to CASiteMinderHost.domain:Port

   2. Set Target to /siteminderagent/forms/login.fcc.redirect.html

3. Under the Advance tab, set Library to smauthhtml.

After configuring the Form Authentication scheme, add the HTML file shown here under <NetegritySMInstallArea>\SMWebAgent\Samples\Forms, naming it login.fcc.redirect.html.

<html>
 <!--Redirect to OIF-->
    <body onload="setTimeout(location.href=getRedirectURL(), 1);"/>
    <script>
    //<!--

    function getRedirectURL ()
    {
        var targetParam = getQueryParam("TARGET");
        if (targetParam.indexOf("$SM$") == 0)
            targetParam = targetParam.substring
             (4, targetParam.length);
        // Redirect
        var redirectURL =
         "http://<SPHost.Domain>:<Port>/fed/sp/smredirect?providerid="
         + escape("http://<idPHost.Domain>:<Port>/fed/idp") 
         +"&targetURL=" + targetParam;

        return redirectURL;
    }

    function getQueryParam (param)
    {
        var result = "";
        var url = location.href;
        var qIndex = url.indexOf("?");
        if (qIndex > -1)
        {
            var queryString = url.substring(qIndex + 1, url.length);
            var params = queryString.split("&");
            for (var i = 0, n = params.length; i < n; ++i)
            {
                var nvPair = params[i].split("=");
                if (nvPair[0] == param)
                {
                    result = nvPair[1];
                    break;
                }
            }
        }
        return result;
    }
    //-->
    </script>
</html>

This form redirects the user to a servlet on the SP that will:

• process the targetURL query parameter

• initiate a flow that results in the user being ultimately redirected to the URL specified by this parameter once single sign-on completes

6.1.5 eTrust SiteMinder with SAML 1.x/WS-Federation

SAML 1.x/WS-Federation SSO can be triggered by requesting URLs in a specific format.

<html>
 <!--Redirect to OSFS-->
    <body onload="setTimeout(location.href=getRedirectURL(), 1);"/>
    <script>
    //<!--

    function getRedirectURL ()
    {
        var targetParam = getQueryParam("TARGET");
        if (targetParam.indexOf("$SM$") == 0)
            targetParam = targetParam.substring(4, targetParam.length);
        // Redirect
        var redirectURL =
          "http://<SPHost.Domain>:<Port>/shareid/saml/ObSAMLTransferForm?"+
         "&TARGET=" + targetParam;
        return redirectURL;
    }

    function getQueryParam (param)
    {
        var result = "";
        var url = location.href;
        var qIndex = url.indexOf("?");
        if (qIndex > -1)
        {
            var queryString = url.substring(qIndex + 1, url.length);
            var params = queryString.split("&");
            for (var i = 0, n = params.length; i < n; ++i)
            {
                var nvPair = params[i].split("=");
                if (nvPair[0] == param)
                {
                    result = nvPair[1];
                    break;
                }
            }
        }
        return result;
    }
    //-->
    </script>
</html>

6.1.6 SP-initiated SSO with Liberty 1.x/SAML 2.0

When Oracle Identity Federation server is integrated with OracleAS Single Sign-On, Oracle Access Manager or Entrust eTrust SiteMinder, a user can initiate a Liberty 1.x/SAML 2.0 SSO operation by directly requesting a service at the Oracle Identity Federation/SP instance.

The URL to be requested on the Oracle Identity Federation server is:

http(s)://Oracle Identity Federation_host:Oracle Identity Federation_port/fed/sp/initiatesso

6.1.7 SP-initiated SSO with SAML 1.x

When Oracle Identity Federation is integrated with OracleAS Single Sign-On, Oracle Access Manager, or eTrust SiteMinder, it is possible to initiate a SAML 1.x SSO operation by directly requesting a service at the Oracle Identity Federation/SP instance using the following URL:

http(s)://oif_host:oif_port/shareid/saml/ObSAMLTransferForm?TARGET=targetURL

where targetURL is the URL of the requested resource. The ObSAMLTransferForm service follows the same rules as the Fed SSO – SAML 1.x authentication scheme discussed in "Using the Fed SSO - SAML 1.x Authentication Scheme". It looks for the ObSAMLDomain cookie to specify the IdP to be used. If the ObSAMLDomain cookie is not found, a local login is performed.

For example:

http://oif_host:oif_port/shareid/saml/ObSAMLTransferForm? TARGEt=http://host:port/protected.html

6.1.8 SP-initiated SSO with WS-Federation

When Oracle Identity Federation is integrated with OracleAS Single Sign-On, Oracle Access Manager, or eTrust SiteMinder, you can initiate a WS-Federation SSO request from the SP with a URL with the format:

http(s)://oif_host:oif_port/shareid/wsfederation/ObWSFedResourceSTS?wa=wsignin1.0& wctx=targetURL

where targetURL is the URL of the requested resource. The ObWSFedResourceSTS service follows the same rules as the Fed SSO – WS-Federation authentication scheme discussed in "Using the Fed SSO - WS-Federation Authentication Scheme". If the ObSAMLDomain cookie is present, it is used to determine the IdP. If there is only one IdP configured for WS-Federation, that IdP is used. Otherwise an IdP selection page is displayed.

Here is an example URL:

http://host:port/shareid/wsfederation/ObWSFedResourceSTS? wa=wsignin1.0&wctx=http://host:port/protected.html

6.1.9 IdP-initiated SSO with Liberty 1.x/SAML 2.0

For the Liberty 1.x and SAML 2.0 protocols, Oracle Identity Federation provides the ability to initiate an SSO operation by directly requesting a URL at the Oracle Identity Federation instance acting as an IdP; this is called an SSO IdP-initiated operation.

The url to be requested on the Oracle Identity Federation server is of the form:

http(s)://oif_host:oif_port/fed/idp/initiatesso

6.1.10 IdP-initiated SSO with SAML 1.x

When Oracle Identity Federation is enabled for SSO with SAML1.x, it is possible to initiate an SSO request from the IdP. The URL for the request is of the form:

http(s)://oif_host:oif_port/shareid/saml/ObSAMLTransferService

with these parameters:

• DOMAIN is the domain name configured for the SP

• METHOD is POST or ARTIFACT

• TARGET is the target URL that is to be accessed

For example:

http://oif_host:oif_port/shareid/saml/ObSAMLTransferService?DOMAIN=SP_domain&METHOD=post&TARGET=http://host2:port/protected.html

6.1.11 IdP-initiated SSO with WS-Federation

When Oracle Identity Federation is enabled for SSO with WS-Federation, it is possible to initiate an SSO request from the IdP, using a URL in the following format:

http(s)://oif_host:oif_port/shareid/wsfederation/ObWSFedIdentitySTS

with these parameters:

• wa is wsignin1.0

• wtrealm is the request realm URI defined by the SP

• wctx is the target URL to be accessed

For example:

http://oif_host:oif_port/shareid/wsfederation/ObWSFedIdentitySTS?wa=wsignin1.0& wtrealm=http://sp_host/&wctx=http://sp_host:port/protected.html

6.6.1 What is Automatic Account Linking at the SP?

Automatic account linking at the SP allows the service provider to directly map an identity contained in an assertion to a user. With this feature:

• a new federation can be created, when none exists for the user and the peer IdP, without having to prompt the user for credentials. This is achieved in conjunction with a federation data store.

• the Oracle Identity Federation server is not required to use a federation data store to persist federation records.

  
  

  See Also: "Edit Federation Data Store".

  
  

Automatic account linking is supported for SAML 2.0 SSO operations with non-opaque name identifiers, when enabled:

• X.509

• e-mail address

• Kerberos principal name

• Windows domain qualified name

This feature is not supported for:

• Liberty 1.x SSO

• SAML 2.0 SSO operations using persistent and transient name identifiers

Make sure that federation creation is allowed when using this feature (see "Service Provider - Global Settings").

6.6.2 Configuring Automatic Account Linking at the SP

Take these steps to configure automatic account linking at the SP:

1. Configure the Service Provider to request a non-opaque SAML 2.0 Name ID:

   • Go to the Oracle Identity Federation administration console.

   • Go to Server Configuration - > Service Provider, then SAML 2.0.

   • Select the Default Authn Request NameID Format to be one of: X.509, Email Address, Kerberos Principal Name or Windows Domain Qualified Name.

     
     

     Note: You can select Unspecified - in that case, the IdP will decide the Name ID format, which must be non-opaque.

     
     

   • Click Apply.

2. Map the selected Name ID format to a user attribute that uniquely reference a user record:

   • Go to Server Configuration - > Service Provider, then SAML 2.0.

   • Click Account Linking NameID Formats.

   • Check which Name ID formats are to be enabled, and the attribute name that will contain the user information for the specified name IDs.

     
     

     Note: dn references the DN of an LDAP entry.

     
     

   • Click Apply.

3. Enable the automatic account linking feature:

   • Go to Server Configuration - > Service Provider, then SAML 2.0.

   • Check the Auto Account Linking Enabled property.

   • Click Apply, then Refresh Server.

6.7.1 What is Automatic Account Linking at the IdP?

Automatic account linking at the identity provider allows the IdP to create a federation automatically, if no federation exists and if the SP did not request that one be created. With this feature:

• a new federation can be created, when none exists for the user and the peer SP, without the SP having to request it. This is achieved in conjunction with a federation data store.

• the Oracle Identity Federation server is not required to use a federation data store to persist federation records.

  
  

  See Also: "Edit Federation Data Store"

  
  

Automatic account linking is supported for SAML 2.0 SSO operations with non-opaque name identifiers, when enabled:

• X.509

• e-mail address

• Kerberos principal name

• Windows domain qualified name

This feature is not supported for:

• Liberty 1.x SSO

• SAML 2.0 SSO operations using persistent and transient name identifiers

6.7.2 Configuring Automatic Account Linking at the IdP

Take these steps to configure the IdP for automatic account linking:

1. Specify the Name ID format mappings:

   • Go to Server Configuration - > Identity Provider, then SAML 2.0.

   • Click Assertion NameID Formats.

   • Check which Name ID formats are to be enabled, and the attribute name that will contain the user information for the specified name IDs.

     
     

     Note: dn references the DN of an LDAP entry.

     
     

   • Click Apply.

2. Optionally, configure the Default Assertion Name ID Format to use a non-opaque Name ID.

3. Enable the automatic account linking feature:

   • Go to Server Configuration - > Identity Provider, then SAML 2.0.

   • Check the Auto Account Linking Enabled property.

   • Click Apply, then Refresh Server.