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.
Note:
A WebLogic Server instance that is configured for SAML 2.0 SSO cannot sent a request to a server instance configured for SAML 1.1, and vice-versa.For an overview of SAML-based single sign on, see the following topics in Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server:
This topic includes the following sections:
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.
To configure a WebLogic Server instance in the role of a source site, complete the following main steps:
Create and configure a SAML Credential Mapping provider V2 in your security realm.
Configure the federation services for the server instance in the realm that will serve as a source site.
Create and configure the relying parties for which SAML assertions will be produced.
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.
To configure a WebLogic Server instance in the role of a destination site, complete the following main steps:
Create and configure a SAML Identity Assertion provider V2 in your security realm.
Configure the federation services for the server instance realm that will serve as a destination site.
Create and configure the asserting parties from which SAML assertions will be consumed.
Establish trust by registering the asserting parties' SSL certificates in the certificate registry maintained by the SAML Identity Assertion provider.
The following topics explain how to configure a WebLogic Server instance as a SAML 1.1 source site:
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.
Configuration of a WebLogic Server instance as a SAML 1.1 source site is controlled by the FederationServicesMBean. Access the FederationServicesMBean with the WebLogic Scripting Tool or through the Administration Console, on the Environment > Servers > ServerName > Configuration > Federation Services > SAML 1.1 Source Site page. See "Configure SAML 1.1 source services" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.
Configure SAML source site attributes as follows:
Enable the SAML Source Site. Allow the WebLogic server instance to serve as a SAML source site by setting Source Site Enabled to true.
Set Source Site URL and Service URIs. Set the URL for the SAML source site. This is the URL that hosts the Intersite Transfer Service and Assertion Retrieval Service. The source site URL is encoded as a source ID in hex and Base64. When you configure a SAML Asserting Party for Browser/Artifact profile, you specify the encoded source ID.
Also specify the URIs for the Intersite Transfer Service and (to support Browser/Artifact profile) the Assertion Retrieval Service. These URIs are also specified in the configuration of an Asserting Party.
Add signing certificate. The SAML source site requires a trusted certificate with which to sign assertions. Add this certificate to the keystore and enter the credentials (alias and passphrase) to be used to access the certificate. The server's SSL identity key/certificates will be used by default if a signing alias and passphrase are not supplied.
Configure SSL for the Assertion Retrieval Service. You can require all access to the Assertion Retrieval Service to use SSL by setting FederationServicesMBean.arsRequiresSSL to true. You can require two-way SSL authentication for the Assertion Retrieval Service by setting both arsRequiresSSL and ARSRequiresTwoWaySSL to true.
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.
You configure a Relying Party in the Administration Console, on the Security Realms > RealmName > Providers > Credential Mapper > SAMLCredentialMapperName > Management > Relying Parties page. See "Create a SAML 1.1 Relying Party" and "Configure a SAML 1.1 Relying Party" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.
You can also configure a Relying Party with the WebLogic Scripting Tool. See Configuring Relying and Asserting Parties with WLST.
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.
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.
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 > ServerName > Configuration > Federation Services > SAML 1.1 Source Site page.
The following topics describe how to configure WebLogic Server as a SAML destination site:
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.
Before you configure WebLogic as a SAML destination site, you must 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 > ServerName > Configuration > Federation Services > SAML 1.1 Destination Site page.
Configure the SAML destination site attributes as follows.
Allow the WebLogic Server instance to serve as a SAML destination site by setting Destination Site Enabled to true.
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.
You can require all access to the Assertion Consumer Service to use SSL by setting FederationServicesMBean.acsRequiresSSL to true.
The SSL client identity is used to contact the ARS at the source site for Artifact profile. Add this certificate to the keystore and enter the credentials (alias and passphrase) to be used to access the certificate.
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 > Servers > ServerName > Configuration > Federation Services > SAML 1.1 Destination Site page.
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 > RealmName > Providers > Credential Mapper > SAMLCredentialMapperName > Management: Asserting Parties page. See "Create a SAML 1.1 Asserting Party" and "Configure a SAML 1.1 Asserting Party" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.
You can also configure an Asserting Party with the WebLogic Scripting Tool. See Configuring Relying and Asserting Parties with WLST.
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.
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.
Example 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.
Example 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()
If you use the SAML 1.1 Credential Mapping Provider Version 2 to configure a source site, but configure a third-party SAML Relying Party that is implemented on a non-WebLogic Server platform, the SAML assertions generated by WebLogic Server might not support all of the attributes required by the configured third-party SAML Relying Party. In this case the Relying Party might be unable to work with the Asserting Party because certain expected attributes of the assertion are not available.
You can create a custom SAML name mapper that maps Subjects to the specific SAML 1.1 assertion attributes required by your third-party SAML Relying Party by implementing the SAMLCredentialAttributeMapper interface, which is provided by WebLogic Server. Details about the SAMLCredentialAttributeMapper are available in the Oracle Fusion Middleware Oracle WebLogic Server API Reference.
The following sections explain how to create a custom SAML name mapper:
Do You Need Multiple SAMLCredentialAttributeMapper Implementations?
Make the Custom SAMLCredentialAttributeMapper Class Available in the Console
To create a custom implementation of the SAMLCredentialAttributeMapper interface, you must do the following:
Use the following classes to describe the attribute data for an assertion:
Implement the SAMLCredentialNameMapper interface. The SAMLCredentialAttributeMapper and SAMLCredentialNameMapper interfaces must both be in the same implementation.
Implementing the SAMLCredentialNameMapper interface allows you to use the WebLogic Server Administration Console to set the NameMapperClassName attribute to the class name of this SAMLCredentialAttributeMapper instance.
You configure the custom SAML name mapper in the active security realm, using the User Name Mapper Class Name attribute of the SAML Credential Mapping Provider Version 2.
Use two methods added to the SAMLNameMapperInfo class to get and set the authentication method attribute to be written to the SAML assertion.
The default name mapper class name you configure for a SAML Credential Mapping Provider Version 2, as described in Make the Custom SAMLCredentialAttributeMapper Class Available in the Console, is used as the default for that provider. However, you can optionally set a name mapper class name specific to any or all of the Relying Parties configured for the SAML Credential Mapping Provider Version 2. Setting the name mapper class name in this manner overrides the default value. If the configured SAML Relying Parties require different attributes, you can create multiple SAMLCredentialAttributeMapper implementations.
This section describes the new classes, interfaces, and methods that you must use when creating your custom SAML name mapper implementation. See Example Custom SAMLCredentialAttributeMapper Class, for example code.
Example 7-3 shows the methods and arguments in the SAMLAttributeStatementInfo class. Embedded comments provide additional information and context.
Example 7-3 Listing of SAMLAttributeStatementInfo Class
/**
* A class that represents the attributes of an AttributeStatement
* in a SAML Assertion
*/
class SAMLAttributeStatementInfo {
/**
* Constructs a SAMLAttributeStatementInfo with
* no attributes. The SAMLAttributeStatementInfo
* represents a empty SAMLAttributeStatement. It is
* expected that SAMLAttributeInfo elements will be
* added to this instance.
*
Public SAMLAttributeStatementInfo();
/**
* Constructs a SAMLAttributeStatementInfo containing multiple
* SAMLAttributeInfo elements. The SAMLAttributeStatementInfo
* represents a SAML AttributeStatement with multiple Attributes.
*
*
* @param data SAMLAttributeInfo
*/
public SAMLAttributeStatementInfo(Collection data);
/**
* returns a Collection of SAMLAttributeInfo elements. The
* collection represents the Attributes contained by
* a single AttributeStatement of a SAML Assertion
*
* The returned Collection is immutable and may be empty.
*
* @return Collection
*/
public Collection getAttributeInfo();
/**
* adds a Collection of SAMLAttributeInfo instances to
* this SAMLAttributeStatementInfo instance, to the
* end of the existing list, in the order that the
* param Collection iterates through the Collection.
*
* See SAMLAttributeInfo(String, String, Collection)
* for information on parameter handling.
*
* @param data
*
*/
public void setAttributeInfo(Collection data);
/**
* Adds a single SAMLAttributeInfo instance to this
* SAMLAttributeStatementInfo instance, at the end of
* the existing list.
*
* See SAMLAttributeInfo(String, String, Collection)
* for information on parameter handling.
*
* @param info
*/
public void addAttributeInfo(SAMLAttributeInfo info);
Example 7-4 shows the methods and arguments in the SAMLAttributeInfo class. Embedded comments provide additional information and context.
Example 7-4 Listing of SAMLAttributeInfo Class
/**
* A class that represents a single Attribute of a SAML Assertion
* AttributeStatement.
*/
class SAMLAttributeInfo {
/**
* Constructs a SAMLAttributeInfo instance with all null fields
*/
public SAMLAttributeInfo();
/**
* Constructs a SAMLAttributeInfo instance representing the SAML 1.1
* Attribute fields
*
* null elements of the Collection are ignored.
* Elements with null 'name' or 'namespace' fields
* are ignored; the resulting SAMLAttributeInfo will not
* be included in a created SAMLAssertion. Null
* attribute values are added as the empty string (ie, “”).
* @param name String
* @param namespace String
* @param values Collection of String values
*/
public SAMLAttributeInfo(String name, String namespace, Collection values;
/**
* Constructs a SAMLAttributeInfo instance representing the attribute fields
* See SAMLAttributeInfo(String, String, Collection) for
* information on parameter handling.
*
* @param name String
* @param namespace String
* @param value String
*/
public SAMLAttributeInfo(String name, String namespace, String value);
/**
* sets the name and namespace of this attribute
* See SAMLAttributeInfo(String, String, Collection) for
* information on parameter handling.
*
* @param name String, cannot be null
* @param namespace String, cannot be null
*/
public void setAttributeName(String name, String namespace);
/**
* returns the name of this attribute.
* @return String
*/
public String getAttributeName();
/**
* returns a String representing this attribute's namespace
* @return String
*/
public String getAttributeNamespace();
/**
* sets a Collection of Strings representing this attribute's values
* an empty collection adds no values to this instance, collection elements
* that are null are added as empty strings.
*
* @param values Collection
*/
public void setAttributeValues(Collection values);
/**
* adds a single String value to the end
* of this instance's Collection of elements
* See SAMLAttributeInfo(String, String, Collection) for
* information on parameter handling.
*
* @param value String
*/
public void addAttributeValue(String value);
/**
* returns a Collection of Strings representing this
* attribute's values, in the order they were added.
* If this attribute has no values, the returned
* value is null.
*
* @return Collection
*/
public Collection getAttributeValues();
}
The SAML Credential Mapping Provider Version 2 determines if the custom SAML name mapper is an implementation of the attribute mapping interface and, if so, calls the methods of the attribute mapping interface to obtain values from the Subject to write to the generated SAML assertion. If the implementation does not support the attribute mapping interface, attribute mapping is silently skipped.
The SAML Credential Mapping Provider Version 2 does not validate the attribute names or values obtained from the custom attribute mapper. Attribute names and values are treated as follows:
Any attribute with a non-null attribute name and namespace is written to the SAML assertion.
An attribute with a null attribute name or namespace is ignored, and subsequent attributes of the same Collection are processed normally.
Any attribute with a null value is written to the SAMLAttributeInfo instances with a value of "". The resulting SAML assertion is written as the string <AttributeValue></AttributeValue>.
Example 7-5 Listing of SAMLCredentialAttributeMapper Interface
/**
* Interface used to perform mapping of Subject to SAMLAssertions
* attributes.
* <p>
* To specify an instance of this interface to be used by the SAML
* Credential Mapper, set the <tt>NameMapperClassName</tt> attribute.
* <p>
* Classes implementing this interface must have a public no-arg
* constructor and must be in the system classpath.
*
* @author Copyright (c) 2008 by BEA Systems, Inc. All Rights Reserved.
*/
public interface SAMLCredentialAttributeMapper
{
/**
* Maps a <code>Subject</code> to a set of values used to construct a
* <code>SAMLAttributeStatementInfo</code> element for a SAML assertion.
* The returned <code>Collection</code> contains
* SAMLAttributeStatementInfo elements, each element
* of which will be used to
* construct a SAML <code>AttributeStatement</code> element for the SAML
* assertion.
*
* @param subject The <code>Subject</code> that should be mapped.
* @param handler The <code>ContextHandler</code> passed to the SAML
* Credential Mapper.
*
* @return A <code>Collection</code> of SAMLAttributeStatementInfo
* instances,or <code>null</code> if no mapping is made.
*/
public Collection mapAttributes(Subject subject, ContextHandler handler);
The SAMLCredentialNameMapper calls new methods on the SAMLNameMapperInfo class to get and set the authentication method attribute to be written to the SAML Assertion.
The new methods are shown in Example 7-6. Embedded comments provide additional information and context.
Example 7-6 Listing of SAMLNameMapperInfo Class
public class SAMLNameMapperInfo
{
[ existing definition ]
/**
* Called by the SAML Credential Name Mapper implementation to set
* the authentication method attribute to be written to the SAML Assertion.
* See SAML 1.1 Assertions and Protocols, Section 7.1 for possible
* values returned.
*
* @param value the Authentication Method
*/
public void setAuthenticationMethod(String value);
/**
* Called by the SAML Credential Mapper to retrive the authentication
* method attribute to be written to the SAML Assertion. See SAML 1.1
* Assertions and Protocols, Section 7.1 for possible values returned.
*
* @return the Authentication Method
*/
public String getAuthenticationMethod();
Example 7-7 shows an example implementation of the SAMLCredentialNameMapper and SAMLCredentialAttributeMapper interfaces.
While the SAMLCredentialNameMapper example implementation maps user and group information stored in the Subject, the SAMLCredentialAttributeMapper example implementation maps attribute information stored in the ContextHandler.
This example does not show how the attributes are placed in the ContextHandler.
Note that you could implement the SAMLCredentialAttributeMapper to map information stored in the Subject rather than the ContextHandler.
Embedded comments provide additional information and context.
Example 7-7 Listing of Example Custom SAMLCredentialAttributeMapper Class
import java.util.ArrayList;
import java.util.Collection;
import java.util.Set;
import javax.security.auth.Subject;
import weblogic.security.providers.saml.SAMLAttributeStatementInfo;
import weblogic.security.providers.saml.SAMLAttributeInfo;
import weblogic.security.providers.saml.SAMLCredentialNameMapper;
import weblogic.security.providers.saml.SAMLCredentialAttributeMapper;
import weblogic.security.providers.saml.SAMLNameMapperInfo;
import weblogic.security.service.ContextHandler;
import weblogic.security.service.ContextElement;
import weblogic.security.spi.WLSGroup;
import weblogic.security.spi.WLSUser;
/**
* @exclude
*
* The <code>CustomSAMLAttributeMapperImpl</code> class implements
* name and attribute mapping for the SAML Credential Mapper.
*
* @author Copyright (c) 2004 by BEA Systems, Inc. All Rights Reserved.
*/
public class CustomSAMLAttributeMapperImpl implements
SAMLCredentialNameMapper,SAMLCredentialAttributeMapper
{
/**
* Your logging code here
*/
private final static String defaultAuthMethod =
"urn:oasis:names:tc:SAML:1.0:am:unspecified";
private final static String SAML_CONTEXT_ATTRIBUTE_NAME =
"com.bea.contextelement.saml.context.attribute.name";
private String nameQualifier = null;
private String authMethod = defaultAuthMethod;
public CustomSAMLAttributeMapperImpl()
{
// make constructor public
}
/**
* Set the name qualifier value
*/
public synchronized void setNameQualifier(String nameQualifier) {
this.nameQualifier = nameQualifier;
}
/**
* Map a <code>Subject</code> and return mapped user and group
* info as a <code>SAMLNameMapperInfo</code> object.
*/
public SAMLNameMapperInfo mapSubject(Subject subject, ContextHandler handler) {
// Provider checks for null Subject...
Set subjects = subject.getPrincipals(WLSUser.class);
Set groups = subject.getPrincipals(WLSGroup.class);
String userName = null;
if (subjects == null || subjects.size() == 0) {
yourlogcode("mapSubject: No valid WLSUser principals
found in Subject, returning null");
return null;
}
if (groups == null || groups.size() == 0) {
yourlogcode("mapSubject: No valid WLSGroup pricipals
found in Subject, continuing");
}
if (subjects.size() != 1) {
yourlogcode("mapSubject: More than one WLSUser
principal found in Subject, taking first user only");
}
userName = ((WLSUser)subjects.iterator().next()).getName();
if (userName == null || userName.equals("")) {
yourlogcode("mapSubject: Username string is null or
empty, returning null");
return null;
}
// Return mapping information...
yourlogcode("mapSubject: Mapped subject: qualifier: " +
nameQualifier + ", name: " + userName + ", groups: " + groups);
return new SAMLNameMapperInfo(nameQualifier, userName,
groups);
}
/**
* Map a <code>String</code> subject name and return mapped user and group
* info as a <code>SAMLNameMapperInfo</code> object.
*/
public SAMLNameMapperInfo mapName(String name, ContextHandler handler) {
yourlogcode("mapName: Mapped name: qualifier: " +
nameQualifier + ", name: " + name);
return new SAMLNameMapperInfo(nameQualifier, name, null);
}
/**
* Returns the SAML AttributeName for group information.
*
* @return The AttributeName.
*/
public String getGroupAttrName() {
return SAMLNameMapperInfo.BEA_GROUP_ATTR_NAME;
}
/**
* Returns the SAML AttributeNamespace for group information.
*
* @return The AttributeNamespace.
*/
public String getGroupAttrNamespace() {
return SAMLNameMapperInfo.BEA_GROUP_ATTR_NAMESPACE;
}
/**
* set the auth method.
* @param method String
*/
public void setAuthenticationMethod(String method)
{
if (method != null)
authMethod = method;
}
/**
* get the auth method
* @return method String
*/
public String getAuthenticationMethod()
{
return authMethod;
}
/**
* maps a Subject/Context to a Collection of SAMLAttributeStatementInfo
* instances.
*
* @return <code>Collection</code>
*/
public Collection mapAttributes(Subject subject, ContextHandler handler)
{
yourlogcode("mapAttributes: Subject: "+subject.toString()+",
ContextHandler: "+handler.toString());
Object element = handler.getValue(SAML_CONTEXT_ATTRIBUTE_NAME);
yourlogcode("mapAttributes: got element from ContextHandler");
yourlogcode("mapAttributes: element is a:"+element.getClass().getName());
TestAttribute[] tas = (TestAttribute[])element;
/*
* loop through all test attributes and write a SAMLAttributeStatementInfo
* for each one.
*/
ArrayList statementList = new ArrayList();
for (int k = 0; k < tas.length; k++)
{
ArrayList al = null;
String[] values = tas[k].getValues();
if (values != null)
{
al = new ArrayList();
for (int i = 0; i < values.length; i++)
if (values[i] != null)
al.add(values[i]);
else al.add("");
}
SAMLAttributeInfo ai = new SAMLAttributeInfo(tas[k].getName(),
tas[k].getNamespace(), al);
SAMLAttributeStatementInfo asi = new
SAMLAttributeStatementInfo();
asi.addAttributeInfo(ai);
statementList.add(asi);
}
return statementList;
}
}
To have the SAML Credential Mapping Provider Version 2 use this SAMLCredentialAttributeMapper instance, you use the WebLogic Server Administration Console to set the existing NameMapperClassName attribute to the class name of this SAMLCredentialAttributeMapper instance.
That is, you use the Console control for the name mapper class name attribute to specify the class name of the SAMLCredentialAttributeMapper in the active security realm.
You can configure the user name mapper class name attribute in one of the following ways:
Once for the SAML Credential Mapping Provider Version 2
Individually for one or more Relying Parties
Both for the SAML Credential Mapping Provider Version 2, and individually for Relying Parties.
To use a custom user name mapper with the WebLogic SAML Credential Mapping Provider Version 2:
If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.
On the Security Realms page, select the name of the realm you are configuring (for example, TestRealm).
Expand Providers > Credential Mapping and select the name of the SAML Credential Mapping Provider Version 2.
Select the Provider Specific tab.
In the Default Name Mapper Class Name field, enter the class name of your SAMLCredentialAttributeMapper implementation.
The class name must be in the CLASSPATH.
Click Save.
In the Change Center, click Activate Changes.
To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
Not all changes take effect immediately; some require a restart.
When you configure a SAML Relying Party, you can optionally set a name mapper class specific to that Relying Party, which will override the default value you set here for the default name mapper class name.
For details about how to set a name mapper class name in the Administration Console, see "Configure a custom user name mapper" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.
This topic includes the following sections:
Configuring an Identity Provider Site for SAML 2.0 Single Sign-On
Configuring a Service Provider Site for SAML 2.0 Single Sign-On
A summary of the main steps you take to configure SAML 2.0 services are as follows:
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:
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 Chapter 10, "Managing the RDBMS Security Store."
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.
Note the considerations described in Web Application Deployment Considerations for SAML 2.0.
If you are configuring a SAML 2.0 Identity Provider site:
Create and configure an instance of the SAML 2.0 Credential Mapping provider in the security realm.
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.
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.
Publish the metadata file describing your site, and manually distribute it to your Service Provider partners.
Create and configure your Service Provider partners.
If you are configuring a SAML 2.0 Service Provider site:
Create and configure an instance of the SAML 2.0 Identity Assertion provider in the security realm.
If you are allowing virtual users to log in via SAML, you need to create and configure an instance of the SAML Authentication provider. For information, see Configuring the SAML Authentication Provider.
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.
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.
Publish the metadata file describing your site, and manually distribute it to your Identity Provider partners.
Create and configure your Identity Provider partners.
The sections that follow provide details about each set of main steps.
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 > Servers > ServerName > Configuration > Federation Services > SAML 2.0 General page.
Note:
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:
The general SAML 2.0 services you configure include the following:
Whether you wish to enable the replicated cache
Enabling the replicated cache is required if you are configuring SAML 2.0 services on two or more WebLogic Server instances in a domain, such as in a cluster. The replicated cache enables server instances to share and be synchronized with the data that is managed by the SAML 2.0 security providers; that is, either or both the SAML 2.0 Identity Assertion provider and the SAML 2.0 Credential Mapping provider.
Note that the RDBMS security store is strongly recommended if you enable the replicated cache. Therefore prior to configuring SAML 2.0 services, the preferred approach is first to create a domain that is configured to use the RDBMS security store. For more information, see Chapter 10, "Managing the RDBMS Security Store."
Information about the local site
The site information you enter is primarily for the benefit of the business partners in the SAML federation with whom you share it. Site information includes details about the local contact person who is your partners' point of contact, your organization name, and your organization's URL.
Published site URL
This URL specifies the base URL that is used to construct endpoint URLs for the various SAML 2.0 services. The published site URL should specify the host name and port at which the server is visible externally, which might not be the same at which the server is accessed locally. For example, if SAML 2.0 services are configured in a cluster, the host name and port may correspond to the load balancer or proxy server that distributes client requests to the Managed Servers in that cluster.
The published site URL should be appended with /saml2. For example:
https://www.avitek.com:7001/avitek-domain/aviserver/saml2
Entity ID
The entity ID is a human-readable string that uniquely distinguishes your site from the other partner sites in your federation. When your partners need to generate or consume an assertion, the SAML 2.0 services use the entity ID as part of the process of identifying the partner that corresponds with that assertion.
Whether recipient check is enabled
If enabled, the recipient of the authentication request or response must match the URL in the HTTP Request.
Whether TLS/SSL client authentication is required for invocations on the Artifact Resolution Service. If enabled, SAML artifacts are encrypted when transmitted to partners.
Transport Layer Security keystore alias and passphrase, the values used for securing outgoing communications with partners.
Whether Basic authentication client authentication is required when your partners invoke the HTTPS bindings of the local site.
If you enable this setting, you also specify the client username and password to be used. These credentials are then included in the published metadata file that you share with your federated partners.
Whether requests for SAML artifacts received from your partners must be signed.
Configuration settings for the SAML artifact cache.
Keystore alias and passphrase for the key to be used when signing documents sent to your federated partners, such as authentication requests or responses.
For information about the steps for configuring SAML 2.0 general services, see "Configure SAML 2.0 general services" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.
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:
Before you publish the metadata file, you should configure the Identity Provider and/or Service Provider services for the SAML 2.0 roles in which the WebLogic Server instances in your domain are enabled to function.
The configuration data for the SAML 2.0 services your site offers that is needed by your federated partners is included in this metadata file, greatly simplifying the tasks your partners perform to import your signing certificates, identify your site's SAML 2.0 service endpoints, and use the correct binding types for connecting to your site's services, and so on.
You should have only a single version of the metadata file that you share with your federated partners, even if your site functions in the role of Service Provider with some partners and Identity Provider with others. By having only a single version of the metadata file, you reduce the likelihood that your configuration settings might become incompatible with those of a partner.
If you change the local site's SAML 2.0 configuration, you should update your metadata file. Because the metadata file is shared with your partners, it will be convenient to minimize the frequency with which you update your SAML 2.0 configuration so that your partners can minimize the need to make concomitant updates to their own partner registries.
When you receive a metadata file from a federated partner, place it in a location that can be accessed by all the nodes in your domain in which SAML 2.0 services are configured. At the time you create a partner, you bring the contents the partner's metadata file into the partner registry.
Operations on the metadata file are available via the com.bea.security.saml2.providers.registry.Partner Java interface.
This section presents the following topics:
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:
Issuer URI
Name Qualifier
Life span attributes for generated SAML 2.0 assertions
Name mapper class name
Whether generated assertions should include attribute information, which specify the groups to which the identity contained in the assertion belongs
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.
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 > Servers > ServerName > Configuration > Federation Services > SAML 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 Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.
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.
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.
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.
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.
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 > RealmName > Providers > Credential Mapper > SAML2CredentialMapperName > Management 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 Service Provider partner" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console 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.
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.
To create and enable a Service Provider partner for web single sign-on:
From the Management tab of the SAML 2.0 Credential Mapping provider page, specify the partner's name and metadata file.
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.
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:
The Service Provider Name Mapper Class name
This is the Java class that overrides the default username mapper class with which the SAML 2.0 Credential Mapping provider is configured in this security realm.
Time to Live attributes
The Time to Live attributes specify the interval of time during which the assertions generated for this partner are valid. These attributes prevent expired assertions from being used.
Whether to generate attribute information that is included in assertions
If enabled, the SAML 2.0 Credential Mapping provider adds, as attributes in the assertion, the groups to which the corresponding user belongs.
Whether the assertions sent to this partner must be disposed of immediately after use
Whether this server's signing certificate is included in assertions generated for this partner
WebLogic Server provides the com.bea.security.saml2.providers.registry.SPPartner Java interface for configuring these attributes.
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:
Assertions
Operations on this attribute are available in the com.bea.security.saml2.providers.registry.SPPartner interface.
Authentication requests
Operations on this attribute are available in the com.bea.security.saml2.providers.registry.WebSSOSPPartner interface.
Artifact requests
Operations on this attribute are available in the com.bea.security.saml2.providers.registry.WebSSOPartner interface.
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.
Optionally, you also use the General tab of the Service Provider partner configuration page to configure the following:
Whether SAML artifacts are delivered to this partner via the HTTP POST binding. If so, you may also specify the URI of a custom web application that generates the HTTP POST form for sending the SAML artifact.
The URI of a custom web application that generate the HTTP POST form for sending request or response messages via the POST binding.
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.
This section presents the following topics:
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:
Whether the replicated cache is enabled
If you are configuring SAML 2.0 Identity Provider services in two or more server instances in the domain, this attribute must be enabled.
A custom name mapper class that overrides the default SAML 2.0 assertion name mapper class
For more information about this security provider, see Configuring a SAML 2.0 Identity Assertion Provider for SAML 2.0.
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.
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.
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 > Servers > ServerName > Configuration > Federation Services > SAML 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 Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.
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.
Optionally you may enable the attributes that set the following document signing requirements:
Whether authentication requests sent to Identity Provider partners are signed
Whether assertions received from Identity Provider partners are signed
Optionally you may enable the following attributes of the authentication request cache:
Maximum cache size
Time-out value for authentication requests, which establishes the time interval beyond which stored authentication requests are expired
Oracle recommends enabling all the available binding types for the endpoints of the Service Provider services; namely, POST, and Artifact. Optionally you may specify a preferred binding type.
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 > RealmName > Providers > Authentication > SAML2IdentityAsserterName > Management 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 Oracle Fusion Middleware Oracle WebLogic Server Administration Console 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.
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.
To create an Identity Provider partner and enable interactions for web single sign-on:
From the Management tab of the SAML 2.0 Identity Assertion configuration page, specify the partner's name and metadata file.
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.
Optionally, you can configure the following attributes of the authentication requests generated for, and assertions received from, this Identity Provider partner:
The Identity Provider Name Mapper Class name
This is the custom Java class that overrides the default username mapper class with which the SAML 2.0 Identity Assertion provider is configured in this security realm. The custom class you specify is used only for identities contained in assertions received from this particular partner.
Operations on this attribute are available in the com.bea.security.saml2.providers.registry.IdPPartner Java interface.
Whether the identities contained in assertions received from this partner are mapped to virtual users in the security realm
Note:
To use this attribute, you must have a SAML Authentication provider configured in the realm.Operations on this attribute are available in the com.bea.security.saml2.providers.registry.IdPPartner Java interface.
Whether to consume attribute information contained in assertions received from this partner
If enabled, the SAML 2.0 Identity Assertion provider extracts attribute information from the assertion, which it uses in conjunction with the SAML Authentication provider (which must be configured in the security realm) to determine the groups in the security realm to which the corresponding user belongs.
Operations on this attribute are available in the com.bea.security.saml2.providers.registry.IdPPartner Java interface.
Whether authentication requests sent to this Identity Provider partner must be signed. This is a read-only attribute that is derived from the partner's metadata file.
Operations on this attribute are available in the com.bea.security.saml2.providers.registry.WebSSOIdPPartner Java interface.
Whether SAML artifact requests received from this Identity Provider partner must be signed.
Operations on this attribute are available in the com.bea.security.saml2.providers.registry.WebSSOIdPPartner Java interface.
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.
Note:
If you configure one or more redirect URIs, remember to set a security policies on them as well; otherwise the web container will not attempt to authenticate the user and, consequently, not redirect the user's request to the Identity Provider partner.WebLogic Server provides the com.bea.security.saml2.providers.registry.WebSSOIdPPartner Java interface for configuring this attribute.
Optionally, you also use the General tab of the Service Provider partner configuration page to configure the following:
Whether SAML artifacts are delivered to this partner via the HTTP POST method. If so, you may also specify the URI of a custom web application that generates the HTTP POST form for sending the SAML artifact.
The URL of the custom web application that generates the POST form for carrying the SAML response for POST bindings to this Identity Provider partner.
The URL of the custom web application that generates the POST form for carrying the SAML response for Artifact bindings to this Identity Provider partner.
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.
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:
The Site tab displays information about the Service Provider partner, which is derived from the partner's metadata file. The data in this tab is read-only.
WebLogic Server provides the com.bea.security.saml2.providers.registry.MetadataPartner Java interface for partner site information.
The Single Sign-On Signing Certificate tab displays details about the partner's signing certificate, which are also derived from the partner's metadata file. The data in this tab is read-only.
Operations on these attributes are available from the com.bea.security.saml2.providers.registry.WebSSOPartner Java interface.
The Transport Layer Client Certificate tab displays partner's transport layer client certificate. You can optionally import this certificate by clicking Import Certificate from File.
Operations on this attribute are available from the com.bea.security.saml2.providers.registry.BindingClientPartner Java interface.
When configuring Service Provider partners, the Assertion Consumer Service Endpoints tab is available, which displays the Service Provider partner's ACS endpoints. This data is also available from the com.bea.security.saml2.providers.registry.WebSSOSPPartner Java interface.
When configuring Identity Provider partners, the Single Sign-On Service Endpoints tab is available, which displays the Identity Provider partner's single sign-on service endpoints. This data is also available from the com.bea.security.saml2.providers.registry.WebSSOIdPPartner Java interface.
The Artifact Resolution Service Endpoints tab displays the partner's ARS endpoints. This data is also available from the com.bea.security.saml2.providers.registry.WebSSOPartner Java interface.
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:
Note the following recommendations regarding the use of the following elements in deployment descriptor files:
relogin-enabled
cookie-name
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.
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.
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.
When an Identity Provider's single sign-on service receives an authentication request, it redirects that request to the login application to authenticate the user. The login application must execute on the same cluster node as that single sign-on service. If not, the Identity Provider is unable to produce a SAML 2.0 assertion even if the authentication succeeds.
Under normal circumstances, the login application executes on the same node as the single sign-on service, so likelihood of the authentication request being redirected to a login application executing on a different node in the domain is very small. However, it may happen if an authentication request is redirected by a cluster node different than the one hosting the login application. You can almost always prevent this situation from occurring if you configure the Identity Provider to use the default login URI with Basic authentication.
When the SAML 2.0 Assertion Consumer Service (ACS) successfully consumes an assertion, it logs in the Subject represented by the assertion. The ACS then redirects the user request to the target application. Normally, the target application executes on the same node as the ACS. However, in rare circumstances, the target application to which is the user request is redirected executes on a cluster node other than the one hosting the ACS on which the login occurred. When this circumstance occurs, the identity represented by the assertion is not propagated to the target application node. The result is either another attempt at the single sign-on process, or denied access.
Because the target application executes on the same node as the ACS, this situation is expected to occur very rarely.
When configuring SAML 2.0 Service Provider services, enabling both the Force Authentication and Passive attributes is an invalid configuration that WebLogic Server is unable to detect. If both these attributes are enabled, and an unauthenticated user attempts to access a resource that is hosted at the Service Provider site, an exception is generated and the single sign-on session fails.
Note that the Force Authentication attribute has no effect because SAML logout is not supported in WebLogic Server. So even if the user is already authenticated at the Identity Provider site and Force Authentication is enabled, the user is not forced to authenticate again at the Identity Provider site.