Securing WebLogic Server

      

Configuring Single Sign-On with Web Browsers and HTTP Clients

The Security Assertion Markup Language (SAML) enables cross-platform authentication between Web applications or Web Services running in a WebLogic Server domain and Web browsers or other HTTP clients. WebLogic Server supports single sign-on (SSO) based on SAML. When users are authenticated at one site that participates in a single sign-on (SSO) configuration, they are automatically authenticated at other sites in the SSO configuration and do not need to log in separately.

The following sections describe how to set up single sign-on (SSO) with Web browsers or other HTTP clients by using authentication based on the Security Assertion Markup Language (SAML) versions 1.1 and 2.0.

A WebLogic Server instance that is configured for SAML 2.0 SSO is not interoperable with one that is configured for SAML 1.1

For an overview of SAML-based single sign on, see the following topics in Understanding WebLogic Security:

 

Configuring SAML 1.1 Services

This topic includes the following sections:

 

Enabling Single Sign-on with SAML 1.1: Main Steps

To enable single sign-on with SAML, configure WebLogic Server as either a source site or destination site as described in the sections that follow.

Configuring a Source Site: Main Steps

To configure a WebLogic Server instance in the role of a source site, complete the following main steps:

  1. Create and configure a SAML credential mapping provider V2 in your security realm.

  2. Configure the federation services for the server instance in the realm that will serve as a source site.

  3. Create and configure the relying parties for which SAML assertions will be produced.

  4. If you want to require relying parties to use SSL certificates to connect to the source site, add any such certificates to the SAML credential mapping provider's Certificate Registry.

Configuring a Destination Site: Main Steps

To configure a WebLogic Server instance in the role of a destination site, complete the following main steps:

  1. Create and configure a SAML identity assertion provider V2 in your security realm.

  2. Configure the federation services for the server instance realm that will serve as a destination site.

  3. Create and configure the asserting parties from which SAML assertions will be consumed.

  4. Establish trust by registering the asserting parties' SSL certificates in the certificate registry maintained by the SAML identity assertion provider.

 

Configuring a SAML 1.1 Source Site for Single Sign-On

The following topics explain how to configure a WebLogic Server instance as a SAML 1.1 source site:

Configure the SAML 1.1 credential mapping Provider

In your security realm, create a SAML credential mapping Provider V2 instance. The SAML credential mapping provider is not part of the default security realm. See Configuring a SAML credential mapping Provider for SAML 1.1.

Configure the SAML credential mapping provider as a SAML authority, using the Issuer URI, Name Qualifier, and other attributes.

Configure the Source Site Federation Services

Configure SAML source services in the Administration Console Online Help.

Configure SAML source site attributes as follows:

Configure Relying Parties

A SAML Relying Party is an entity that relies on the information in a SAML assertion produced by the SAML source site. You can configure how WebLogic Server produces SAML assertions separately for each Relying Party or use the defaults established by the Federation Services source site configuration for producing assertion.

Create a SAML Relying Party and Configure a SAML Relying Party in the Administration Console Online Help.

You can also configure a Relying Party with the WebLogic Scripting Tool. See Configuring Relying and Asserting Parties with WLST.

Configure Supported Profiles

When you configure a SAML Relying Party, you can specify support for Artifact profile or POST profile, for the purposes of SAML SSO. As an alternative configure a Relying Party to support WSS/Holder-of-Key or WSS/Sender-Vouches profiles for Web Services Security purposes. Be sure to configure support for the profiles that the SAML destination sites support.

If you support the POST profile, optionally create a form to use in POST profile assertions for the Relying Party and set the pathname of that form in the POST Form attribute.

Assertion Consumer Parameters

For each SAML Relying Party, you can configure one or more optional query parameters (such as a partner ID) that will be added to the ACS URL when redirecting to the destination site. In the case of POST profile, these parameters will be included as form variables when using the default POST form. If a custom POST form is in use, the parameters will be made available as a Map of names and values, but the form may or may not constructed to include the parameters in the POSTed data.

Replacing the Default Assertion Store

WebLogic Server uses a simple assertion store to maintain persistence for produced assertions. You can replace this assertion store with a custom assertion store class that implements weblogic.security.providers.saml.AssertionStoreV2. Configure WebLogic Server to use your custom assertion store class, rather than the default class, using the FederationServicesMBean.AssertionStoreClassName attribute. You can configure properties to be passed to the initStore() method of your custom assertion store class by using the FederationServicesMBean.AssertionStoreProperties attribute. Configure these attributes in the Administration Console on the Environment: Servers Arrow symbolServerName Arrow symbolConfiguration Arrow symbolFederation Services Arrow symbolSAML 1.1 Source Site page.

 

