Export (0) Print
Expand All

Overview of ADFS

Updated: August 22, 2005

Applies To: Windows Server 2003 R2

Introduction to ADFS

Active Directory® Federation Services (ADFS) is a component in Windows Server® 2003 R2 that provides Web single-sign-on (SSO) technologies to authenticate a user to multiple Web applications over the life of a single online session. ADFS accomplishes this by securely sharing digital identity and entitlement rights, or "claims," across security and enterprise boundaries.

ADFS is not:

  • A database or repository for employee or customer identity data.

  • An extension of the Active Directory schema.

  • A type of Windows domain or forest trust.

ADFS in Windows Server 2003 R2 supports the WS-Federation Passive Requestor Profile (WS-F PRP).

Key features of ADFS

The following are some of the key features of ADFS in Windows Server 2003 R2:

  • Federation and Web SSO

    When an organization uses the Active Directory™ directory service, it currently experiences the benefit of SSO functionality through Windows-integrated authentication within the organization's security or enterprise boundaries. ADFS extends this functionality to Internet-facing applications, which enables customers, partners, and suppliers to have a similar, streamlined, Web SSO user experience when they access the organization’s Web-based applications. Furthermore, federation servers can be deployed in multiple organizations to facilitate business-to-business (B2B) federated transactions between partner organizations.

  • Web Services (WS)-* interoperability

    ADFS provides a federated identity management solution that interoperates with other security products that support the WS-* Web Services Architecture. ADFS does this by employing the federation specification of WS-*, called WS-Federation. The WS-Federation specification makes it possible for environments that do not use the Windows identity model to federate with Windows environments.

  • Extensible architecture

    ADFS provides an extensible architecture that supports the Security Assertion Markup Language (SAML) token type and Kerberos authentication (in the Federated Web SSO with Forest Trust scenario). ADFS can also perform claim mapping, for example, modifying claims using custom business logic as a variable in an access request. Organizations can use this extensibility to modify ADFS to coexist with their current security infrastructure and business policies.

Extending Active Directory to the Internet

Active Directory serves as a primary identity and authentication service in many organizations. With Windows Server 2003 Active Directory, forest trusts can be created between two or more Windows Server 2003 forests to provide access to resources that are located in different business units or organizations. For more information about forest trusts, see How Domain and Forest Trusts Work on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35356).

However, there are scenarios in which forest trusts are not a viable option. For example, access across organizations may need to be limited to only a small subset of individuals, not every member of a forest.

By employing ADFS, organizations can extend their existing Active Directory infrastructures to provide access to resources that are offered by trusted partners across the Internet. These trusted partners can include external third parties or other departments or subsidiaries in the same organization.

ADFS is tightly integrated with Active Directory. ADFS retrieves user attributes from Active Directory, and it authenticates users against Active Directory. ADFS also uses Windows Integrated Authentication.

ADFS works with both Active Directory and Active Directory Application Mode (ADAM). Specifically, ADFS works with both enterprise-wide deployments of Active Directory or instances of ADAM. When it works with Active Directory, ADFS can take advantage of the strong authentication technologies in Active Directory, including Kerberos, X.509 digital certificates, and smart cards. When it works with ADAM, ADFS uses Lightweight Directory Access Protocol (LDAP) Bind as a means to authenticate users.

ADFS supports distributed authentication and authorization over the Internet. ADFS can be integrated into an organization's or department’s existing access management solution to translate the terms that are used in the organization into claims that are agreed on as part of a federation. ADFS can create, secure, and verify the claims that move between organizations. It can also audit and monitor the activity between organizations and departments to help ensure secure transactions.

Federation scenarios

ADFS supports federated identity scenarios that use Web Services Federation (WS-Federation), WS-F PRP, and WS-Federation Passive Requestor Interoperability Profile specifications. The ADFS solution helps administrators deal with federated identity management challenges by making it possible for organizations to securely share a user's identity information over federation trusts. The following three descriptions of deployment scenarios illustrate how you can use ADFS server roles to federate identities, depending on the needs of your organization.

Federated Web SSO

The ADFS Federated Web SSO scenario involves secure communication that often spans multiple firewalls, perimeter networks, and name resolution servers, in addition to the entire Internet routing infrastructure. Communication over a federated Web SSO environment can help foster more efficient and secure online transactions between organizations that are joined by federation trust relationships.

As shown in the following illustration, a federation trust relationship can be established between two businesses. In this scenario, federation servers route authentication requests from user accounts in Tailspin Toys to Web-based applications that are located in the network of Online Retailer.

