Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

6 Appendix A: Product Behavior

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include released service packs:

  • Windows 2000 operating system

  • Windows XP operating system

  • Windows Server 2003 R2 operating system

  • Windows Vista operating system

  • Windows Server 2008 operating system

  • Windows 7 operating system

  • Windows Server 2008 R2 operating system

  • Windows 8 operating system

  • Windows Server 2012 operating system

  • Windows 8.1 operating system

  • Windows Server 2012 R2 operating system

Exceptions, if any, are noted below. If a service pack or Quick Fix Engineering (QFE) number appears with the product version, behavior changed in that service pack or QFE. The new behavior also applies to subsequent service packs of the product 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.6: All Windows behavior documented in this specification applies only to Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2.

<2> Section 1.8: Windows uses the protocol extensions specified in [MS-MWBE]. For further specifications on these extensions, see [MS-MWBE].

<3> Section 1.8: Windows uses the existing extensibility points specified in [WSFedPRP] as protocol extensions, as specified in [MS-MWBE]. For details on these extensions, see [MS-MWBE].

<4> Section 2.1: Except in the cases specified in [MS-MWBE] section 3.2.5.1.1, Windows uses POST methods to transmit wsignin1.0 responses to relying parties.

<5> Section 2.1: Windows requires use of the HTTPS URL scheme to identify each IP/STS and WS resource participating in the protocol.

<6> Section 2.1: Requests for wsignout1.0 and wsignoutcleanup1.0 are not authenticated by Windows.

<7> Section 2.2: These messages are not supported. For the protocol behavior of Windows for such messages, see section 3.1.5.1.

<8> Section 2.2: Parameters not specified in this document are not supported. For the protocol behavior of Windows on nonspecified parameters, see section 3.1.5.1.

<9> Section 2.2.1: These parameters are not supported. For the protocol behavior of Windows on these parameters, see section 3.1.5.1.

<10> Section 2.2.2: This parameter is supported. For the protocol behavior of Windows on this parameter, see sections 3.1.5.4.7 and 3.3.5.1.2.

<11> Section 2.2.2: This parameter is not supported. For the protocol behavior of Windows for this parameter, see section 3.1.5.1.

<12> Section 2.2.3: This parameter is supported by Windows. For the protocol behavior of Windows on this parameter, see sections 3.1.5.4.7 and 3.3.5.1.2.

<13> Section 2.2.3: This parameter is supported by Windows. For the protocol behavior of Windows on this parameter, see section 3.3.5.1.2.

<14> Section 2.2.3: The values supported for this parameter are specified in the following table. For the protocol behavior of Windows on this parameter, see sections 3.1.5.4.2 and 3.3.5.1.2

Method of authentication wanted

wauth URI

User name/password authentication

urn:oasis:names:tc:SAML:1.0:am:password

SSL client authentication

urn:ietf:rfc:2246

Windows integrated authentication

urn:federation:authentication:windows

Multiple factor authentication

http://schemas.microsoft.com/claims/multipleauthn

If the HTTP GET of the wsignin1.0 request message (section 2.2.3) contains an X-MS-Proxy HTTP header, then Windows integrated authentication; otherwise, multiple factor authentication. The X-MS-Proxy HTTP header is defined in [MS-ADFSPIP] section 2.2.1.1.

http://schemas.microsoft.com/claims/wiaormultiauthn

<15> Section 2.2.3: This parameter is conditionally supported. For the supported conditions and processing semantics of Windows for this parameter, see sections 3.1.5.4.2 and 3.3.5.1.2.

<16> Section 2.2.3: The ClientRequestID parameter is supported only on Windows Server 2012 R2.

<17> Section 2.2.3: The login_hint parameter is supported only on Windows Server 2012 R2.

<18> Section 2.2.3: The username parameter is supported only on Windows Server 2012 R2.

<19> Section 2.2.4: This parameter is supported. For the protocol behavior of Windows on this parameter, see section 3.1.5.4.7.

<20> Section 2.2.4.1: The AppliesTo element is supported. For the protocol behavior of Windows for the AppliesTo element, see sections 3.1.5.4.7 and 3.3.5.2.2.

<21> Section 2.2.4.1: Optional elements and attributes are not supported. For the protocol behavior of Windows for optional elements and attributes in the RSTR, see 3.1.5.4.7 and 3.3.5.2.2.

