Share via

6 Appendix A: Product Behavior

  • Article

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

  • Windows Server 2003 R2 operating system

  • Windows Server 2008 operating system

  • Windows Server 2008 R2 operating system

  • Windows Server 2012 operating system

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 1.5: The Windows implementation of the SAML 1.1 Assertion Extension is integrated with Windows Active Directory. All SIDs that are transmitted in the SAML assertion correspond to Active Directory accounts. In order to transmit SIDs between a requestor IP/STS and a resource IP/STS that reside in different forests, the requestor IP/STS forest must be a trusted forest of the resource IP/STS forest.

<2> Section 1.5: Local configuration is used to modify several of the Windows behaviors described in this document. In all cases, the local configuration must exist before the protocol is initiated. Specific instances where local configuration is used are listed below.

By default, an IP/STS does not issue security tokens with SIDs (see section 3.1.5.2). The issuance of SIDs (that is, including the WindowsUserIdentifier (section 3.1.5.2.1.3), WindowsUserName (section 3.1.5.2.1.4), and WindowsIdentifiers (section 3.1.5.2.1.5) elements in issued SAML assertions) can be enabled for specific relying parties by using local configuration.

By default, when a user authenticates to a resource IP/STS by using a security token from a requestor IP/STS (see section 3.1.5.2), any SIDs in the SAML assertion are ignored (that is, the WindowsUserIdentifier (section 3.1.5.2.1.3), WindowsUserName (section 3.1.5.2.1.4), and WindowsIdentifiers (section 3.1.5.2.1.5) elements). Processing these SIDs (as described in section 3.1.5.2) can be enabled for specified requestor IP/STSs using local configuration. In this case, the local configuration also specifies a Windows domain associated with the IP/STS, so that SID filtering can be performed (as specified in section 5.1.3).

When a user authenticates to a resource IP/STS by using a security token from a requestor IP/STS (as specified in section 3.1.5.2), claims can be mapped to SIDs based on local configuration. In this case, the local configuration also specifies the desired value of the TryLocalAccount flag (as specified in WindowsIdentifierFlags Structure (section 2.2.3.2.1)).

A special algorithm is used to determine when the Query String Response Protocol is used (as specified in section 3.2.5.1.1). This algorithm uses local configuration to force the use of the protocol and for the FileExtensionBypassList flag.

<3> Section 1.6: The Query String Response Transfer Protocol is supported only in Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012.

<4> Section 1.6: SAML1.1 Assertion Extension is supported only in Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2.

<5> Section 1.9: The following URIs are used as local assignments in fields specified by the SAML 1.1 Assertion Extension: "urn:federation:activedirectory" and "urn:microsoft:federation".

<6> Section 2.2.3.1: Support for this field is conditional, as specified in CookieInfoHash Element (section 3.1.5.2.1.2).

<7> Section 2.2.3.1: WindowsUserName Element (section 3.1.5.2.1.4) specifies how Windows constructs the WindowsUserName value.

<8> Section 3.1.1.1.1: The pending result is maintained in secure session cookies written using Set-Cookie headers (as specified in [RFC2965]), which are added to the HTTP 302 response to the web browser requestor.

<9> Section 3.1.1.1.2: The recommended value is used.

<10> Section 3.1.2: There are no new timers. The pending result is stored by using secure session cookies (see section 3.1.1.1.1).

<11> Section 3.1.5.2.1.1: The IP/STS only includes this element when it is a resource IP/STS. The value identifies Active Directory, a Lightweight Directory Access Protocol (LDAP) service, or a security realm. If the user authenticated by using Active Directory, the ClaimSource (section 3.1.5.2.1.1) value is "urn:federation:activedirectory". If the user authenticated by using an LDAP service, the ClaimSource (section 3.1.5.2.1.1) value is a URI associated with the LDAP service, for example "LDAP://ldap.example.com". If the user authenticated by using a SAML assertion from a Requestor IP/STS, the ClaimSource (section 3.1.5.2.1.1) value is the value of the Security Assertion Markup Language (SAML) issuer. For more information about user authentication, see [MS-MWBF] section 3.1.5.4.3.

<12> Section 3.1.5.2.1.2: The IP/STS includes the CookieInfoHash (section 3.1.5.2.1.2) element when an authentication cookie is issued at the same time as a SAML assertion. The authentication cookie is a base64-encoded binary structure. Windows includes the base64-encoded SHA-1 hash value (as described in [FIPS180]) of the raw octets.

<13> Section 3.1.5.2.1.3: By default, the IP/STS does not include the WindowsUserIdentifier (section 3.1.5.2.1.3) element. It can be enabled for specific relying parties (see section 1.5). A requestor IP/STS populates this field only if the user authenticated by using Active Directory. A resource IP/STS populates this field only if the user authenticated by using a security token from a requestor IP/STS, in which case the value, if present, is copied from that security token.

