Securing the ADFS Server
May 16, 2013 Leave a comment
This post will discuss best practice with regards to the general security of your ADFS server.
As recommended by Microsoft, the ADFS server is best placed in a network location that is not directly connected to the internet. This is crucial in maintaining the security of your identity infrastructure, because federation servers have the ability to grant security tokens to any authorised user, and is trusted by the Active Directory domain infrastructure.
From a business point-of-view the federation servers are as important as the domain controller; so in theory they should have the same level of protection. If a federation server is compromised, a ‘hacker’ will have the ability to issue access tokens to all web applications as well as the Relaying Parties they are federated to. As a worst-case this would allow a ‘hacker’ to impersonate any user associated with the Identifying Party.
Typically security would be met by establishing at least an intranet-facing firewall between the corporate network and the internet, or a fully fledged perimeter network with a second firewall placed between the perimeter network and the internet. Either way – keep the federation server not accessible directly to the internet.
For this reason AD FS allows the use of a Federation Server Proxy (FSP) to provide these services without the exposure to the internet.
The FSP, unlike the federation server, does not need to be joined to the AD domain; the FSP is able to remain in a workgroup and as such not have a secure channel to any domain controllers. When you install the FSP, the computer functions as a proxy server in a perimeter network (for example a DMZ).
The FSP accepts the following types of incoming requests from incoming clients (then relayed to the ADFS server);
- WS-Trust RST
- WS-MetadataExchange (MEX)
- WS-Federation Passive
- SAML web SSO
- WS-Federation Metadata
- SAML Metadata
Services are exposed over HTTP/HTTPS, and all client connections terminate at the proxy. Back-end requests are then submitted from the FSP to the internal Federation server over a new connection.
FSP provides the following benefits;
- Security – Isolates requests received on a less-secure network (the Internet or a perimeter network) from the federation server residing on the internal network. The FSP is segregated from direct access to resources such as SQL servers, application servers, or AD Domain Controllers.
- Key Protection – The Federation Server’s token-signing certificate does not reside on the FSP.
FSP maintains a secure connection with a federation server through the use of SSL certificates and the use of an ADFS token.
When you install a federation server, you configure a Uniform Resource Identifier (URI), which identifies the Uniform Resource Locator (URL) the users will be redirected to as the endpoint of communication. These redirections are defined below;
- The web applications at the Relaying Party are configured with the URI of the Relaying Party’s FS.
- The Relying Party’s federation server is configured with a URI for the Identity Provider’s FS.
- The Claims Provider’s federation server is configured with the URI for the Relying Party’s FS.