Identity & Access Management Glossary
Identity Federation - Organisationsübergreifende Identitätsverwaltung
Identity federation enables the secure use of identities across organizational boundaries—without the need for separate accounts. SAML 2.0, OpenID Connect, and WS-Federation are the protocols used. Typical use cases: 'Login with Azure AD,' B2B partner access, and cloud SSO. Security risks arise from incorrect trust configuration, insecure token validation, and overprivileged attributes.
Identity Federation solves the fundamental problem of identity management in distributed systems: How can a user access external resources using their existing corporate identity—without separate passwords, without the hassle of provisioning, and without data duplication?
Comparison of Federation Protocols
SAML 2.0 (Security Assertion Markup Language):
Parties:
Identity Provider (IdP): knows the user (e.g., Microsoft Entra ID)
Service Provider (SP): offers the service (e.g., Salesforce, SAP)
Principal: the user
SAML Flow (SP-initiated, the most common case):
1. User → SP: https://app.example.com/dashboard
2. SP → User (Redirect): SAML AuthnRequest to IdP
3. User → IdP: logs in (SSO session exists → direct)
4. IdP → User (POST-Binding): SAML Response (signed XML assertion)
5. User → SP: forwards SAML Response (browser acts as intermediary!)
6. SP: Verifies signature, issuer, NotBefore/NotOnOrAfter, audience
7. SP → User: Grants access
What a SAML assertion contains:
<saml:Assertion>
<saml:Issuer>https://login.microsoftonline.com/...</saml:Issuer>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
user@firma.de
</saml:NameID>
</saml:Subject>
<saml:Conditions NotBefore="..." NotOnOrAfter="...">
<saml:AudienceRestriction>
<saml:Audience>https://saas-app.com/saml</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AttributeStatement>
<saml:Attribute Name="displayName">
<saml:AttributeValue>John Doe</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="groups">
<saml:AttributeValue>IT Department</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
---
OpenID Connect (OIDC) / OAuth 2.0 Federation:
→ More modern standard, JSON-based (instead of XML)
→ ID token (JWT) instead of SAML assertion
→ Common: "Log in with Google/GitHub/Microsoft"
B2B OIDC Federation (Cross-Tenant):
→ Company A has Entra ID Tenant A
→ Company B has Entra ID Tenant B
→ B2B Direct Federation: Tenant A trusts Tenant B as an IdP
---
WS-Federation:
→ Older Microsoft protocol (ADFS era)
→ Being replaced by SAML/OIDC
→ Still active in legacy environments with ADFSMicrosoft Entra ID Federation (Practical Application)
B2B External Identity (most common enterprise use case):
Scenario: Supplier/partner needs access to SharePoint
Option 1: Entra B2B Collaboration (Guest Account):
→ Admin invites: admin.partner@lieferant.de → becomes a guest in the tenant
→ Partner uses THEIR own credentials (supplier tenant)
→ Entra ID forwards to supplier IdP for authentication
→ No separate password required!
PowerShell:
New-AzureADMSInvitation `
-InvitedUserEmailAddress admin.partner@lieferant.de `
-SendInvitationMessage $true `
-InviteRedirectUrl "https://myorg.sharepoint.com"
Option 2: Direct Federation (SAML/OIDC):
→ Provider has its own IdP (not Entra ID, e.g., Okta, Ping)
→ Configure direct trust relationship
→ Admin: Entra External → Identity Provider → Direct Federation Configuration
→ Required: Partner’s SAML metadata URL or OIDC well-known endpoint
Conditional Access for external identities:
→ Enforce MFA (including for partner accounts!)
→ Compliant device requirement (or not, depending on the scenario)
→ Cross-Tenant Access Policy:
Inbound trust: Recognize partner MFA as your own MFA?
Outbound: What are your own users allowed to view at the partner?
---
Azure AD B2C (Consumer Identity):
→ Business-to-Consumer, not B2B
→ Customer login for own apps via social login
→ Google, Facebook, GitHub as external IdPs
→ Custom Policies (Identity Experience Framework) for complex flowsSAML Federation Security Risks
Common misconfigurations and attacks:
1. XML Signature Wrapping (XSW):
Problem: SP validates only PART of the XML document
Attack: Attacker inserts a second (forged) assertion,
which is unsigned but is "read" by the parser
SAML Response:
<Response>
<Assertion ID="good">
</Assertion>
<Assertion ID="evil"><!-- NICHT signiert! -->
<Subject><!-- Signiert, valide -->attacker@evil.com</Subject>
<Subject>admin@firma.de</Subject>
← SP reads this!</Assertion>
</Response>
Protection:
→ Keep SAML library up to date with security patches
→ Implement XML Canonicalization correctly
→ Always ensure Assertion ID is unique + random
2. SAML Assertion not bound to SP (Audience validation missing):
Problem: A valid assertion from SP-A can be used at SP-B!
Protection: ALWAYS check <Audience>https://NUR-DIESER-SP.com</Audience>
!
3. NotOnOrAfter too large (replay attack):
Problem: Assertion valid for 24 hours → stolen assertion can be reused
Protection: Max. 5 minutes; SP maintains assertion ID cache against replay
4. IdP metadata URL manipulated:
Problem: Attacker changes metadata URL → own IdP
Protection: Manually pin metadata; only HTTPS sources
5. Too many attributes passed:
Problem: IdP sends internal roles/groups to external SP
Protection: Attribute Release Policy – only required attributes
---
OIDC/OAuth Federation Attacks:
→ Sub-Claim Takeover: sub-claim (User-ID) is not unique when switching providers
→ Issuer Confusion: app accepts tokens from any OIDC issuer
Protection: Configure issuer URL statically; do not read from token
→ PKCE Bypass: Authorization code intercepted
Protection: PKCE for all public clients (mandatory since OAuth 2.1)Configuring Federation in Practice
Okta as IdP for G Suite / Google Workspace:
1. Okta: "Google Workspace SAML" app from the app catalog
2. Okta provides: ACS URL, Entity ID, signing certificate
3. Google Admin Console: Security → SSO with 3rd party IdP
Sign-in page URL: https://firma.okta.com/app/google/sso/saml
Certificate: Upload Okta’s public signing certificate
4. Test: Configure admin exception (to avoid locking yourself out!)
5. User: Type google.com → Redirect to Okta → Return with SAML assertion
Shibboleth IdP (open-source, universities):
Configuration: /opt/shibboleth-idp/conf/relying-party.xml
<bean parent="SAML2.SSO" p:signAssertions="true">
<property name="relyingParties">
<list>
<value>https://uni-portal.de/shibboleth</value>
</list>
</property>
</bean>
Attribute resolver (which attributes to which SP?):
relying-party.xml → AttributeFilterPolicy
→ Share eduPerson attributes, NEVER internal roles!
---
Debugging SAML issues:
Browser extension: SAML-tracer (Firefox/Chrome) → View SAML assertion in the browser
Important checks:
✓ Assertion valid (check NotBefore/NotOnOrAfter!)
✓ Audience matches SP Entity ID
✓ NameID format matches
✓ Attribute names exactly correct (case-sensitive!)
✓ Signature certificate not expired
✓ Clock skew < 5 minutes between IdP and SP
