Building Identity Federation With Saml Azure AdSAFE

817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains ·

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: building-identity-federation-with-saml-azure-ad
description: Configure SAML 2.0 identity federation between on-premises Active Directory (via AD FS or a third-party IdP) and Microsoft Entra ID, covering federation models (AD FS, password hash sync, pass-through auth, third-party IdP) and the SAML authentication flow. Use when extending on-premises authentication authority to cloud resources or designing hybrid identity SSO architecture for Entra ID.
domain: cybersecurity
subdomain: identity-access-management
tags:
- saml
- azure-ad
- entra-id
- federation
- identity
- sso
- adfs
- hybrid-identity
version: '1.0'
author: mahipal
license: Apache-2.0
nist_csf:
- PR.AA-01
- PR.AA-02
- PR.AA-05
- PR.AA-06
mitre_attack:
- T1606.002
- T1556.007
- T1484.002
- T1078.004
- T1110.003
mitre_f3:
  version: '1.1'
  tactics:
  - initial-access
  - positioning
  techniques:
  - id: F1006
    name: Account Takeover
    tactic: initial-access
    source: f3
  - id: F1006.002
    name: 'Account Takeover: Exposed Login Credential'
    tactic: initial-access
    source: f3
  - id: T1110.003
    name: 'Brute Force: Password Spraying'
    tactic: initial-access
    source: attack
  - id: T1550
    name: Use Alternate Authentication Material
    tactic: initial-access
    source: attack
  - id: F1004
    name: Access with Stolen Session Cookie
    tactic: initial-access
    source: f3
---

# Building Identity Federation with SAML Azure AD

## Overview

Identity federation enables users authenticated by one identity provider to access resources managed by another without maintaining separate credentials. This skill covers establishing SAML 2.0 federation between an organization's on-premises Active Directory (via AD FS or third-party IdP) and Microsoft Entra ID (formerly Azure AD), as well as configuring federated SSO for third-party SaaS applications. Federation eliminates password synchronization concerns and keeps authentication authority on-premises while extending SSO to cloud resources.


## When to Use

- When deploying or configuring building identity federation with saml azure ad capabilities in your environment
- When establishing security controls aligned to compliance requirements
- When building or improving security architecture for this domain
- When conducting security assessments that require this implementation

## Prerequisites

- On-premises Active Directory domain
- AD FS 2019+ or third-party SAML IdP (Okta, Ping, etc.)
- Microsoft Entra ID tenant (P1 or P2 license recommended)
- Azure AD Connect (if using hybrid identity with password hash sync as backup)
- Public TLS certificate for federation endpoint
- DNS records for federation service name

## Core Concepts

### Federation Models

| Model | Authentication Authority | Use Case |
|-------|------------------------|----------|
| Federated (AD FS) | On-premises AD FS | Regulatory requirement to keep auth on-prem |
| Managed (PHS) | Azure AD with password hash sync | Simplest cloud auth, AD FS not needed |
| Managed (PTA) | On-premises via pass-through agent | Cloud auth validated against on-prem AD |
| Third-Party Federation | External IdP (Okta, Ping) | Multi-IdP environment |

### SAML Federation Architecture

```
User → Cloud App (SP)
   │
   └── Redirect to Azure AD
          │
          ├── Azure AD checks federated domain
          │
          └── Redirect to on-premises AD FS
                 │
                 ├── AD FS authenticates against Active Directory
                 │
                 ├── AD FS issues SAML token
                 │
                 └── Token posted back to Azure AD
                        │
                        ├── Azure AD validates federation trust
                        │
                        ├── Azure AD issues its own token
                        │
                        └── User receives access token for cloud app
```

### Federation Trust Components

| Component | Description |
|-----------|-------------|
| Token-Signing Certificate | X.509 certificate used by IdP to sign SAML assertions |
| Federation Metadata | XML document describing IdP endpoints and capabilities |
| Relying Party Trust | Configuration in AD FS for each SP (Azure AD) |
| Claims Rules | Transform AD attributes into SAML claims |
| Issuer URI | Unique identifier for the IdP (entity ID) |

## Workflow

### Step 1: Prepare AD FS Infrastructure

```powershell
# Install AD FS role
Install-WindowsFeature ADFS-Federation -IncludeManagementTools

# Configure AD FS farm
Install-AdfsFarm `
    -CertificateThumbprint $certThumbprint `
    -FederationServiceDisplayName "Corp Federation Service" `
    -FederationServiceName "fs.corp.example.com" `
    -ServiceAccountCredential $gmsaCredential

# Verify AD FS is operational
Get-AdfsProperties | Select-Object HostName, Identifier, FederationPassiveAddress
```

### Step 2: Configure Azure AD Federated Domain

```powershell
# Install Microsoft Graph PowerShell module
Install-Module Microsoft.Graph -Scope CurrentUser

# Connect to Microsoft Graph
Connect-MgGraph -Scopes "Domain.ReadWrite.All"

# Convert managed domain to federated
# Using AD FS federation metadata URL
$domainId = "corp.example.com"
$federationConfig = @{
    issuerUri = "http://fs.corp.example.com/adfs/services/trust"
    metadataExchangeUri = "https://fs.corp.example.com/adfs/services/trust/mex"
    passiveSignInUri = "https://fs.corp.example.com/adfs/ls/"
    signOutUri = "https://fs.corp.example.com/adfs/ls/?wa=wsignout1.0"
    signingCertificate = $base64Cert
    preferredAuthenticationProtocol = "saml"
}

# Apply federation settings to domain
New-MgDomainFederationConfiguration -DomainId $domainId -BodyParameter $federationConfig
```

### Step 3: Configure AD FS Claims Rules

```powershell
# Add Relying Party Trust for Azure AD
Add-AdfsRelyingPartyTrust `
    -Name "Microsoft Office 365 Identity Platform" `
    -MetadataUrl "https://nexus.microsoftonline-p.com/federationmetadata/2007-06/federationmetadata.xml"

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

declared (3 observation(s))

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (1)

cert_der = base64.b64decode(cert_base64)

Gates applied: no_behavioural_pass.