<22> Section 2.2.4.2: The Advice element is used by Windows to extend the protocol. These extensions are as specified in [MS-MWBE].

<23> Section 2.2.4.2.1.2: The AttributeStatement is conditionally supported. For more information on the protocol behavior of Windows for AttributeStatements, see sections 3.1.5.4.7 and 3.3.5.2.2.

<24> Section 2.2.4.2.1.2: This namespace is supported. For the protocol behavior of Windows for AttributeNamespace values, see sections 3.1.5.4.7 and 3.3.5.2.2.

<25> Section 2.2.4.2.1.3: The SubjectConfirmation element is not supported. For the protocol behavior of Windows for the SubjectConfirmation element, see sections 3.1.5.4.7 and 3.3.5.2.2.

<26> Section 2.2.4.2.2: Both direct inclusion and SKI are supported for X.509 certificates. For the protocol behavior of Windows for referencing X.509 certificates, see sections 3.1.5.4.7 and 3.3.5.2.2.

<27> Section 2.2.5: The wreply parameter is not supported. For the protocol behavior of Windows for this parameter, see sections 3.1.5.4.7 and 3.3.5.1.2.

<28> Section 2.2.6: The wreply parameter is not supported. For the protocol behavior of Windows for this parameter, see section 3.3.5.4.2.

<29> Section 3.1.1.2: The requestor IP/STS and relying parties use internal data structures similar to Authentication Context and support all of the fields defined for the abstract data model.

<30> Section 3.1.1.3: This information is exchanged using files that can be generated, or consumed, using export or import capabilities. Also, the information can be typed into a management console.

<31> Section 3.1.1.3: Two separate records are used for a federation partner that is capable of playing both roles.

<32> Section 3.1.1.3: Both configurations are supported. If a requestor IP/STS is configured as a farm of servers, each server can use a different private key, or the same private key can be installed on all servers.

<33> Section 3.1.1.3: Metadata exchanged between federation partners includes claims requested by a relying party. A requestor IP/STS stores this information in local configuration data using the ClaimsOut concept.

<34> Section 3.1.1.3: Metadata exchanged between federation partners includes claims requested by a relying party. A relying party stores this information in local configuration data using the ClaimsIn concepts.

<35> Section 3.1.1.3: A requestor IP/STS includes as many claims as possible based on the attributes available for the user that is the subject of the security token. It sends the security token even if not all of the requested claims can be generated.

<36> Section 3.1.1.4: A requestor IP/STS includes optional claims requested by a relying party in the AttributeStatement of the security token issued.

<37> Section 3.1.1.4: Federation partners, performing either the requestor IP/STS or the relying party role, support the EmailAddress, UPN, CommonName, and Group claims, as defined in section 3.1.1.4. Based on local configuration, relying parties interpret Group claims as strings or map them to specific group objects defined in Active Directory.

<38> Section 3.1.1.4: Federation partners, performing either the requestor IP/STS or the relying party role, support the Custom claim as defined. Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 will reject any request containing an AttributeNamespace value other than http://schemas.xmlsoap.org/claims with an HTTP 1.1 status code 500 server error.

<39> Section 3.1.1.5: HTTP session cookies, as specified in [RFC2965], are used to identify individual web browser requestors.

<40> Section 3.1.1.5.1: An HTTP session cookie, as specified in [RFC2965], is issued to a web browser requestor to manage the list of relying parties that should be sent wsignoutcleanup1.0 messages when the user requests to sign out. The cookie is rewritten for every new security token that is issued for the web browser requestor session.

<41> Section 3.1.1.5.2: An HTTP session cookie, as specified in [RFC2965], is issued to a web browser requestor to manage the list of requestor IP/STSs that should be sent wsignout1.0 messages when the user requests to sign out. The cookie is rewritten for every new security token that is received for the web browser requestor session.

<42> Section 3.1.2: A web browser requestor access request, such as an HTTP GET or POST, for a particular URL managed by a WS resource is rejected if the validity interval of the Authentication Context for the user has expired. Once an access request has been accepted, it will be processed even if the validity interval expires before the response is returned to the web browser requestor.

<43> Section 3.1.2: Timers are not used to determine when validity intervals expire. The NotBefore and NotOnOrAfter values obtained from security tokens and recoded in Authentication Contexts are checked explicitly.