Configuring a SAML 1.1 Destination Site for Single Sign-On

The following topics describe how to configure WebLogic Server as a SAML destination site:

Configure SAML Identity Assertion Provider

In your security realm, create and configure a SAML Identity Assertion Provider V2 instance. The SAML identity assertion provider is not part of the default security realm. See Configuring a SAML Identity Assertion Provider for SAML 1.1.

Configure Destination Site Federation Services

Before you configure WebLogic as a SAML destination site, first create a SAML Identity Assertion Provider V2 instance in your security realm. Configuration of a WebLogic Server instance as a SAML destination site is controlled by the FederationServicesMBean. You can access the FederationServicesMBean using the WebLogic Scripting Tool or through the Administration Console, using the Environment: Servers Arrow symbolServerName Arrow symbolConfiguration Arrow symbolFederation Services Arrow symbolSAML 1.1 Destination Site page.

Configure the SAML destination site attributes as follows.

Enable the SAML Destination Site

Allow the WebLogic Server instance to serve as a SAML destination site by setting Destination Site Enabled to true.

Set Assertion Consumer URIs

Set the URIs for the SAML Assertion Consumer Service. This is the URL that receives assertions from source sites, so that the destination site can use the assertions to authenticate users. The Assertion Consumer URI is also specified in the configuration of a Relying Party.

Configure SSL for the Assertion Consumer Service

You can require all access to the Assertion Consumer Service to use SSL by setting FederationServicesMBean.acsRequiresSSL to true.

Add SSL Client Identity Certificate

The SAML destination site uses a trusted certificate with which to sign POST profile responses. Add this certificate to the keystore and enter the credentials (alias and passphrase) to be used to access the certificate.

Configure Single-Use Policy and the Used Assertion Cache or Custom Assertion Cache

Optionally, you can require that each POST profile assertion be used no more than once. WebLogic Server maintains a cache of used assertions so that it can support a single-use policy for assertions. You can replace this assertion cache with a custom assertion cache class that implements weblogic.security.providers.saml.SAMLUsedAssertionCache. Configure WebLogic Server to use your custom assertion cache class, rather than the default class, using the FederationServicesMBean.SAMLUsedAssertionCache attribute. You can configure properties to be passed to the initCache() method of your custom assertion cache class using the FederationServicesMBean.UsedAssertionCacheProperties attribute. You can configure these attributes in the Administration Console on the Environment Arrow symbolServers Arrow symbolServerName Arrow symbolConfiguration Arrow symbolFederation Services Arrow symbolSAML 1.1 Destination Site page.

Configure Recipient Check for POST Profile

Optionally, you can require that the recipient of the SAML Response must match the URL in the HTTP Request. Do this by setting the POST Recipient Check Enabled attribute.

Configuring Asserting Parties

A SAML asserting party is a trusted SAML Authority (an entity that can authoritatively assert security information in the form of SAML Assertions).Configure an asserting party in the Administration Console, using the Security Realms Arrow symbolRealmName Arrow symbolProviders Arrow symbol Credential Mapper Arrow symbolSAMLCredentialMapperName Arrow symbolManagement: Asserting Parties page. See Create a SAML asserting party and Configure a SAML asserting party in the Administration Console Online Help.

You can also configure an asserting party with the WebLogic Scripting Tool. See Configuring Relying and Asserting Parties with WLST.

Configure Supported Profiles

When you configure a SAML asserting party, you can specify support for Artifact profile or POST profile, for the purposes of SAML SSO. Alternatively, configure an asserting party to support WSS/Holder-of-Key or WSS/Sender-Vouches profiles for Web Services Security purposes.

Configure Source Site ITS Parameters

For each SAML asserting party, configure zero or more optional query parameters (such as a partner ID) that will be added to the ITS URL when redirecting to the source site.

 

Configuring Relying and Asserting Parties with WLST

SAML partners (Relying Parties and Asserting Parties) are maintained in a registry. You can configure SAML partners using the WebLogic Administration Console or using WebLogic Scripting Tool. The following example shows how you might configure two Relying Parties using WLST in online mode. Listing 7-1 Creating Relying Parties with WLST 

connect('weblogic','weblogic','t3://localhost:7001')