Federated Web SSO scenario

Federation servers authenticate requests from trusted partners based on the credentials of the partners. Representations of the credentials are exchanged in the form of security tokens.

For enhanced security, federation server proxies can be used to relay requests to federation servers that are not directly accessible from the Internet.

Federated Web SSO with Forest Trust

The ADFS Federated Web SSO with Forest Trust scenario involves two Active Directory forests in a single organization, as shown in the following illustration. One of the forests is located in the organization's perimeter network (also known as a demilitarized zone (DMZ) or a screened subnet). The other forest is located in the internal network. A one-way, forest trust is established so that the forest in the perimeter network trusts the forest in the internal network. Federation servers are deployed in both networks. A federation trust is established so that accounts in the internal forest can be used to access a Web-based application in the perimeter network, whether the accounts access the site from the intranet forest or from the Internet.

Federated Web SSO with Forest Trust scenario

In this scenario, external users, such as customers, can access the Web application by authenticating to the external account federation server, which is located in the perimeter network. External users have user accounts in the perimeter-network Active Directory forest. Internal users, such as employees, can also access the Web application by authenticating to the internal account federation server, which is located in the internal network. Internal users have accounts in the internal Active Directory forest.

If the Web-based application is a Windows NT token-based application, the ADFS Web Agent that is running on the Web application server intercepts requests and creates Windows NT security tokens, which are required by the Web application to make authorization decisions. For external users, this is possible because the Web server that hosts the Windows NT® token-based application is joined to the domain in the external forest. For internal users, this is enabled through the forest trust relationship that exists between the perimeter forest and the internal forest.

If the Web-based application is a claims-aware application, the ADFS Web Agent that is running on the Web application server does not have to create Windows NT security tokens for the user. The ADFS Web agent can expose the claims that come across, which allows the application to make authorization decisions based on the contents of the security token that is provided by the account federation server. As a result when it deploys claims-aware applications, the Web server does not have to be joined to the domain, and the external-forest-to-internal-forest trust is not required.

Web SSO

In the ADFS Web SSO scenario, users must authenticate only once to access multiple Web-based applications. In this scenario all users are external, and no federation trust exists. Because the Web servers must be Internet accessible and also joined to the Active Directory domain, they are connected to two networks; that is, they are multihomed. The first network is Internet facing (the perimeter network) to provide the needed connectivity. The second network contains the Active Directory forest (the protected network), which is not directly Internet accessible. The federation server proxy is also multihomed to provide the necessary connectivity to the federation server and the Internet. In this scenario, placing the federation server on a network that is not directly accessible from the Internet greatly reduces the risk to the federation server.

Web SSO scenario

Partner organizations

When you plan for cross-organizational (federation-based) collaboration using ADFS, you first determine whether your organization will host a Web resource to be accessed by other organizations across the Internet — or the reverse. This determination affects how you deploy ADFS, and it is fundamental in the planning of your ADFS infrastructure.

For federation scenarios such as Federated Web SSO and Federated Web SSO with Forest Trust (but not the Web SSO scenario), ADFS uses terms such as "account partner" and "resource partner" to help differentiate the organization that hosts the accounts (the account partner) from the organization that hosts the Web-based resources (the resource partner). The term "federation trust" is used in ADFS to characterize the one-way, nontransitive relationship that is established between the account partner and the resource partner.

The following sections explain some of the concepts that are related to account partners and resource partners.

Account partner

An account partner represents the organization in the federation trust relationship that physically stores user accounts in either an Active Directory store or an ADAM store. The account partner is responsible for collecting and authenticating a user's credentials, building up claims for that user, and packaging the claims into security tokens. These tokens can then be presented across a federation trust to access Web-based resources that are located in the resource partner organization.

In other words, an account partner represents the organization for whose users the account-side Federation Service issues security tokens. The Federation Service in the account partner organization authenticates local users and creates security tokens that are used by the resource partner in making authorization decisions.

In relation to Active Directory, the account partner in ADFS is conceptually equivalent to a single Active Directory forest whose accounts need access to resources that are physically located in another forest. Accounts in this example forest can access resources in the resource forest only when an external trust or forest trust relationship exists between the two forests and the resources to which the users are trying to gain access have been set with the proper authorization permissions.

noteNote
This analogy is meant strictly to emphasize how the relationship between account and partner organizations in ADFS is similar, in concept, to the relationship between an account forest and a resource forest in Active Directory. External trusts and forest trusts are not required for ADFS to function.