<44> Section 3.1.5.1: Federation partners do not emit query string parameters when sending a protocol message using an HTTP POST. If any query string parameters are received with an HTTP POST, they are ignored.

<45> Section 3.1.5.1: The xml-attribute-request and the xml-pseudonym-request messages described in section 2.2 are not emitted by Windows. Windows Server 2003 returns an HTTP 403 error message. Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 return an HTTP 500 error message if they receive such messages. Any parameters that are not specified in section 2.2 or in the protocol extension specified in [MS-MWBE] are ignored by Windows.

<46> Section 3.1.5.2: An unsupported or unrecognized parameter received with a protocol message is ignored, and the message is processed as if it were not present.

<47> Section 3.1.5.2: SOAP faults are not used. An HTTP 500 error response is returned to the web browser requestor.

<48> Section 3.1.5.3.2: A WS resource stores the application URL in the wctx parameter. A resource IP/STS stores the WS resource URL in the wctx parameter by prepending it to the incoming value.

<49> Section 3.1.5.3.3: A web browser requestor can send an HTTP GET with a whr parameter to WS resource URLs directly. A relying party uses the whr parameter for security realm discovery when present. If this parameter is not present, a resource IP/STS displays an HTML form to collect the information from the user.

<50> Section 3.1.5.3.3: A resource IP/STS writes a persistent cookie (for more information, see [RFC2965]) to the web browser requestor to preserve the value of the security realm identifier.

<51> Section 3.1.5.4.2: If the wauth parameter, which is described in section 2.2.3, is present and is not set to one of the values from the table in that section, Windows returns an HTTP 1.1 status code 500 server error.

<52> Section 3.1.5.4.3: An IP/STS can authenticate a user by means of the Windows implementation of Kerberos (for more information, see [RFC4120]) by collecting the user's Windows identifier and password in an HTML form (using HTTPS) and validating the credentials with Active Directory, or by client SSL authentication using an X.509 certificate issued to the web browser requestor. An IP/STS can also authenticate the user by initiating the Microsoft Web Browser Federated Sign-On Protocol with another STS.

<53> Section 3.1.5.4.4: Attributes are retrieved from either Active Directory or Active Directory Application Mode using authenticated LDAP binds.

<54> Section 3.1.5.4.7: The following Windows behaviors apply for response message processing:

  • The wctx parameter specified in section 2.2.2 is always returned by Windows with the response if the parameter is present in the request.

  • When emitting wsignin1.0 responses, Windows includes the wsp:AppliesTo element.

  • When emitting wsignin1.0 response messages, Windows does not include any other optional elements or attributes in the RSTR.

  • The presence of the SAML AttributeStatement in the SAML assertion in a wsignin1.0 response message emitted by Windows depends on configuration of the product. Windows supports emitting both no SAML AttributeStatement and one SAML AttributeStatement. Windows includes a SAML AttributeStatement when more than one claim is included in the token. For further specifications, see sections 3.1.1.4 and 3.1.5.

  • When emitting wsignin1.0 response messages, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 use the namespace http://schemas.xmlsoap.org/claims.

  • Windows does not specify the SubjectConfirmation element when emitting wsignin1.0 response messages.

  • When emitting wsignin1.0 response messages, Windows includes the X.509 certificate directly in the KeyInfo element by default. Windows does not reference X.509 certificates using the X509SKI element by default when emitting wsignin1.0 response messages. Windows can be configured to use the X509SKI element when emitting wsignin1.0 response messages.

<55> Section 3.1.6: Timers are not used to determine when validity intervals expire. The NotBefore and NotOnOrAfter values obtained from security tokens and recoded in Authentication Contexts are checked explicitly.

<56> Section 3.2.5.2.2: An STS, regardless of role, sends wsignoutcleanup1.0 messages to relying parties. An HTTP session cookie (for more information, see [RFC2965]) is issued to a web browser requestor to manage the list of relying parties that should be sent wsignoutcleanup1.0 messages when the user requests to sign out. A requestor IP/STS does not cache any user or web browser requestor session data on a server.

<57> Section 3.2.5.2.3: The wreply parameter is not supported for wsignout1.0 request messages, so the web browser requestor is not redirected after wsignoutcleanup1.0 messages are sent.

<58> Section 3.2.5.3.2: An HTTP session cookie (for more information, see [RFC2965]) is issued to a web browser requestor to manage the list of relying parties. A requestor IP/STS sends wsignoutcleanup1.0 messages to all relying parties identified in the session cookie when a user requests to sign-out.