rlm=cmo.getSecurityConfiguration().getDefaultRealm()

cm=rlm.lookupCredentialMapper('samlv2cm')

rp=cm.newRelyingParty()

rp.setDescription('test post profile')

rp.setProfile('Browser/POST')

rp.setAssertionConsumerURL('http://domain.example.com:7001/saml_destination/acs')

rp.setAssertionConsumerParams(array(['APID=ap_00001'],String))

rp.setSignedAssertions(true)

rp.setEnabled(true)

cm.addRelyingParty(rp)

rp=cm.newRelyingParty()

rp.setDescription('test artifact profile')

rp.setProfile('Browser/Artifact')

rp.setAssertionConsumerURL('http://domain.example.com:7001/saml_destination/acs')

rp.setAssertionConsumerParams(array(['APID=ap_00002'],String))

rp.setARSUsername('foo')

rp.setARSPassword('bar')

rp.setSSLClientCertAlias('demoidentity')

rp.setEnabled(true)

cm.addRelyingParty(rp)

disconnect()

exit()

The following example shows how you might edit an existing asserting party. The example gets the asserting party, using its asserting party ID, and sets the Assertion Retrieval URL. Listing 7-2 Editing an asserting party with WLST 

connect('weblogic','weblogic','t3://localhost:7001')

rlm=cmo.getSecurityConfiguration().getDefaultRealm()

ia=rlm.lookupAuthenticationProvider('samlv2ia')

ap=ia.getAssertingParty('ap_00002')

ap.setAssertionRetrievalURL('https://hostname:7002/samlars/ars')

ia.updateAssertingParty(ap)

disconnect()

exit()

 

Configuring SAML 2.0 Services

This topic includes the following sections:

 

Configuring SAML 2.0 Services: Main Steps

A summary of the main steps you take to configure SAML 2.0 services are as follows:

  1. Determine whether you plan to have SAML 2.0 services running in more than one WebLogic Server instance in the domain. If so, do the following:

    1. Create a domain in which the RDBMS security store is configured.

      The RDBMS security store is required by the SAML 2.0 security providers so that the data they manage can be synchronized across all the WebLogic Server instances that share that data.

      Note that Oracle does not recommend upgrading an existing domain in place to use the RDBMS security store. If you want to use the RDBMS security store, you should configure the RDBMS security store at the time of domain creation. If you have an existing domain with which you want to use the RDBMS security store, create the new domain and migrate your existing security realm to it.

      For information, see Managing the RDBMS Security Store.

    2. Ensure that all SAML 2.0 services are configured identically in each WebLogic Server instance. If you are configuring SAML 2.0 services in a cluster, each Managed Server in that cluster must be configured individually.

    3. Note the considerations described in Web Application Deployment Considerations for SAML 2.0.

  2. If you are configuring a SAML 2.0 identity provider site:

    1. Create and configure an instance of the SAML 2.0 credential mapping provider in the security realm.

    2. Configure the SAML 2.0 general services identically and individually in each WebLogic Server instance in the domain that will run SAML 2.0 services.

    3. Configure the SAML 2.0 identity provider services identically and individually in each WebLogic Server instance in the domain that will run SAML 2.0 services.

    4. Publish the metadata file describing your site, and manually distribute it to your service provider partners.

    5. Create and configure your service provider partners.

  3. If you are configuring a SAML 2.0 service provider site:

    1. Create and configure an instance of the SAML 2.0 identity assertion provider in the security realm.

      Optionally, you may also need to create and configure an instance of the SAML Authentication provider.

    2. Configure the SAML 2.0 general services identically and individually in each WebLogic Server instance in the domain that will run SAML 2.0 services.

    3. Configure the SAML 2.0 service provider services identically and individually in each WebLogic Server instance in the domain that will run SAML 2.0 services.

    4. Publish the metadata file describing your site, and manually distribute it to your identity provider partners.

    5. Create and configure your identity provider partners.

The sections that follow provide details about each set of main steps.

 

Configuring SAML 2.0 General Services

Regardless of the SAML 2.0 role in which you wish to configure a WebLogic Server instance — that is, as either a service provider or identity provider — you need to configure the server's general SAML 2.0 services. Configuration of the SAML 2.0 general services for a WebLogic Server instance is controlled by the SingleSignOnServicesMBean. You can access the SingleSignOnServicesMBean with the WebLogic Scripting Tool or through the Administration Console, on the Environment Arrow symbolServers Arrow symbolServerName Arrow symbolConfiguration Arrow symbolFederation Services Arrow symbolSAML 2.0 General page.