Resource partner

A resource partner is the second organizational partner in the federation trust relationship. A resource partner is where the Web servers that host one or more Web-based applications (the resources) reside. The resource partner trusts the account partner to authenticate users. Therefore, to make authorization decisions, the resource partner consumes the claims that are packaged in security tokens coming from users in the account partner.

In other words, a resource partner represents the organization whose Web servers are protected by the resource-side Federation Service. The Federation Service at the resource partner uses the security tokens that are produced by the account partner to make authorization decisions for Web servers that are located in the resource partner.

To function as an ADFS resource, Web servers in the resource partner organization must have the ADFS Web Agent component of ADFS installed. Web servers that function as an ADFS resource can host either claims-aware applications or Windows NT token-based applications.

noteNote
If the application that is hosted on the Web server is a Windows NT token–based application, a resource account may be required for the Active Directory forest in the resource partner organization.

In relation to Active Directory, the resource partner is conceptually equivalent to a single forest whose resources are made available over an external trust or forest trust relationship to accounts that are physically stored in another forest.

noteNote
This analogy is meant strictly to emphasize how the relationship between account and partner organizations in ADFS is similar, in concept, to the relationship between an account forest and a resource forest in Active Directory. External trusts and forest trusts are not required for ADFS to function.

Enhanced identity privacy

Enhanced identity privacy is an optional setting that can be configured on a resource partner in the trust policy. If the Enhanced identity privacy option is enabled, this setting hashes the user-name portion of outgoing UPN claims and e-mail claims. It substitutes the common name with a random value.

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. This setting creates a unique hash per partner so that identity claim values are different across different trusting realm partners but consistent across sessions for a single partner.

  • Simple dictionary attacks against the hash by salting the user value with data that is in the trust policy — data that is not known by the resource partners.

How enhanced identity privacy works

