I have been trying to read on ADFS nowadays. It’s my new area of interest! :) Wrote a document at work sort of explaining it to others, so here’s bits and pieces from that.
What does Active Directory Federation Services (ADFS) do?
Typically when you visit a website you’d need to login to that website with a username/ password stored on their servers, and then the website will give you access to whatever you are authorized to. The website does two things basically – one, it verifies your identity; and two, it grants you access to resources.
It makes sense for the website to control access, as these are resources with the website. But there’s no need for the website to control identity too. There’s really no need for everyone who needs access to a website to have user accounts and passwords stored on that website. The two steps – identity and access control – can be decoupled. That’s what ADFS lets us do.
With ADFS in place, a website trusts someone else to verify the identity of users. The website itself is only concerned with access control. Thus, for example, a website could have trusts with (say) Microsoft, Google, Contoso, etc. and if a user is able to successfully authenticate with any of these services and let the website know so, they are granted access. The website itself doesn’t receive the username or password. All it receives are “claims” from a user.
What are Claims?
A claim is a statement about “something”. Example: my username is ___, my email address is ___, my XYZ attribute is ___, my phone number is ____, etc.
When a website trusts our ADFS for federation, users authenticate against the ADFS server (which in turn uses AD or some other pool to authenticate users) and passes a set of claims to the website. Thus the website has no info on the (internal) AD username, password, etc. All the website sees are the claims, using which it can decide what to do with the user.
Claims are per trust. Multiple applications can use the same trust, or you could have a trust per application (latter more likely).
All the claims pertaining to a user are packaged together into a secure token.
What is a Secure Token?
A secure token is a signed package containing claims. It is what an ADFS server sends to a website – basically a list of claims, signed with the token signing certificate of the ADFS server. We would have sent the public key part of this certificate to the website while setting up the trust with them; thus the website can verify our signature and know the tokens came from us.
Relying Party (RP) / Service Provider (SP)
Refers to the website/ service who is relying on us. They trust us to verify the identity of our users and have allowed access for our users to their services.
I keep saying “website” above, but really I should have been more generic and said Relying Party. A Relying Party is not limited to a website, though that’s how we commonly encounter it.
Note: Relying Party is the Microsoft terminology.
ADFS cannot be used for access to the following:
- File shares or print servers
- Active Directory resources
- Exchange (O365 excepted)
- Connect to servers using RDP
- Authenticate to “older” web applications (it needs to be claims aware)
A Relying Party can be another ADFS server too. Thus you could have a setup where a Replying Party trusts an ADFS service (who is the Claims Provider in this relationship), and the ADFS service in turn trusts a bunch of other ADFS servers depending on (say) the user’s location (so the trusting ADFS service is a Relying Party in this relationship).
Claims Provider (CP) / Identity Provider (IdP)
The service that actually validates users and then issues tokens. ADFS, basically.
Note: Claims Party is the Microsoft terminology.
Secure Token Service (STS)
The service within ADFS that accepts requests and creates and issues security tokens containing claims.
Relying Party Trust
Refers to the trust between a Relying Party and Identity Provider. Tokens from the Identity Provider will be signed with the Identity Provider’s token signing key – so the Relying Party knows it is authentic. Similarly requests from the Relying Party will be signed with their certificate (which we can import on our end when setting up the trust).
Examples of setting up Relying Party Trusts: 1 and 2.
Web Application Proxy (WAP)
Access to an ADFS server over the Internet is via a Web Application Proxy. This is a role in Server 2012 and above – think of it as a reverse proxy for ADFS. The ADFS server is within the network; the WAP server is on the DMZ and exposed to the Internet (at least port 443). The WAP server doesn’t need to be domain joined. All it has is a reference to the ADFS server – either via DNS, or even just a hosts file entry. The WAP server too contains the public certificates of the ADFS server.
Miscellaneous
- ADFS Federation Metadata – this is a cool link that is published by the ADFS server (unless we have disabled it). It is
https://<your-adfs-fqdn>/FederationMetadata/2007-06/FederationMetadata.xml and contains all the info required by a Replying Party to add the ADFS server as a Claims Provider.
- This also includes Base64 encoded versions of the token signing certificate and token decrypting certificates.
- SAML Entity ID – not sure of the significance of this yet, but this too can be found in the Federation Metadata file. It is usually of the form
http://<your-adfs-fqdn>/adfs/services/trust and is required by the Relying Party to setup a trust to the ADFS server.
- SAML endpoint URL – this is the URL where users are sent to for authentication. Usually of the form
http://<your-adfs-fqdn>/adfs/ls. This information too can be found in the Federation Metadata file.
- Link to my post on ADFS Certificates.