You cannot configure SAML 2.0 general services in a WebLogic Server instance until you have first configured either the SAML 2.0 Identity Assertion or SAML 2.0 credential mapping provider and restarted the server instance.

The following sections describe SAML 2.0 general services:

About SAML 2.0 General Services

The general SAML 2.0 services you configure include the following:

For information about the steps for configuring SAML 2.0 general services, see Configure SAML 2.0 general services in the Administration Console Online Help.

Publishing and Distributing the Metadata File

The local site information that is needed by your federated partners — such as the local site contact information, entity ID, published site URL, whether TLS/SSL client authentication is required, and so on — is published to a metadata file by clicking Publish Meta Data in the SAML 2.0 General console page.

When you publish the metadata file, you specify an existing directory on the local machine in which the file can be created. The process of distributing the metadata file to your federated partners is a detail that is not implemented by WebLogic Server. However, you may send this file via a number of commonly used mechanisms suitable for securely transferring electronic documents, such as encrypted email or secure FTP.

Keep the following in mind regarding the metadata file:

Operations on the metadata file are available via the com.bea.security.saml2.providers.registry.Partner Java interface.

 

Configuring an identity provider Site for SAML 2.0 Single Sign-On

This section presents the following topics:

Configure the SAML 2.0 credential mapping Provider

In your security realm, create a SAML 2.0 credential mapping provider instance. The SAML 2.0 credential mapping provider is not part of the default security realm. See Configuring a SAML 2.0 credential mapping Provider for SAML 2.0.

Configure the SAML 2.0 credential mapping provider as a SAML authority. Attributes you specify include the following:

After you configure the SAML 2.0 credential mapping provider, configure SAML 2.0 general services, as described in Configuring SAML 2.0 General Services.

Configure SAML 2.0 identity provider Services

Configuration of a WebLogic Server instance as a SAML 2.0 identity provider site is controlled by the SingleSignOnServicesMBean. You can access the SingleSignOnServicesMBean using the WebLogic Scripting Tool (WLST), or through the Administration Console by using the Environment Arrow symbolServers Arrow symbolServerName Arrow symbolConfiguration Arrow symbolFederation Services Arrow symbolSAML 2.0 identity provider page.

The sections that follow summarize the configuration tasks. For more information about performing these tasks, see Configure SAML 2.0 identity provider services in the Administration Console Online Help.

Enable the SAML 2.0 identity provider Site

From the SAML 2.0 identity provider page in the console, allow the WebLogic Server instance to serve as an identity provider site by setting the Enabled attribute to true.

Specify a Custom Login Web Application

Optionally, you may use a custom login web application to authenticate users into the identity provider site. To configure a custom login web application, enable the Login Customized attribute and specify the URL of the web application.

Enable Binding Types

Oracle recommends enabling all the available binding types for the endpoints of the identity provider services; namely, POST, Redirect, and Artifact. Optionally you may select a preferred binding type.

Publish Your Site's Metadata File

After you have configured the SAML 2.0 general services and identity provider services, publish your site's metadata file and distribute it to your federated partners, as described in Publishing and Distributing the Metadata File.

Create and Configure Web Single Sign-On service provider Partners

A SAML 2.0 service provider partner is an entity that consumes the SAML 2.0 assertions generated by the identity provider site. The configuration of service provider partners is available from the Administration Console, using the Security Realms Arrow symbolRealmName Arrow symbolProviders Arrow symbolCredential Mapper Arrow symbolSAML2CredentialMapperName Arrow symbolManagement page.

The attributes that can be set on this console page can also be accessed programmatically via a set of Java interfaces, which are identified in the sections that follow.

See Create a SAML 2.0 Web SSO Provider partner in the Administration Console Online Help for complete details about the specific steps for configuring a service provider partner. For a summary of the site information, signing certificates, and service endpoint information available when you configure a web single sign-on partner, see Viewing Partner Site, Certificate, and Service Endpoint Information.

Obtain Your service provider Partner's Metadata File

Before you configure a service provider partner for web single sign-on, you need to obtain the partner's SAML 2.0 metadata file via a trusted and secure mechanism, such as encrypted email or an SSL-enabled FTP site. Your partner's metadata file describes the partner site and binding support, includes the partner's certificates and keys, contains your partner's SAML 2.0 service endpoints, and more. Copy the partner's metadata file into a location that can be accessed by each node in your domain configured for SAML 2.0.

