Drummond Group's Knowledge Library

Because of the numerous configurations with SAML, it is important to have a products properly set up in order to achieve interoperability. For all products, proper metadata setup was needed. Basic partner configuration, such as binding to use and security settings, was determined from the test case steps and configured as expected through the product interface. However, any different, unique or unexpected configurations apart from the normal settings found in metadata, or the typical user interface, are listed below. This is information collected directly from the participants. This was the configuration for the products within this test, and it may be different for individual user deployments.

Entrust GetAccess

With some exceptions, we configured the system to always sign requests and responses and always require and verify signatures for incoming requests and responses.

To validate signatures, Microsoft required that Entrust GetAccess be configured to include the certificate in the signature data in both the IDP and SP

By default GetAccess performs XML type normalization. Some partners do not perform XML type normalization on large binary objects before signing them. This is particularly an issue when encryption is enabled since the signature is calculated after encryption. To address this issue, Entrust GetAccess was configured with XML type normalization disabled for partners Ping, Novell and Siemens in both the IDP and SP.

Microsoft required that Entrust GetAccess be configured to omit the inclusion of the Assertion OneTimeUse option.

By default, encryption of the NameID and Assertion were disabled for each partner. When running TC B/D, Entrust GetAccess configuration had to be changed to enable encryption.

Entrust GetAccess requires that the AuthnContexts used by partners be specified in configuration. The same configuration was used for each partner. The supported AuthnContexts were:

urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession
urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransp
urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified (for Ping only)

Entrust GetAccess includes configuration that maps internal attribute names into SAML Attributes. The same configuration was used for each partner and mapped the required eGov attributes.

When performing TC S, we configured two users in Entrust GetAccess for each partner. One user had the local attributes defined and one did not. For the first user, Entrust GetAccess included the SAML attributes in the assertion. For the second user, Entrust GetAccess did not include the SAML attributes in the assertion.

For MNI, the Entrust GetAccess interop UIs included a page that allowed the partner to perform MNI operations including local removal of the persistent identifier name. MNI links were not provided for the different bindings.

For CDC, the hostname using the CDC domain had to be configured in the Entrust GetAccess configuration. CDC support can be enabled or disabled within Entrust GetAccess. For the interop testing, CDC functionality was enabled for all tests.

When using POST vs. Artifact at the Entrust GetAccess SP (ex. TC J, or TC A/C vs. B/D), Entrust GetAccess needs to be reconfigured and restarted (i.e. it is either POST or Artifact configured per partner).

Entrust IdentityGuard

With some exceptions, we configured the system to always sign requests and responses and always require and verify signatures for incoming requests and responses.

To validate signatures, Microsoft and Siemens required that Entrust IdentityGuard was configured to include the certificate in the signature data in both the IDP and SP

By default Entrust IdentityGuard performs XML type normalization. Some partners do not perform XML type normalization on large binary objects before signing them. This is particularly an issue when encryption is enabled since the signature is calculated after encryption. To address this issue, Entrust IdentityGuard was configured with XML type normalization disabled for partners Ping, Novell and Siemens in both the IDP and SP.

Microsoft required that Entrust IdentityGuard was configured to omit the inclusion of the Assertion OneTimeUse option.

By default, encryption of the NameID and Assertion were disabled for each partner. When running TC B/D, configuration had to be changed to enable encryption. Both the Entrust IdentityGuard IDP and SP interop test interfaces provided a UI to allow the partner to change this configuration.

Entrust IdentityGuard requires that the AuthnContexts used by partners be specified in configuration. The same configuration was used for each partner. The supported AuthnContexts were:

urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession
urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified (for Ping only)

Entrust IdentityGuard includes configuration that maps internal attribute names into SAML Attributes. The same configuration was used for each partner and mapped the required eGov attributes.

When performing TC S, we configured two users in Entrust IdentityGuard for each partner. One user had the local attributes defined and one did not. For the first user, Entrust IdentityGuard included the SAML attributes in the assertion. For the second user, Entrust IdentityGuard did not include the SAML attributes in the assertion.

For MNI, the Entrust IdentityGuard interop UIs for both the IDP and SP included a page that allowed the partner to perform MNI operations including local removal of the persistent identifier name.

Entrust IdentityGuard does not locally logout the user after an MNI terminate. In TC E after step 6, the partner should perform a local logout from Entrust IdentityGuard before performing step 7.

For CDC, the hostname using the CDC domain had to be configured in the Entrust IdentityGuard configuration. CDC support can be enabled or disabled within Entrust IdentityGuard. For the interop testing, CDC functionality was enabled for all tests.

IBM