<59> Section 3.2.5.3.3: All of the web browser requestor session state that needs to be deleted is maintained in an HTTP session cookie (for more information, see [RFC2965]). This cookie is deleted as part of the process of sending wsignoutcleanup1.0 messages.

<60> Section 3.2.5.3.4: When a wsignout1.0 message is received, Windows sends a wsignoutcleanup1.0 message to all relying parties identified by the Outbound Sessions List maintained for the web browser requestor. An HTML page that contains a set of IFrames, one for each WS resource, is constructed. In the process of returning this HTML page to the web browser requestor, the HTTP session cookie used to maintain the Outbound Sessions List is deleted. Processing of the iframes in this HTML page by the web browser requestor causes the wsignoutcleanup1.0 messages to be sent in parallel. Windows does not use the wreply parameter when emitting wsignoutcleanup1.0 messages.

<61> Section 3.2.6: Timers are not used to determine when validity intervals expire. The NotBefore and NotOnOrAfter values obtained from security tokens (see section 2.2.4.2) and recoded in Authentication Contexts are checked explicitly.

<62> Section 3.3.1: A relying party is implemented as separate resource IP/STS and WS resource components. This factorization is used whether or not the components are deployed on the same server or on different servers.

<63> Section 3.3.1: A relying party is factored into separate resource IP/STS and WS resource components even if the components are located on the same server. Interactions between the resource IP/STS and WS resource are not exposed to requestor IP/STSs in other security realms.

<64> Section 3.3.1.1: The roles a federation partner may perform are indicated in configuration data, as described in section 3.3.1.1. This information is obtained using out-of-band metadata exchange. Files can be exchanged using export or import capabilities, or the data may be typed into a management console.

<65> Section 3.3.1.1: Federation partner URLs are maintained in configuration data. This configuration data is always treated as authoritative versus the value of a wreply parameter received in a wsignin1.0 message.

<66> Section 3.3.2: Timers are not used to determine when validity intervals expire. The NotBefore and NotOnOrAfter values obtained from security tokens, as specified in section 2.2.4.2, and recoded in Authentication Contexts are checked explicitly. A resource IP/STS or a WS resource will reject a security token for which the validity interval has expired. A WS resource maintains a user's Authentication Context in an HTTP session cookie (for more information, see [RFC2965]). The cookie is signed to prevent undetected manipulation. The WS resource will return an HTTP 500 error for any request that is accompanied by a session cookie for which the validity interval has expired.

<67> Section 3.3.3: By default, relying parties support CRL checking by means of a CDP. However, if the CDP is not accessible, CRL checking can be disabled to prevent otherwise acceptable security tokens from being rejected.

<68> Section 3.3.5.1.1: A dialect of the Microsoft Web Browser Federated Sign-On Protocol is used, with the WS resource acting as a relying party and the resource IP/STS acting as a requestor IP/STS. The WS resource sends a wsignin1.0 request message to the resource IP/STS to request a security token for the user.

<69> Section 3.3.5.1.2: The following Windows behaviors apply when marshaling parameters for a request message:

<70> Section 3.3.5.2.2: The following Windows behaviors apply when validating wsignin1.0 response messages:

  • Windows processes wsp:AppliesTo messages according to the message syntax requirements specified in section 2.2.4.1 when receiving wsignin1.0 responses.

  • Windows ignores any other optional elements included in the RSTR when processing received wsignin1.0 response messages.

  • Windows supports processing both no SAML AttributeStatement and one SAML AttributeStatement when receiving wsignin1.0 responses.

  • Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 reject the security token with an HTTP 1.1 500 error code if a wsignin1.0 response is received with an Attribute element that has an AttributeNamespace value other than http://schemas.xmlsoap.org/claims.

  • When processing received wsignin1.0 messages, Windows ignores the SubjectConfirmation element, if present.

  • When receiving wsignin1.0 responses, Windows uses the certificate included directly in the X509Certificate element, if present. When receiving wsignin1.0 responses, Windows uses the SKI, if present, to look up the corresponding certificate and continue to process the message. A failed look-up will result in the wsignin1.0 response messages being rejected with an HTTP 1.1 500 server error.

  • When receiving wsignin1.0 responses, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 reject any messages with the EncryptedData element described in section 2.2.4.1 with an HTTP 1.1 500 server error.