<14> Section 3.1.5.2.1.4: By default, the IP/STS does not include the WindowsUserName (section 3.1.5.2.1.4) element. It can be enabled for specific relying parties (see section 1.5). Windows constructs the user name by including the NetBIOS domain name (as it is always available in this context) and Active Directory account name, separated by a backslash (for example, "DOMAIN\user name"). A requestor IP/STS populates this field only if the user authenticated by using Active Directory. A resource IP/STS populates this field only if the user authenticated by using a security token from a requestor IP/STS, in which case the value, if present, is copied from that security token.

<15> Section 3.1.5.2.1.5: By default, the IP/STS does not include the WindowsIdentifiers (section 3.1.5.2.1.5) element. It can be enabled for specific relying parties (see section 1.5).

A requestor IP/STS populates this field only if the user authenticated by using Active Directory. In this case, a WindowsIdentifiers (section 3.1.5.2.1.5) binary structure is constructed that contains a subset of the security identifiers (SIDs) associated with the Active Directory account. The subset consists of the user SIDs, the global group SIDs, and the universal group SIDs. That structure is base64-encoded and included in this field.

A resource IP/STS populates this field only if the user authenticated by using a security token from a requestor IP/STS. If the SAML assertion issued by the requestor IP/STS contains a WindowsIdentifiers field, its value is copied to this field. Otherwise, the resource IP/STS maps claims from the SAML assertion of the requestor IP/STS to SIDs based on local configuration (see section 1.5). If any claims are mapped to SIDs, those SIDs are encoded in a WindowsIdentifiers (section 3.1.5.2.1.5) binary structure with the NoUserSid flag set to 1 and the TryLocalAccount flag set based on local configuration (see section 1.5). The structure is base64-encoded and included in the WindowsIdentifiers field.

<16> Section 3.1.6: There are not any new timer events. The pending result is stored by using secure session cookies (see section 3.1.1.1.1).

<17> Section 3.2.1.1.1: The aggregated result is maintained in secure session cookies written using Set-Cookie headers (as specified in [RFC2965]), which are added to the HTTP 302 response to the web browser requestor.

<18> Section 3.2.2: There are no new timers. The aggregated result is stored using secure session cookies (see section 3.2.1.1.1).

<19> Section 3.2.5.1.1: A special algorithm (described later) determines whether to use the Query String Response Transfer Protocol or not.

The algorithm is presented in pseudocode.

Let KnownClients be a constant set composed of the following strings, which specify user agent string fragments that are known to identify user agents that do not support scripting:

  • "Microsoft FrontPage"

  • "Microsoft Office"

  • "Test for Web Form Existence"

  • "Microsoft Data Access Internet Publishing Provider"

  • "Microsoft-WebDAV"

Let FileExtensionBypassList be a set of strings retrieved from local configuration (see section 1.5) that identify file name extensions.

The algorithm is as follows.

 IF local configuration forces Query String Response Transfer 
 Protocol 
 OR User-Agent is empty 
 OR User-Agent is in KnownClients
 OR NOT User-Agent contains "Mozilla" 
 OR NOT Http-Verb is in (GET,POST) THEN
   Use Query String Response Transfer Protocol
 ELSE
   IF local machine state indicates Windows Sharepoint Services 
   AND NOT Request-URL's file extension is in 
 FileExtensionBypassList THEN
     Use Query String Response Transfer Protocol
   ELSE
     Use the base protocol specified in [MS-MWBF]
   END IF
 END IF

<20> Section 3.2.5.2: By default, the resource IP/STS ignores these fields and processes the security token as though the extension elements are absent. Their processing can be enabled for specific requestor IP/STSs (as specified in section 1.5). Section 3.1.5.2.1 specifies how the resource IP/STS includes the fields. The web service resource uses the fields to provide authorization services to a web-based application on the same machine by using methods that are outside the scope of this protocol.

<21> Section 3.2.6: There are no new timer events. The aggregated result is stored by using secure session cookies (as specified in section 3.1.1.1.1).

<22> Section 3.3.1: Windows Internet Explorer supports the use of session and persistent HTTP cookies (for more information, see [RFC2965]). The Windows implementation of this protocol requires that web browser requestor support at least session cookies. It uses persistent cookies to preserve security realm identifiers if they are supported by the web browser requestor.

<23> Section 3.3.5:  The RMS 2.0 client in Windows Vista operating system with Service Pack 1 (SP1), Windows Server 2008, Windows 7 operating system, Windows Server 2008 R2, Windows 8 operating system, and Windows Server 2012 adds a whr parameter to the wsignin 1.0 Request Message (section 2.2.2) if the wsignin 1.0 Request Message does not already contain a whr parameter.

<24> Section 5.1.2: The inclusion of SIDs can be enabled for specific relying parties (as specified in section 1.5).

<25> Section 5.1.3: A relying party that accepts security identifiers from an IP/STS in another security realm performs SID filtering based on local configuration that associates the IP/STS with a Windows domain (as specified in section 1.5). For more information about SID filtering, see [MS-PAC] section 4.1.2.2.