The SAML 2.0 metadata file is described in Publishing and Distributing the Metadata File.

Create Partner and Enable Interactions

To create and enable a service provider partner for web single sign-on:

  1. From the Management tab of the SAML 2.0 credential mapping provider page, specify the partner's name and metadata file.

  2. From the General tab of the partner configuration page, enable interactions between the partner and the WebLogic Server instance

WebLogic Server provides the com.bea.security.saml2.providers.registry.Partner Java interface for configuring these attributes.

Configure How Assertions are Generated

Optionally from the General tab of the partner configuration page in the console, you can configure the following attributes of the SAML 2.0 assertions generated specifically for this service provider partner:

WebLogic Server provides the com.bea.security.saml2.providers.registry.SPPartner Java interface for configuring these attributes.

Configure How Documents Are Signed

You can use the General tab of the service provider partner configuration page to determine how the following documents exchanged with this partner must be signed:

The attributes for specifying whether this partner accepts only signed assertions, or whether authentication requests must be signed, are read-only: they are derived from the partner's metadata file.

Configure Artifact Binding and Transport Settings

Optionally, you also use the General tab of the service provider partner configuration page to configure the following:

Operations on these attributes are available via the com.bea.security.saml2.providers.registry.WebSSOPartner Java interface.

For added security in the exchange of documents with this partner, you can also specify a client user name and password to be used by the service provider partner when connecting to the local site's binding using Basic authentication. This attribute is available via the com.bea.security.saml2.providers.registry.BindingClientPartner Java interface.

 

Configuring a service provider Site for SAML 2.0 Single Sign-On

This section presents the following topics:

Configure the SAML 2.0 Identity Assertion Provider

In your security realm, create an instance of the SAML 2.0 identity assertion provider. The SAML 2.0 identity assertion provider is not part of the default security realm. The attributes you specify for the SAML 2.0 identity assertion provider include the following:

For more information about this security provider, see Configuring a SAML 2.0 Identity Assertion Provider for SAML 2.0.

Configure the SAML Authentication Provider

If you plan to enable virtual users, or consume attribute statements contained in assertions that you receive from your identity provider partners, you need to create and configure an instance of the SAML Authentication provider. For more information, see Configuring the SAML Authentication Provider.

Configure SAML 2.0 General Services

After configuring the SAML 2.0 identity assertion provider, and optionally the SAML Authentication provider, configure the SAML 2.0 general services, as described in Configuring SAML 2.0 General Services.

Configure SAML 2.0 service provider Services

Configuration of a WebLogic Server instance as a SAML 2.0 service provider site is controlled by the SingleSignOnServicesMBean. You can access the SingleSignOnServicesMBean using the WebLogic Scripting Tool (WLST), or through the Administration Console using the Environment Arrow symbolServers Arrow symbolServerName Arrow symbol Configuration Arrow symbolFederation Services Arrow symbolSAML 2.0 service provider page.

You configure the SAML 2.0 service provider site attributes as summarized in the sections that follow. For more information about these configuration tasks, see Configure SAML 2.0 service provider services in the Administration Console Online Help.

Enable the SAML 2.0 service provider Site

From the Federation Services: SAML 2.0 identity provider page in the console, allow the WebLogic Server instance to serve as a service provider site by setting the Enabled attribute to true.

Specify How Documents Must Be Signed

Optionally you may enable the attributes that set the following document signing requirements:

Specify How Authentication Requests Are Managed

Optionally you may enable the following attributes of the authentication request cache:

Enable Binding Types

Oracle recommends enabling all the available binding types for the endpoints of the service provider services; namely, POST, Redirect, and Artifact. Optionally you may specify a preferred binding type.

Set Default URL

Optionally, you may specify the URL to which unsolicited authentication responses are sent if they do not contain an accompanying target URL.

Create and Configure Web Single Sign-On identity provider Partners

A SAML 2.0 identity provider partner is an entity that generates SAML 2.0 assertions consumed by the service provider site. The configuration of identity provider partners is available from the Administration Console, using the Security Realms Arrow symbol RealmName Arrow symbolProviders Arrow symbolAuthentication Arrow symbolSAML2IdentityAsserterName Arrow symbolManagement page.

The attributes that can be set on this console page can also be accessed programmatically via a set of Java interfaces, which are identified in the sections that follow.