The configuration is pretty much standard. The only things to point out is that we have setup all partners to do what we call is typical signature validation option when importing metadata to your environments. That means that AuthnResponse and ArtifactResolve signatures are not mandated but will get validated if the document is signed.

Microsoft

AuthnRequest signing was enabled during testing. Except Test Case B, assertion encryption was disabled; the default is to encrypt assertions.

Test Case B was accomplished using SLO over redirect instead of SOAP. When Microsoft is the IDP, some partners would include SPNameQuailifer or NameQualifier in the NamID of the SLO messages. By default AD FS 2.0 does not set these attributes. To enable SLO these attributes were added to the assertions to match what was in the SLO message.

To enable IsPassive and ForceAuthn testing, no changes were required to the IDP. However, these attributes are set on the SP through page customization, calling documented APIs.

NameID encrypting for Test Case B is also a non-default configuration and can be configured according to documentation.

Redirect requests can be configured at the SP by setting the default endpoint on a per IdP basis. The IdP requires no additional configuration to accept redirect binding.

Artifact binding response can be configured at the IdP as the default response, this is required for IdP initiated sign in scenarios. For SP initiated scenarios, the IdP will honor the requested protocolBinding. At the SP a request protocolBinding can be configure per documentation. The same holds for POST responses.

IdP discovery is not enabled by default, but may be deployed following product documentation.

The NameID format returned by the IdP must be configured manually, following documentation.

Novell

Novell's software being tested in the 2009 SAML2 Conformance event is both an SP and an IDP. The product tested, including the User Interface is what ships as part of the product. A configuration utility (which is not part of the product) was used to allow participants to quickly configure the software to operate in modes being tested. A more comprehensive admin utility ships with the Novell IDP, but does not allow for changes to be made quickly on-the-fly. The conformance admin utility allowed setting a subset of functions that the product admin can. Exceptions include:

The conformance utility provided a mechanism to specify the binding to be used (SOAP, POST, Redirect) for given tests. The product normally will select the most secure binding to use based on supported bindings identified in provider metadata and those allowed at the Novell IDP. This still required that the binding be supported by both sides.
The conformance utility allowed setting "Passive" authentication requests. In the product, this setting is only used when doing Introductions, and can be tested by selecting an authentication option only available when Introducable IDPs are detected.

No other configurations which are not offered by the product were required.

Tests run by Novell were done primarily using Firefox 1.7.5 and IE 7.0.5730.

Ping

With Microsoft, we always include the certificate in signed messages.

IdP Discovery is not enabled by default with PingFederate. You should follow instruction in the Administrator's Manual in the Section on Configuring IdP Discovery to enable this. The endpoint for an SP using IdP Dicovery is /sp/cdcstartSSO.ping.

SAP

Browser:

When testing with Microsoft in test case B we had to explicitly use Firefox because the SLO URLs exceed the maximum supported length by IE 6 and IE 7.

Signature/Encryption:

The default signature settings in SAP NetWeaver Identity Management 7.2 match the requirements for all IdP Lite/SP Lite test cases except for test case B. For SSO profile by default the AuthnRequest will be signed by the SP and only the Assertion will be signed by the IdP (the Response is unsigned). The encryption of Assertions and NameIDs has to be enabled explicitly. All signature and encryption settings are maintained per trusted provider (partner).

Bindings:

The bindings to be used for the different profiles are again configured per trusted provider (partner). By default HTTP-Redirect for AuthnRequest (SSO), HTTP-POST for Response (SSO) and HTTP-Redirect for LogoutRequest/LogoutResponse (SLO) are used. The SP could be configured to require the Response (SSO) over HTTP-Artifact binding. This is done by setting AssertionConsumerServiceIndex attribute in the AuthnRequest.

For SOAP communication (both SLO and ARS profiles) SAP NW IdM 7.2 supports authentication through username/password, client/server certificate and through digital signature of the corresponding SAML protocol messages.

IdP Discovery:

For IdP Discovery, the IdP and SP has to be configured to use external CDC write/read services. Such services come as part of the product. By default their usage is disabled.

ForceAuthn/IsPassive:

The settings for forced authentication (ForceAuthn) and passive authentication (IsPassive) are maintained per web application and apply for all trusted providers (partners).

Siemens

By default, samlp:AuthnRequest elements are digitally signed (can be disabled through a configuration setting). Details regarding the attributes (e.g. samlp:ForceAuthn, samlp:IsPassive, samlp:AssertionConsumerServiceIndex or samlp:AssertionConsumerServiceURL/samlp:ProtocolBinding) and child elements (e.g. samlp:NameIDPolicy, samlp:RequestedAuthnContext) of samlp:AuthnRequest elements depend on the configuration settings described below.

