Review how ADFS may affect privacy
Updated: November 8, 2007
Applies To: Windows Server 2003 R2
Active Directory Federation Services (ADFS) provides Web single-sign-on (SSO) technologies to authenticate a user to multiple Web applications over the life of a single online session. When you build an application using ADFS in Windows Server 2003 R2, your application may affect your end users’ privacy.
For example, your application may explicitly collect user contact information, or it may request or send information over the Internet to your Web site or partner Web sites. If you embed Microsoft technology in your application, that technology may have its own behavior that may affect privacy.
Messages contain Security Assertion Markup Language (SAML) tokens that may include application-defined personal data, depending on the claims that an administrator chooses to include in the token. The information that is contained in these SAML tokens is signed by the Federation Service’s token-signing certificate, or, in some cases, the information is protected by a Kerberos session key. Messages are secured by the use of Secure Sockets Layer (SSL).
Communication between the Federation Service and the application
Although messages between Federation Services and Web applications transmit message routing information and body information, messages are typically secure by default. In addition, although messages contain application-specific data, such as application-defined personal information, this data is secured during transmission by SSL.
Communication between the user and the application
Query string parameters in the messages between a user and an application are subject to inspection by the account federation servers and the resource federation servers. Because an account federation server may be in a different organization, we recommend that you use a programming method that helps to ensure user privacy when you build Web applications.
A mitigation for this problem is to program an application to use HTTP POSTs, such as ASP.NET form submits, to communicate information that a user supplies. However, this method may have unreliable results because unauthenticated POSTs to applications that are protected by ADFS lose the POST body during ADFS authentication. (Unauthenticated POSTs include initial POSTs or POSTs that occur immediately after a token expires.) In spite of the potential for unreliable results, using an HTTP POST may prevent sensitive user data from being disclosed.
During the process of authenticating a user, the user is redirected to his or her account organization to perform authentication. As part of this request, the Uniform Resource Locator (URL) of the original requested page at the resource organization is included in encoded form. An account organization may decode this value to determine the first page at the resource that is accessed by the user.
After a token is verified at a Federation Service or Web application, an authentication cookie is issued to the client browser. Each time that a client must be authenticated, this cookie is used by the Federation Service, and, if the cookie is valid, the user is not required to enter his or her credentials again. The contents of this cookie are encrypted by SSL during transmission.
Application-defined personal information may be contained in this cookie, depending on the claims that an administrator includes in the token, and this personal information may be written to the disk of the Web browser. The contents of authentication cookies are signed, but they are not encrypted when they are written to disk.
All authentication cookies are session cookies that typically exist only in memory. These cookies are removed when the browser session ends or the ADFS sign-out procedure is invoked.
During the process of home-realm discovery at a resource Federation Service or Federation Service Proxy, the client is prompted to select its account realm before being redirected to authenticate. After the account provider is selected, a persistent cookie is written to the disk of the Web browser computer that identifies the account provider. This cookie has a configurable lifetime, with a default of 30 days.
When you enable the Audit object access policy setting and you configure ADFS for auditing, ADFS audits authentication events. This includes the authentication of the user and any evidence, such as tokens, that the user presents. Application-defined personal information may be included in the security log, based on the configuration of the Federation Service that issues the security token. When auditing is enabled, both claim names and values are written to the security log. When the Limit the auditing of this claim check box is selected for a specific claim, only the claim’s name is written to the security log.
Enhanced identity privacy
Enable enhanced identity privacy is an optional setting that you can configure for a resource partner in the trust policy. If the Enable enhanced identity privacy option is enabled, this setting hashes the user-name portion of outgoing user principal name (UPN) claims and e-mail claims. A random value is substituted for the common name.
The purpose of this feature is to prevent:
The resource partner from correlating identity claims to personally identifiable user information.
Collusion between partners in correlating identity claims to personally identifiable user information.
Simple dictionary attacks to determine identity.
How enhanced identity privacy works
If you enable the Enable enhanced identity privacy setting, the user’s identity is transformed by the account Federation Service before it is sent to the resource realm. The account Federation Service does this by hashing a combination of the privacy key (for salting), the resource partner Uniform Resource Identifier (URI), and the identity claim itself, as well as the privacy key (for salting), which reduces the possibility of dictionary attacks. When these three elements are combined, a unique hash per partner is created so that the resulting transformed identity is the same when the following values are the same:
Resource partner URI
Identity claim (UPN or e-mail)
The hashing algorithm is case sensitive. Therefore, the hashed results are different if the case of the URI or the user-name portion of the UPN claim or e-mail claim is different.
The IT pro experience
By default, ADFS records activities and events that are associated with messages to the event log. Event log entries are written that include data from messages and activities that are associated with those messages. This may include application-defined personal information, depending on the logging level and the claims that an administrator includes in the token.
You may configure ADFS to log messages that pass through the ADFS system, along with the activities and events that are associated with these messages. This feature is turned off by default. When logging is enabled, a log is written to the configured location. The log includes the messages and activities and the events that are associated with those messages. This may include application-defined personal information, depending on the logging level and the claims that an administrator includes in the token.