If the Enable enhanced identity privacy setting is enabled, 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. Therefore, the resulting transformed identity will be the same when the following values are the same:

  • Privacy key

  • Resource partner URI

  • Identity claim (user principal name (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.

ADFS server roles

ADFS can operate only when the servers running Windows Server 2003 R2 are configured appropriately. Depending on the environment in your organization, specific ADFS server roles must be deployed. The following sections describe the server roles that can be used to provide an ADFS federated identity management solution.

Federation server

Federation servers host the Federation Service component of ADFS. They are used to route authentication requests that are made from user accounts in other organizations (in Federated Web SSO scenarios) or from clients that can be located anywhere on the Internet (in the Web SSO scenario).

Federation servers also host a security token service that issues tokens that are based on the credentials (for example, user name and password) that are presented to it. After the credentials are verified (by the user logging on), claims for the user are collected through examination of the attributes for the user that are stored in Active Directory or ADAM.

In Federated Web SSO scenarios, claims can then be modified by claim mappings for a specific resource partner. The claims are built into a token that is sent to a federation server in the resource partner. After a federation server in the resource partner receives the claims as incoming claims, it maps them into their organization claims. The organization claims are then built into a new token that is sent to the ADFS Web Agent.

The role that a federation server plays in either of the Federated Web SSO scenarios (Federated Web SSO or Federated Web SSO with Forest Trust) can depend on whether your organization is designated as the account partner or the resource partner:

  • Federation servers in the account partner are used to log on local user accounts in either an Active Directory store or an ADAM store. Federation servers also issue initial security tokens that the local user accounts can use to access Web-based applications that are hosted in the resource partner. In addition, federation servers in the account partner issue cookies to users to maintain login status. These cookies include claims for those users. These cookies enable SSO capabilities so that users do not have to enter credentials each time that they visit different Web-based applications in the resource partner.

  • Federation servers at the resource partner validate the security tokens that are issued by the federation servers at the account partner. Federation servers at the resource partner also issue security tokens that are meant for the Web-based applications in the resource partner. In addition, federation servers in the resource partner issue cookies to the user accounts, which come from the account partner. These cookies enable SSO capabilities so that users do not have to log in again at their federation servers in the account partner when users attempt to access different Web-based applications at the resource partner.

Federation server proxy

Federation server proxies host the Federation Service Proxy component of ADFS. Federation server proxies can be deployed in an organization's perimeter network (also known as a DMZ or a screened subnet) to forward requests to federation servers that are not accessible from the Internet.

noteNote
Although you can deploy separate servers to host the Federation Service Proxy component, it is not necessary to deploy a separate server to act as a federation server proxy in the intranet forest of either the account partner or the resource partner. A federation server performs this role automatically.

The role that a federation server proxy plays in your organization can depend on whether your organization is the account partner or the resource partner:

  • Federation server proxies at the account partner act as proxies for user logons to federation servers that are located in the intranet. Federation server proxies also act as proxies for security tokens that are issued by the account partner federation server for both its own tokens and those tokens that are destined for resource partners.

  • Federation service proxies in the resource partner act as proxies for user security tokens, which are issued from federation servers in both the account partner and the resource partner, to Web-based applications in the resource partner.

Web server

In ADFS, Web servers in the resource forest host the ADFS Web Agent component to provide secure access to the Web applications that are hosted on those Web servers. The ADFS Web Agent manages security tokens and authentication cookies that are sent to a Web server. The Web server requires a relationship with a Federation Service so that all authentication tokens come from that Federation Service.

The ADFS Web Agent supports two types of applications: claims-aware applications and Windows NT token–based applications.

Federation trusts

You can use ADFS to enable efficient and secure online transactions between partner organizations that are joined by federation trust relationships. In other words, a federation trust is the embodiment of a business-level agreement or partnership between two organizations.

As shown in the following illustration, you can establish federation trust relationships between two partner organizations when both of the organizations deploy at least one ADFS federation server and they configure their Federation Service settings appropriately. The one-way arrow signifies the direction of the trust, which — like the direction of Windows trusts — always points to the account side of the forest. This means that authentication flows from the account partner organization to the resource partner organization.

Federation trust linking partner organizations
noteNote
No communication occurs over the network between the account Federation Service and the resource Federation Service.

After you create the federation trust, users who are located in the account partner organization can send authentication requests successfully through the federation trust to the Web server in the resource partner organization. A federation trust is created when the account partner organization and the resource partner organization both install the Federation Service component of ADFS and they both use the Active Directory Federation Services snap-in to configure the account partner and resource partner appropriately.

If one side of a federation trust (either the account partner or the resource partner) is not configured or if it is configured incorrectly by the administrator for either organization, the federation trust will not be created successfully. For detailed guidance about how to create federation trusts, look for ADFS step-by-step or deployment content on the ADFS home page (http://go.microsoft.com/fwlink/?LinkId=79542).

noteNote
Federation trusts are not used in the Web SSO scenario.

Federation Service

The Federation Service is a component of ADFS that can be installed independently from other ADFS components. The Federation Service functions as a security token service. The act of installing the Federation Service component on a computer makes that computer a federation server. It also makes the Active Directory Federation Services snap-in available in the Administrative Tools menu on that computer.

The Federation Service is designed to use Active Directory to provide tokens in response to requests for security tokens. This enables Active Directory domains and forests to function as:

  • Identity providers that can federate with compliant account partners and resource partners. As an identity provider, the Federation Service can project Active Directory identities across the Internet to interact with applications at compliant service providers.

  • Service providers that can federate with compliant account partners and resource partners. As a service provider, the Federation Service can allow identities from other organizations to access a partner's Windows-based and Microsoft ASP.NET-based applications.

  • Security token providers for applications that are compliant with the WS-F PRP specification.

As an account partner, the Federation Service allows Active Directory users to access resources at partner organizations. In response to a request from a resource partner, the Federation Service collects and verifies user credentials against Active Directory or ADAM. The Federation Service can then populate a set of organization claims based on the LDAP attributes of the user account. The organization claims are then mapped to appropriate claims for the resource partner and packaged into a security token that is signed by the Federation Service’s token-signing certificate. The resultant security token is posted as the response to the resource partner’s original request. The resource partner then uses the token to allow access for the user.

As a resource partner, the Federation Service plays the opposite role. When a user attempts to access an ADFS-protected application, the Federation Service determines which account partner should authenticate the user. It then sends an authentication request to that partner. When the user returns with a security token, the Federation Service verifies that the token has been correctly signed by the partner. It then extracts the claims from the token. The claims are mapped to organization claims, and the filtering policy for the specific application is applied. The filtered organization claims are packaged into a security token that is either signed by the Federation Service’s token-signing certificate or protected by a Kerberos session key for the Web application. The resultant security token is posted back to the original application Uniform Resource Locator (URL). The application then uses the token to allow access for the user.

ADFS uses the WS-F PRP protocol to carry claims in security tokens that are issued by the Federation Service to the Web application.

These claims are populated initially from account stores, either Active Directory or ADAM account stores. The Federation Service issues tokens based on the credentials that are presented. After the credentials are verified using the account store, the claims for the user are generated according to the rules of the trust policy. The obtained inbound claims are mapped into outbound claims that are appropriate for a resource partner. The resulting claim mappings are added to a security token that is issued to the resource partner.

After the token is verified, an authentication cookie is issued and written to the client browser. Each time that the client needs to be authenticated, this cookie is used by the Federation Service so that the client does not have to enter credentials again, thereby enabling SSO.

Federation Service Web pages

The Federation Service provides a Web page that prompts the user to select an appropriate account partner to which the user can authenticate. The Federation Service also provides a Web page that prompts for the user’s credentials, such as a user name and password for forms-based authentication. A Web page is also provided that supports Windows Integrated Authentication.

Behind the Web pages, the Federation Service provides an ASP.NET Web service that processes requests from the client or the federation server proxy. The federation server proxy is located in the perimeter network. It acts as an intermediary between an Internet client and a Federation Service in the intranet. There are two basic types of requests to which the Federation Service responds:

  • Requests to issue security tokens

  • Requests to retrieve trust policy data

Account partner discovery

Account partner discovery is the process by which a client can identify what account partner it prefers for authentication in the event that more than a single account partner is configured. The Federation Server presents this choice to the client browser as a drop box containing the account partner names as they are configured in the trust policy.

One mechanism that you can use to avoid account partner discovery is to include the whr parameter in the query string for the resource being accessed, for example,

https://webserver/testapp/testpage.aspx?whr=urn:federation:< accountpartner>, where <accountpartner> indicates the account partner realm of the client.

When the whr parameter is used, the Web server removes the parameter and writes a cookie to the client browser to remember this setting for future requests. Then, the request proceeds in the same way as if it had not been provided.

Federation Service Proxy

The Federation Service Proxy is a component of ADFS in Windows Server 2003 R2 that can be installed independently from other ADFS components. The Federation Service Proxy functions as a proxy in a perimeter network (also known as a DMZ or a screened subnet) for the Federation Service. The act of installing the Federation Service Proxy component on a computer makes that computer a federation server proxy. It also makes the Active Directory Federation Services snap-in available on that computer in the Administrative Tools menu.

A federation server proxy participates in the WS-F PRP protocol by communicating with a protected Federation Service on the client’s behalf. When the federation server proxy is protecting an account partner, it collects user credential information from browser clients. When the federation server proxy is protecting a resource partner, it relays requests by and for Web applications to the Federation Service.

The federation server proxy also stores Hypertext Transfer Protocol (HTTP) cookies on clients when necessary to facilitate SSO. The federation server proxy writes all three types of cookies: authentication cookies, account partner cookies, and sign-out cookies.

ADFS Web Agent

The ADFS Web Agent is a component of ADFS. It is used to consume security tokens and either allow or deny a user access to a Web application. To accomplish this, the Web server requires a relationship with a resource Federation Service so that it can direct the user to the Federation Service as needed.

The ADFS Web Agent can be used for two different types of applications:

  • Claims-aware applications: An ASP.NET application that is written to published ADFS objects that allow the querying of ADFS security token claims. The application makes authorization decisions based on these claims. Security token failures for this type of application result in the client seeing an "Access Denied" message and events in the Federation Service event log.

  • Windows NT token–based applications: An application that uses Windows-based authorization mechanisms. The ADFS Web Agent supports conversion from an ADFS security token to an impersonation-level Windows NT access token.

The Web server also stores HTTP cookies on clients where necessary to facilitate SSO.

Terminology used in ADFS

ADFS uses terminology from several different technologies, including certificate services, Internet Information Services (IIS), Active Directory, ADAM, and Web Services (WS-*). The following table describes these terms.

 

Term Description

account partner

A federation partner that is trusted by the Federation Service to provide security tokens. The account partner issues these tokens to its users (that is, users in the account partner realm) so that they can access Web-based applications in the resource partner.

Active Directory Federation Services (ADFS)

A Windows Server 2003 R2 component that provides Web SSO technologies to authenticate a user to multiple Web applications over the life of a single online session. ADFS accomplishes this by securely sharing digital identity and entitlement rights across security and enterprise boundaries. ADFS in Windows Server 2003 R2 supports the WS-F PRP.

claim

A statement that an issuer makes (for example, name, identity, key, group, privilege, or capability) about a client.

claim mapping

The act of mapping, removing or filtering, or passing claims between various claim sets.

claims-aware application

An ASP.NET application that performs authorization based on the claims that are present in an ADFS security token.

client account partner discovery Web page

The Web page that is used to interact with the user to determine which account partner the user belongs to when ADFS cannot automatically determine which of the account partners should authenticate the user.

client logoff Web page

When ADFS performs a logoff operation, a Web page that is executed to provide visual feedback to the user that the logoff has occurred.

client logon Web page

When ADFS collects client credentials, a Web page that is executed to perform the user interaction. The client logon Web page may use any necessary business logic to determine the type of credentials to collect.

federation

A pair of realms or domains that have established a federation trust.

Federation Service

A security token service that is built into Windows Server 2003 R2. The Federation Service provides tokens in response to requests for security tokens.

Federation Service Proxy

A proxy to the Federation Service in the perimeter network (also known as a DMZ or a screened subnet). The Federation Service Proxy uses WS-F PRP protocols to collect user credential information from browser clients and Web applications and send the information to the Federation Service on their behalf.

organization claims

Claims in intermediate or normalized form within an organization's namespace.

passive client

An HTTP browser, capable of broadly supported HTTP, that can make use of cookies. ADFS in Windows Server 2003 R2 supports only passive clients, and it adheres to the WS-F PRP specification.

resource partner

A federation partner that trusts the Federation Service to issue claims-based security tokens. The resource partner contains published Web-based applications that users in the account partner can access.

security token

A cryptographically signed data unit that expresses one or more claims.

security token service (STS)

A Web service that issues security tokens. An STS makes assertions based on evidence that it trusts, to whoever trusts it (or to specific recipients). To communicate trust, a service requires proof, such as a signature, to prove knowledge of a security token or set of security tokens. A service itself can generate tokens or it can rely on a separate STS to issue a security token with its own trust statement. This forms the basis of trust brokering. In ADFS, the Federation Service is an STS.

server farm

In ADFS, a collection of load-balanced federation servers, federation server proxies, or Web servers hosting the ADFS Web Agent.

single sign-on (SSO)

An optimization of the authentication sequence to remove the burden of repeated logon actions by an end user.

token-signing certificate

An X509 certificate whose associated public/private key pair is used to provide integrity for security tokens.

Uniform Resource Identifier (URI)

A compact string of characters that identifies an abstract resource or physical resource. URIs are explained in RFC 2396 (http://go.microsoft.com/fwlink/?LinkId=48289). In ADFS, URIs are used to uniquely identify partners and account stores.

Web Services (WS-*)

The specifications for a Web Services Architecture that is based on industry standards such as Simple Object Access Protocol (SOAP); XML; Web Service Description Language (WSDL); and Universal Description, Discovery, and Integration (UDDI). WS-* provides a foundation for delivering complete, interoperable business solutions for the extended enterprise, including the ability to manage federated identity and security.

The Web services model is based on the idea that enterprise systems are written in different languages, with different programming models, which run on and are accessed from many different types of devices. Web services are a means of building distributed systems that can connect and interact with one another easily and efficiently across the Internet, regardless of what language they are written in or what platform they run on.

Web Services Security (WS-Security)

A series of specifications that describes how to attach signature and encryption headers to SOAP messages. In addition, WS-Security describes how to attach security tokens, including binary security tokens such as X.509 certificates and Kerberos tickets, to messages. In ADFS, WS-Security is used when Kerberos signs security tokens.

Windows NT token–based application

A Windows application that relies on a Windows NT token to perform authorization of users.

WS-Federation

A specification that defines a model and set of messages for brokering trust and the federation of identity and authentication information across different trust realms.

The WS-Federation specification identifies two sources of identity and authentication requests across trust realms: active requestors, such as SOAP-enabled applications, and passive requestors, which are defined as HTTP browsers capable of supporting broadly supported HTTP, for example, HTTP 1.1.

WS-Federation Passive Requestor Profile (WS-F PRP)

An implementation of the WS-Federation specification that proposes a standard protocol for how passive clients (such as Web browsers) apply the federation framework. Within this protocol, Web service requestors are expected to understand the new security mechanisms and be capable of interacting with Web service providers.

ADFS resources

You can find detailed documentation about Active Directory Federation Services (ADFS) on the ADFS home page (http://go.microsoft.com/fwlink/?LinkId=79542).

For more information about ADFS or for other ADFS-related information, see the following Web resources:

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft