Introduction
I was involved in an ADFS deployment recently where the customer wanted to restrict access from the Internet to their ADFS proxy servers, located on their DMZ. They used ADFS to federate with Windows Azure Active Directory so they only wanted to allow traffic from the Microsoft Online Security Token Service (STS) servers into their ADFS. The rational behind this was that only a trusted party (Microsoft) should be able to communicate with an externally available service in their network. A good theory, but one doomed to failure. Let me explain why…
The WS-Federation Passive Requestor Profile
ADFS is Microsoft’s implementation of the OASIS group’s WS-* suite of protocols and mechanisms. A complete description of WS-* is way beyond this post, but I will list some resources at the end of this post for the inquisitive among you. One of the purposes of the WS-* standard is to allow:
“different security realms to federate, such that authorized access to resources managed in one realm can be provided to security principals whose identities and attributes are managed in other realms”
In other words, to outsource authentication to somebody else that you trust.
The letters WS stand for Web Service, meaning that WS-* is created to work on the Internet, something e.g. Kerberos is not designed to do. Let’s look at a few pieces of WS-* terminology:
- Requestor
The client that wants access to some resource/content/service. Often a browser. Requestors are broadly split into two groups; those that can emit Web Service messages using SOAP and those that cannot. (Remember this last bit because it is important.) - Relying party (RP)
The content provider that has something that a user wants access to. The RP has delegated the task of authentication to somebody else; the Identity Provider (IdP)/Security token Service (STS). The RP trusts the IdP/STS. In the Windows world an RP is often an IIS server with the Windows Identity Foundation (WIF) framework installed. - Identity Provider (IdP)
A secure storage of identity information that also provides authentication mechanisms, allowing a Security Token Service (STS) to use it to authenticate. Active Directory is ADFS’ IdP. - Security Token Service (STS)
A service that receives authentication requests from clients, authenticates them via its configured IdP, and issues tokens to clients, to be used at the RP. - Trust
A relationship between the RP and the IdP/STS established with digital certificates whereby the RP trusts the IdP/STS.
A browser cannot emit web service requests, i.e. it cannot talk SOAP, so it uses something called the WS-Federation Passive Requestor Profile (PRP). WS-Federation is an extension to the WS-Trust specification that allows requestors that cannot talk SOAP to still exchange security information (tokens). They do this by being passive, meaning they rely on the RP and IdP to tell them what to do.
An implementation of this can look like this:
This is what happens when the passive requestor profile is used to obtain access to a resource:
- The requestor contacts the resource asking for access. The resource is the RP.
- The RP know the requestor’s security realm so it sends an HTTP redirect instructing the requestor to authenticate at its own realm.
- The requestor follows the redirect to its own realm where it is authenticated by its IdP/STS.
- In the request for authentication the requestor has included the URI of the resource it wants to access to. After the IdP/STS has authenticated the requestor, it sends another HTTP redirect back to the original resource. Included with the redirect is also a token, possession of which assures that the user has been authenticated.
- The requestor follows the redirect back to the original resource supplying the token and gains access to the resource.
The most important thing to note here is that when using the Passive Requestor Profile the RP and IdP/STS never need to communicate directly. It is only the requestor that needs to talk to all the involved parties.
Usually the RP is also an IdP/STS. In the case of Windows Azure Active Directory and federation with an on-premise Windows Server Active Directory the WAAD IdP/STS trusts your on-premise IdP/STS. This allows a single trust to be established. If not each RP would have to maintain its own trust with the IdP/STS.
So now that we know how the Passive Requestor Profile works how would this impact my customer’s request to only allow Microsoft’s STS to talk to its ADFS servers?
Security
Answer is that it would break it and no one would be able to access any resource in the Microsoft cloud. As we have seen it is not the WAAD STS that communicates with on-premise ADFS, or the other way around, it is the requestors, i.e. the clients. So restricting access would deny every client access to on-premise ADFS, and thus any resource they want to access. Don’t do that.
Other stuff and more info
The customer had actually started working on this “security improvement” before I got involved and had already discovered IPs they needed to allow. For the curious, the name of the Microsoft STS is login.microsoftonline.com, which is a CNAME that resolves to the A record login.microsoftonline.com.nsatc.net. The A record has several records (I do not know if this is a complete list):
- 157.56.53.213
- 157.56.58.13
To restrict access and always use least privilege is a very good idea, in this case it just backfired because how the system works was not known.
If you want to know more about WS-*, ADFS etc., you can have a look at these resources:
- Windows Identity Foundation 101’s : WS-Federation Passive Requestor Profile (part 1 of 2)
- OASIS Web Services Federation Language Draft
- ADFS Deployment Guide
Be secure!
