My friends, soon we all should start to prepare to the “ADFS time”.
ADFS = my company Microsoft is a partner with Pyramid. Pyramid employees need access to one of my applications, so we create a federated trust between my application and their user store, so they can log into my application using their internal Active Directory.
So how will it affect us? read the follows:
Understanding what Windows Identity Foundation and ADFS v2 will do is very important. In order to take claims based identity from an idea to a reality means that there are some elements that have to be present. First, the STS must be in place so that tokens can be received. Developers need to have claims aware applications that are able to receive those tokens and use the claims within them. It doesn’t make sense though for all of the developers out there to have to write new code. Instead what will work is a basic and standardized approach to be used for all of them. The difference here though is that the AD FS v2 is in place as an STS. CardSpace is the identity selector. The application itself, SharePoint, is using Windows Identity Foundation. We are going to cover these three types of technology in much more detail later on. Yet it is a good idea to familiarize yourself with them at this point.
AD FS v2 offers support for browsers as well as for clients, encouraging both the WS Federation and the SAML 2.0 protocol. This means it can cover a wide range of different environments and it can be used by just about every identity provider. It won’t matter if it is internal for a business, external on the cloud, or for both of them. It is important to take note that with claims based identity you won’t have to use AD FS v2 as a requirement, it is optional. The STS can come from any vendor including one that you build and operate yourself.
However, the goal of Microsoft is to offer AD FS v2 as a way to get an STS built on AD DS that has all the features you will need.
You may have heard of CardSpace from Microsoft previously, and this is the updated version of it. You will be happy to hear that this particular identity selector is able to be used with a variety of web browsers. It definitely is compliant with the two major ones – Internet Explorer and Firefox. There must be an STS in place for claims based identity to work. However, it can work effectively without any identity selector in place. The problem though is that if you don’t have CardSpace in place or something comparable to it then there is no way for the application to know which identity that you want to use. Based upon that information it just makes good sense that you have an identity selector in place when you are talking about claims based identity. The card will be associated with a given identity as well as a particular provider. When you click on a given card, CardSpace is going to request a token for it from the provider. This is why a user may be asked for a password or other information that is used to authenticate the request. The software will then take those tokens and exchange them for claims. This is all going on behind the scenes. When you are talking about Windows applications, there is another element of claims-based identity that has to be present. This is the Windows Identity Foundation that I mentioned.
This offers a complete function library including getting a token, verifying who is requesting the token, accessing the claims of a token, and much more. Sometimes a AD FS v2 STS won’t be adequate and the Windows Identity Foundation can be leveraged offering additional support custom creation STS. AD FS v2 is actually built on the Windows Identity Foundation. This realization is important because it means the interactions that occur have to be standard in nature. AD FS v2 doesn’t need CardSpace and vice versa. Both of them can function without the use of the Windows Identity Foundation. This is because when CardSpace is looking at the AD FS v2 it will see an STS requesting tokens through the WS-Trust protocol.