WS-Security provides a core function by defining mechanisms for assuring message authenticity, integrity and confidentiality through the use of security tokens.
WS-SecurityPolicy enables the description of the security requirements of services via assertions about the security mechanisms of the services (i.e. algorithms and types of tokens that the service accepts). Using these assertions web services are able to recognize and assess the types of security tokens and claims that are required for exchanging messages securely.
WS-Trust provides an additional piece of the foundation for federation by defining a service model, the Security Token Service (STS), and a protocol for requesting/issuing these security tokens which are used by WS-Security and described by WS-SecurityPolicy.
A fundamental goal of WS-Federation is to simplify the development of federated services through cross-realm communication and management of Federation Services by re-using the WS-Trust Security Token Service model and protocol.
WS-Federation does not restrict users to a specific security token format. Instead, WS-Federation builds on the WS-Trust encapsulation mechanism, the RST/RSTR, which allows protocol processing to remain agnostic of the type of token being transmitted.
Access to SharePoint Server running in Claims Mode Authentication utilizes
Server that enables access for Windows Integrated Authentication, Form Based Authentication and Trusted Claims Providers (TRUST).
Some service applications require the use of the Windows Identity Foundation (WIF) Claims-to Windows Token Service (C2WTS) to translate claims within the farm to Windows credentials for outbound authentication. It is important to understand that Service Applications that come with SharePoint Server can leverage the C2WTS only if the incoming authentication method is either Classic mode or Windows claims.
A claims provider in SharePoint Server 2010 can be used to augment claims and provide name resolution. By using claims authentication, you can assign rights based on claims without having to know who users are, or how they are authenticated. You only have to know the attributes of the users. You can, for example, use a piece of corporate metadata that is associated with a person and have the claims provider do a lookup to another system to determine the different identities of a particular person—Windows, forms-based authentication, SAP, CRM, and so on—and map another identifier or set of claims to that identity. Those claims are then used to grant access to resources.
Compund Claims augemenation with AND operator
Difference between Windows Claims and SAML Claims
Network load balancer considerations
You need to set network load balancing to single affinity when using claims-based authentication. If you use SAML token-based authentication with AD FS on a SharePoint Server 2010 farm that has multiple Web servers in a load-balanced configuration, there will be an effect on the performance and functionality of client Web-page views. When AD FS provides the authentication token to the client, that token is submitted to SharePoint Server 2010 for each permission-restricted page element. If the load-balanced solution is not using affinity, each secured element is authenticated to more than one SharePoint Server 2010 server, which will result in rejection of the token. After the token is rejected, SharePoint Server 2010 redirects the client to authenticate again back to the AD FS server. After this occurs, an AD FS server will reject multiple requests that are made in a short time period. This behavior is by design, to protect against a denial of service attack. If performance is adversely affected or pages do not load completely, set network load balancing to single affinity. This isolates the requests for SAML tokens to a single Web server.