ADFS Implementation Guide: Federated Authentication for PHP Applications Using SAML 2.0


2 views

Active Directory Federation Services (ADFS) is Microsoft's standards-based identity federation solution that enables single sign-on (SSO) across organizational boundaries. Unlike traditional LDAP which primarily handles directory services within a single domain, ADFS implements a claims-based authentication model using protocols like SAML 2.0, WS-Federation, and OAuth.

While both handle authentication, they operate fundamentally differently:


// LDAP Authentication (Direct binding)
$ldapconn = ldap_connect("ldap.example.com");
ldap_bind($ldapconn, "cn=user,dc=example,dc=com", "password");

// ADFS Authentication (Claims-based via SAML)
// No direct server binding - uses token exchange

ADFS acts as a Security Token Service (STS) that issues signed tokens containing claims about the user's identity. These tokens can be consumed by applications without needing direct AD access.

A standard SAML 2.0 flow with ADFS involves:

  1. User accesses PHP application (Service Provider)
  2. App redirects to ADFS (Identity Provider)
  3. User authenticates against Active Directory
  4. ADFS issues SAML assertion
  5. Assertion is posted back to PHP app
  6. App validates signature and processes claims

ADFS servers are typically exposed via:

  • ADFS Proxy servers in DMZ (recommended)
  • Direct internet-facing ADFS servers
  • Azure AD as federation proxy

This differs from domain controllers which should never be internet-accessible.

Using simplesamlphp library for ADFS integration:


require_once('simplesamlphp/lib/_autoload.php');
$as = new SimpleSAML_Auth_Simple('default-sp');

if (!$as->isAuthenticated()) {
    $as->requireAuth();
}

$attributes = $as->getAttributes();
echo "Authenticated as: " . $attributes['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name'][0];

// Authorization check example
if (in_array('Manager', $attributes['http://schemas.microsoft.com/ws/2008/06/identity/claims/role'])) {
    // Grant access to manager resources
}

Typical SAML assertions contain:

Claim Type Example URI
Name http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
Email http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
Groups http://schemas.microsoft.com/ws/2008/06/identity/claims/role
  • Always validate SAML response signatures
  • Implement proper audience restriction checks
  • Use encrypted assertions for sensitive data
  • Configure proper token lifetime policies

Active Directory Federation Services (ADFS) is Microsoft's implementation of federated identity using industry standards like SAML 2.0, WS-Federation, and OAuth. Unlike traditional LDAP which handles direct directory queries, ADFS operates as a claims-based identity provider that issues security tokens containing user attributes (claims).

ADFS consists of:

  • Federation Service: The core component that issues and validates tokens
  • ADFS Proxy: Publishes the federation service to external networks
  • Attribute Store: Typically Active Directory that provides user attributes

Here's the typical authentication sequence when a PHP app integrates with ADFS:


1. User accesses PHP application
2. App redirects to ADFS endpoint with SAML AuthnRequest
3. ADFS authenticates user (forms/Kerberos)
4. ADFS returns SAMLResponse to PHP app
5. App validates assertion and extracts claims

Using the popular onelogin/php-saml library:


require_once 'vendor/autoload.php';

$auth = new OneLogin\Saml2\Auth([
    'strict' => true,
    'sp' => [
        'entityId' => 'https://your-php-app.com/saml/metadata',
        'assertionConsumerService' => [
            'url' => 'https://your-php-app.com/saml/acs',
        ],
    ],
    'idp' => [
        'entityId' => 'urn:federation:adfs',
        'singleSignOnService' => [
            'url' => 'https://adfs.yourcompany.com/adfs/ls/',
        ],
        'x509cert' => 'ADFS_SIGNING_CERT'
    ]
]);

if (!isset($_SESSION['samlUserdata'])) {
    $auth->login();
} else {
    $attributes = $_SESSION['samlUserdata'];
    // Process authorization based on claims
}
  • Always validate SAML responses against the ADFS signing certificate
  • Implement proper session timeout handling
  • Map AD groups to application roles via claims rules in ADFS

ADFS servers are typically deployed in two configurations:

  1. Internal-only: Behind corporate firewall with VPN access
  2. Internet-facing: Through ADFS Proxy/WAP servers in DMZ

The proxy configuration enables secure external access without exposing domain controllers.

ADFS can transform directory attributes into claims. A sample claim rule might look like this in PowerShell:


Add-ADFSClaimRule -ClaimRule '@RuleName = "Transform Groups"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", 
Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory", 
types = ("http://schemas.xmlsoap.org/claims/Group"), 
query = ";tokenGroups;{0}", param = c.Value);'
  • Use Fiddler to examine SAML traffic
  • Check ADFS event logs for failed authentications
  • Validate clock synchronization between systems