By default, samlp:Response elements are digitally signed (can be disabled through a configuration setting). Embodied saml:Assertion elements are also digitally signed by default (also configurable) and may be encrypted (i.e. provided as saml:EncryptedAssertion). The actual contents of embodied saml:Assertion elements are subject to:

Directives obtained from samlp:AuthnRequest elements received from SPs
Applicable configuration settings esp. the configured saml:Assertion templates. These are product-specific configuration data objects which control the issuance of saml:Assertion elements at a granular level.
Applicable authentication states of acting users. This includes identity management data esp. the user records and their LDAP attributes, transient information obtained from security protocols (e.g. X.509 certificate contents, contents of [other] saml:Assertion elements) used to authenticate at the IdP as well as information produced by the IdP-side authentication process (e.g. assurance level).

By default, samlp:LogoutRequest and samlp:LogoutResponse elements are digitally signed (can be disabled through a configuration setting). In the samlp:LogoutRequest elements, the SAML name identifier can be provided as saml:NameID or saml:EncryptedID element (configurable). The optional child element samlp:SessionIndex and attribute samlp:NotOnOrAfter (case of an IdP) are provided.

The federation configuration can be managed in the Web-based administrative user interface. The underlying configuration subsystem also provides Web services for managing system configuration. The federation configuration settings are managed by an administrator and may be overridden in a request-specific way by actual end users (respectively the applications that support users) as far as SAML protocol primitives support "negotiation" means i.e. allow requesters to provide directives on how to satisfy a request. This concerns features represented by samlp:ForceAuthn, samlp:IsPassive, samlp:Format, samlp:AllowCreate where samlp:AuthnRequest and its child element samlp:NameIDPolicy provide such "negotiation" means.

Support for SSO / SLO exchanges via the HTTP-Redirect binding is activated at deployment time by providing SAML metadata files with md:SingleSignOnService / md:SingleLogoutService endpoints for the HTTP-Redirect binding. No specific configuration for the HTTP-Redirect binding is needed. There are no assumptions on peers beyond their ability to honor the provided configuration contract (SAML metadata file).

The same statements/assumptions as for the HTTP-Redirect binding hold for the HTTP-POST and Artifact bindings.

The IdP discovery via CDC is a configurable functionality i.e. this functionality needs to be enabled in the configuration subsystem and provided with a setup (esp. common domain name).

Support for the attribute query responder is activated at deployment time by providing SAML metadata files with md:AttributeService endpoints. Moreover, the responder needs to be configured with saml:Assertion templates. Structurally these are the same configuration objects as those described above but a md:AttributeService will typically work with different instances of saml:Assertion templates than a md:SingleSignOnService. The saml:Assertion templates allow attribute encryption to be configured on a per-attribute granularity-level (i.e. saml:EncryptedAttribute). Moreover the assertion can be provided in encrypted form i.e. as a saml:EncryptedAssertion

The attribute query requester functionality is provided through an SDK i.e. it is envisioned that deployments will integrate the attribute requester in a programmatic way with their own code and create own frontends. A Web frontend for the attribute requester is also supplied as an off-the-shelf application.

Support for the authentication query responder is activated at deployment time by providing SAML metadata files with md:AuthnQueryService endpoints. In contrast to the attribute query responder (which is working with saml:Assertion templates) no further configuration setup is needed. For the authentication query requester the same statements as for the attribute query requester hold.

Browser Usage

Since SAML SSO is primarily a web browser based action, each participant was required to use the web browser or web browsers of their choice for certification testing. The browsers used are listed below.

During testing, participants reported problems using Microsoft Internet Explorer (IE) browser when encountering long URL values in HTTP Redirect bindings. IE does not accept URLs longer than 2083 characters (http://support.microsoft.com/kb/208427). This was particularly an issue when encryption was enabled in Test Cases B/D which results in very long URLs stings. Participants worked around this limitation by using a browser other than IE.

Also, a participant reported that it was necessary to accept their self-signed common domain certificate prior to executing Test Case H for IdP Discovery. If not and the certificate was accepted when redirected to the common domain URL, IE would redirect the user back to the original URL after the certificate was accepted.

Entrust GetAccess: Primarily used IE 7 (7.0.5730.13), FireFox 3.5.2 and Google Chrome 0.2.149.29

Entrust IdentityGuard: Primarily used Firefox 3.0 and 3.5 in testing. Also used IE 7, IE 8 and Google Chrome 2.0.

IBM: Firefox 3.0.13

Microsoft: Majority of testing was done with Internet Explorer 8, additional testing was done with Firefox 3.5.2

Novell: Primarily using Firefox 1.7.5 and IE 7.0.5730

Ping: Firefox 3.0.1 and IE 7.0

SAP: IE 6, IE 7, Firefox 3.5

Siemens: Firefox 3.5.2 and Internet Explorer 7.0