<71> Section 3.3.5.2.4: A user's identity from the Subject element of the security token is mapped to a local Windows security principal identity in Active Directory based on local configuration. In terms of the Authentication Context abstract data model, the local Windows security principal identity replaces the AuthIdentity value derived from the Subject of a security token.

<72> Section 3.3.5.2.6: The Microsoft Web Browser Federated Sign-On Protocol is used with the WS resource acting as a relying party and the resource IP/STS acting as a requestor IP/STS. The resource IP/STS sends a wsignin1.0 response message to the WS resource to issue a security token for the user. There is no change to the protocol message processing, as specified in section Issuing a Security Token by responding to a wsignin1.0 request message (section 3.1.5.4).

<73> Section 3.3.5.3.2: The wreply parameter described in section wsignout1.0 Request Message (section 2.2.5) is not supported when emitting wsignout1.0 Request Messages.

<74> Section 3.3.5.3.3: Relying party components, both resource IP/STSs and WS resources, send wsignout1.0 messages to security token services. An HTTP session cookie (for more information, see [RFC2965]) is issued to a web browser requestor to manage the list of security token services that should be sent wsignout1.0 messages when the user requests to sign-out.

<75> Section 3.3.5.4.2: A security token service, regardless of role, sends wsignoutcleanup1.0 messages to relying parties. An HTTP session cookie (for more information, see [RFC2965]) is issued to a web browser requestor to manage the list of relying parties that should be sent wsignoutcleanup1.0 messages when the user requests to sign-out. A resource IP/STS does not cache any user or web browser requestor session data on a server.

<76> Section 3.3.5.4.3: A security token service, regardless of role, sends wsignoutcleanup1.0 request messages to relying parties. An HTTP session cookie (for more information, see [RFC2965]) is issued to a web browser requestor to manage the list of relying parties that should be sent wsignoutcleanup1.0 messages when the user requests to sign-out.

<77> Section 3.3.5.4.4: An HTML page that contains a set of iframes (as specified in [HTML] section 16.5), one for each WS resource, is returned to the web browser requestor. Processing of the iframes by the web browser requestor causes the wsignoutcleanup1.0 messages to be sent in parallel.

<78> Section 3.3.5.4.5: When receiving a wsignoutcleanup1.0 request message (section 2.2.6), the web browser requestor is not redirected to the wreply URL after sign-out processing is complete. Windows completes by returning a string indicating that clean up is complete for the security realm, regardless of the presence of wreply.

<79> Section 3.3.6: Timers are not used to determine when validity intervals expire. The NotBefore and NotOnOrAfter values obtained from security tokens, as specified in section 2.2.4.2, and recoded in Authentication Contexts are checked explicitly.

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

<81> Section 3.4.5: Internet Explorer in Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 always passes protocol messages through unaltered. The RMS 2.0 client in Windows Vista SP1, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 adds a whr parameter to the wsignin 1.0 Request Message (section 2.2.3) if the wsignin 1.0 Request Message does not already contain a whr parameter.

<82> Section 5.1.1: The Windows IP/STS only supports the RSA algorithm (for more information, see [RFC3447]) for signatures, and supports the SHA-1 algorithm (for more information, see [FIPS180]) for calculating digests. The default key length of the Windows RSA keys used for signing security tokens is 2,048 bits.

<83> Section 5.1.2: The certificate validation behavior of Windows is configurable. By default, for certificates used to sign security tokens, Windows ensures that the current time is in the certificate's validity interval, that the certificate has a valid signature, that the certificate is issued by a trusted authority, and that the certificate serial number is not present in the CRL of the issuing authority.

<84> Section 5.1.3: The use of SSL/TLS is required for each Windows IP/STS and WS resource.

<85> Section 5.1.4: The validity period of security tokens issued by the Windows IP/STS is limited to 8 hours by default.

<86> Section 5.1.5: The Windows requestor IP/STS may be configured to issue a different identifier to each resource IP/STS for each user to prevent correlation of user information across multiple relying parties. This behavior is turned off by default.

<87> Section 5.1.6: The Windows resource IP/STS requires that messages from each requestor IP/STS be restricted to only using a specific set of suffix DNS names when UPN or EmailAddress is used as the unique identifier for the user by that requestor IP/STS.

<88> Section 5.1.7: Windows sets cookies as secure.

 
Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.