ADFS (1) – Terminologie

  • Article

1 Úvod

V seriálu se budeme věnovat technologii Active Directory Federation Services. Články budou vycházet jednou měsíčně a v prvním díle se seznámíme s terminologií ADFS. Budeme se držet terminologie společnosti Microsoft, v závorce pak terminologie Shibboleth).

2 Teoretický základ

Active Directory Federation Services je implementace protokolu WS-Federation Passive Requestor Profile protokolu (Passive znamená, že požadavky klienta jsou cookie - popis zde) od společnosti Microsoft do služby, poskytující sdílení informací o identitách mezi důvěryhodnými partnery přes nedůvěryhodné sítě (extranet, Internet atd.). ADFS ke komunikaci využívá protokol HTTP a HTTPS na portech 80, 443. Informace se vyměňují přes Security Assertion Markup Language (SAML).

Smyslem ADFS je umožnit identitě z organizace A přistoupit ke zdrojům z organizace B bez nutnosti vytvářet pro identitu A další identitu v organizaci B. ADFS zajišťuje autentizaci a autorizaci identity v organizaci B tím, že požadavek na autentizaci a autorizaci pošle do organizace A, kde se požadavek vyhodnotí a do organizace B putuje Claim, který v sobě obsahuje potřebné údaje o tom, zda identita A může ke zdrojům v organizaci B přistoupit. Identita A se tedy autentizuje a autorizuje ve své domácí organizaci A, ADFS pak zajistí vystavení a bezpečný přesun Claimu do organizace B, kde se Claim použije.

3 Terminologie

V této kapitole si vysvětlíme jednotlivé termíny, abychom je mohli následně použít v dalších dílech seriálu o ADFS.

SAML – Security Markup Assertion Language – je otevřený datový formát, založený na XML, který zaštiťuje OASIS (odkaz na OASIS), pro výměnu informací o autentizaci a autorizaci mezi organizacemi. Technicky jde o výměnu informací mezi Identity providerem a Service providerem (viz dále). SAML je jedna z možností, jak zajistit Web Single Sign On (Web SSO), další možností je například OpenID nebo Shibboleth, které v tomto seriálu nebudeme popisovat. Popisu SAML je na internetu k nalezení spousta. My budeme potřebovat následující:

  • Ke dnešnímu datu jsou 3 verze SAML
  • SAML 1.0
  • SAML 1.1
  • SAML 2.0
  • Vznikl v roce 2005
  • Nejnovější specifikace SAML (z roku 2012)
  • Není kompatibilní s předchozími verzemi SAML (1.0 a 1.1)

SAML definuje 3 komponenty:

  • Protokol
  • Definuje, jak SAML odesílá a přijímá Security Tooken (*Assertion)
  • Security Token (*Assertion) (tvrzení)
  • XML dokument posílaný přes Federation request popisující identitu
  • Autentizace – ověřuje uživatelovu identitu
  • Autorizace – identifikuje, k čemu má uživatel mandát
  • Claims (*Atributes) – obsahuje specifické informace o identitě, které jsou posílány uvnitř Security tokenu
  • Bindings
  • Definuje, přes jaký protokol se vyměňují SAML zprávy
  • SAML pracuje mimo jiné s protokoly SMTP, HTTP, FTP, EbXML a dalšími

Claims provider (*Identity provider) – je služba, která komunikuje se Service providerem za použití SAML a předává Claimy uživateli nebo aplikaci (Principal nebo Identita). Jako příklad Identity Provider je možné si představit ADFS ve vaší organizaci. Identity provider může požadovat další údaje pro Principal (Identity), například uživatelské jméno a heslo.

Relaying party (*Service provider) – Service provider je endpoint, se kterým identita komunikuje a vůči kterému se autorizuje a autentizuje. Service provider požaduje Security assertion (Claim) od Identity providera. Jako příklad Service providera uvedeme Office 365.

Claims (*Attributes) – Je sada informací o identitě, které jsou posílány v Security Tokenu

Federation Metadata– je sada OPTIONAL atributů, která je generovaná na základě konfigurace ADFS a rozšiřuje stávající SAML 2.0.

a1

Příklad Federation Metadata.xml

Account partner organization – je reprezentovaná Claims provider trustem v lokálním ADFS. Je to například AD, ve kterém se nachází identity, které budou přistupovat do aplikace, nebo ke zdrojům Resource partner organizace

Account federation server – Je federation server (např. ADFS) v Account partner organizaci. Tento server vystavuje Security tokeny pro identity na základě autentizace. Server autentizuje uživatele, ze zdroje autentizace načte relevantní atributy, členství ve skupinách a zabalí tyto informace do Claimů. V dalším kroku vygeneruje a podepíše Security token a vrátí jej uživateli. Uživatel následně může Security token poslat do Resource partner organizace.

Resource partner organization – je organizace federačního partnera, která je v lokálním federačním serveru reprezentovaná jako Relaying party trust. Resource partner organization vystavuje Claimy, které obsahují seznam aplikací, ke kterým může uživatel z Resource partner organizace přistupovat.

Resource federaton server– je federační server v Resource partner organizaci. Resource federation server vystavuje Security tokeny uživatelům na základě Security tokenů vystavených Account federation serverem. Resource federation server příjme Security token, ověří jeho podpis, aplikuje pravidla pro přijaté Claimy (například převod UPN na Email adresu atd.) a následně vygeneruje nový Security token, který přepošle uživateli.

Relaying Party Trust– Jsou definované vztahy důvěry, skládají se z řady identifikátorů, pravidel a jmen, které identigikují partnerskou organizaci nebo webovou aplikaci vůči lokálnímu ADFS.

Jako příklad Relaying Party Trustu je možné uvést Microsoft Office 365 Identity Platform.

a2

Příklad URL pro Federation Metadata URL v rámci Relaying party Trustu pro Office 365

a3

Příklad Relaying Party Trust pro Office 365 – 1/ WS-Federation Passive URL, 2/ Federation Metadata URL

Relaying Party Trusty slouží:

  • V Account partner organization – reprezentuje organizaci ve vztahu důvěry jako organizaci, jejíž identity budou přistupovat ke zdrojům v Resource partner organizaci
  • V Resource partner organizaci – reprezentuje vztah důvěry (trust) mezi Federation Service a Web aplikací

Claims Provider Trust – je vztah důvěry mezi Federation Service v Resource partner organization, kde reprezentuje organizaci, ze které se budou autentizovat identity, které mají přistupovat do Resource partner organizace.

Token Signing Certificate– Certifikát jehož privátní klíč podepisuje Security tokeny

Token Decrypting Certificate – Certifikát pro dekryptování claimů vystavených partnerskými Federation servisy.

Service Communication Certificate – Důvěryhodný certifikát pro servisní komunikaci ADFS serverů.

V další části seriálu si popíšeme, základy ADFS, jak ADFS funguje a uvedeme příklady použití.

- Zbyněk Saloň ( KPCS CZ )