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:
- User accesses PHP application (Service Provider)
- App redirects to ADFS (Identity Provider)
- User authenticates against Active Directory
- ADFS issues SAML assertion
- Assertion is posted back to PHP app
- 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 |
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:
- Internal-only: Behind corporate firewall with VPN access
- 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