Microsoft ADFS service is widely used for integrating Web Applications with Microsoft Active Directory.
Since Windows Server 2012 R2, it can also integrate Non-Claims-Aware applications.
This configuration is very interesting because ADFS can still be the single point of user authentication, and the whole configuration is much easier as a Claims one.
The whole architecture is very similar to the one for Claim-Based authentication (see my previous Blog entry): it requires at least one Web Application Proxy (previously named ADFS Proxy) and one ADFS Server. The latter can be hosted on the Domain Controller itself.
There is only one drawback: the Web Application Proxy server MUST be Active Directory Domain Joined, too.
This requirement is due to the fact that a Web Application Proxy server needs to impersonate the user and perform a Kerberos authentication towards the published Web Application.
The whole backend authentication scheme must be based on Kerberos, as this is the only kind of authentication supported by ADFS for Non-Claims Apps.
Each Web Application has to publish a Kerberos SPN (Service Principal Name) in Active Directory, and the Web Application Proxy server must be able to perform Kerberos Constrained Delegation, so that it can impersonate the user when accessing the Web Application.
A user coming from the Internet can still get a Claim with his identity: this claim is contained in a digitally signed Token (SAML Token), which will be used in accessing the entire suite of Web Applications, Claims Aware and not.
A user will still need to authenticate once with the Web Application Proxy server.
When accessing a Non-Claims-Aware web application, the Web Application Proxy server has to convert the user SAML Token into a Kerberos one, although the user is not aware of this change.
Users coming from the internal network don’t need to authenticate themselves towards ADFS: they can perform direct authentication towards the Web Application using Kerberos or NTLM authentication.
EriZone and NetEye servers can be easily integrated into your Active Directory Kerberos architecture with a keytab file.
A keytab is used in situations on mixed networks, where Microsoft Active Directory Domain is the KDC (Key Distribution Center) providing enterprise directory services for a heterogeneous network comprised of both Windows and non-Windows systems (such as Linux and Java-based application servers), and where it is desirable that AD users accessing some service (for example, HTTP) on a non-Windows system can be silently authenticated (not challenged for credentials) in that system using their AD username. Since such a system might not participate in the AD domain in any other way, there must be some common authentication mechanism to allow this process to work. The Kerberos single sign-on (SSO) protocol accomplishes this task. Kerberos SSO from Linux and Java-based systems to Active Directory is accomplished via multiple components, such as SPNEGO, GSSAPI, the SPN (Service Principal Name), and the keytab.
In this configuration, EriZone and NetEye servers can be accessed with SSO through ADFS as Non-Claims-Aware applications.
The Kerberos authentication protocol is very powerful and can be used with complex architectures.
User impersonation performed by the Web Application Proxy can also extend to backend servers: for example, the Web Application can access a backend Reporting Services module, which takes data from a backend MS SQL Server.
Kerberos is able to manage this authentication propagation without requiring the user to authenticate himself again.