See Create a SAML 2.0 Web Single Sign-on identity provider partner in the Administration Console Online Help for complete details about the specific steps for configuring a service provider partner.

For a summary of the site information, signing certificates, and service endpoint information available when you configure a web single sign-on partner, see Viewing Partner Site, Certificate, and Service Endpoint Information.

The following sections summarize tasks for configuring an identity provider partner.

Obtain Your identity provider Partner's Metadata File

Before you configure an identity provider partner for web single sign-on, you need to obtain the partner's SAML 2.0 metadata file via a trusted and secure mechanism, such as encrypted email or an SSL-enabled FTP site. Your partner's metadata file describes that partner site and binding support, includes the partner's certificates and keys, and so on. Copy the partner's metadata file into a location that can be accessed by each node in your domain configured for SAML 2.0.

The SAML 2.0 metadata file is described in Publishing and Distributing the Metadata File.

Create Partner and Enable Interactions

To create an identity provider partner and enable interactions for web single sign-on:

WebLogic Server provides the com.bea.security.saml2.providers.registry.Partner Java interface for configuring these attributes.

Configure Authentication Requests and Assertions

Optionally, you can configure the following attributes of the authentication requests generated for, and assertions received from, this identity provider partner:

Configure Redirect URIs

You can configure a set of URIs that, if invoked by an unauthenticated user, cause the user request to be redirected to the identity provider partner where the user can be authenticated.

WebLogic Server provides the com.bea.security.saml2.providers.registry.WebSSOIdPPartner Java interface for configuring this attribute.

Configure Binding and Transport Settings

Optionally, you also use the General tab of the service provider partner configuration page to configure the following:

Operations on these attributes are available via the com.bea.security.saml2.providers.registry.WebSSOPartner Java interface.

For added security in the exchange of documents with this partner, you can also specify a client user name and password to be used by this identity provider partner when connecting to the local site's binding using Basic authentication. This attribute is available via the com.bea.security.saml2.providers.registry.BindingClientPartner Java interface.

 

Viewing Partner Site, Certificate, and Service Endpoint Information

When you configure SAML 2.0 partners, the partner configuration pages displayed by the Administration Console include tabs for viewing and configuring the following additional information about the partner:

 

Web Application Deployment Considerations for SAML 2.0

When deploying web applications for SAML-based SSO in a clustered environment, note the following considerations to prevent SAML-based single sign-on from failing:

Deployment Descriptor Recommendations

Note the following recommendations regarding the use of the following elements in deployment descriptor files:

Use of relogin-enabled with CLIENT-CERT Authentication

If a user logs in to a web application and tries to access a resource for which that user is not authorized, an HTTP FORBIDDEN (403) response is generated. This is standard web application behavior. However, for backwards compatibility with earlier releases, WebLogic Server permits web applications to use the relogin-enabled element in the weblogic.xml deployment descriptor file, so that the response to an access failure results in a request to authenticate. In certain circumstances, it can cause SAML 2.0 based web single sign-on to fail.

Normally, the SAML 2.0 Assertion Consumer Service (ACS) logs the user into the application and redirects the user request to the target web application. However, if that web application is enabled for SAML 2.0 single sign-on, is protected by CLIENT-CERT authentication, and has the relogin-enabled deployment descriptor element set to true, an infinite loop can occur in which a request to authenticate a user is issued repeatedly. This loop can occur when a user is logged in to the web application and attempts to access a resource for which the user is not permitted: instead of generating a FORBIDDEN message, a new authentication request is generated that triggers another SAML 2.0 based web single sign-on attempt.

To prevent this situation from occurring in a web application that is protected by CLIENT-CERT authentication, either remove the relogin-enabled deployment descriptor element for the web application, or set the element to false. This enables standard web application authentication behavior.

Use of Non-default Cookie Name

When the Assertion Consumer Service logs in the Subject contained in an assertion, an HTTP servlet session is created using the default cookie name JSESSIONID. After successfully processing the assertion, the ACS redirects the user's request to the target web application. If the target web application uses a cookie name other than JSESSIONID, the Subject's identity is not propagated to the target web application. As a result, the servlet container treats the user as if unauthenticated, and consequently issues an authentication request.

To avoid this situation, do not change the default cookie name when deploying web applications in a domain that are intended to be accessed by SAML 2.0 based single sign-on.

Login Application Considerations for Clustered Environments

Note the following two login limitations that are rare in clustered environments, but if they occur, they may prevent a single sign-on session from succeeding.


  Back to Top