SAML (Security Assertion Markup Language) ist ein quell­of­fe­nes XML-Framework, das den Austausch von Au­then­ti­fi­zie­rungs- und Au­to­ri­sie­rungs­in­for­ma­tio­nen er­mög­licht. Die einzelnen SAML-Kom­po­nen­ten, zu denen unter anderem eine zentrale Be­nut­zer­da­ten­bank und sechs ver­schie­de­ne Pro­to­kol­le zählen, stellen alle re­le­van­ten Funk­tio­nen zur Be­schrei­bung und Über­tra­gung von Si­cher­heits­funk­tio­nen zur Verfügung – weshalb SAML als her­vor­ra­gen­de Kom­plett­lö­sung für das Federated Identity Ma­nage­ment (FIM) gilt.

Was ist SAML?

Security Assertion Markup Language, kurz SAML, ist ein quell­of­fe­nes Framework auf XML-Basis zum Aus­tau­schen von Au­then­ti­fi­zie­rungs- und Au­to­ri­sie­rungs­in­for­ma­tio­nen. Es wurde ab 2001 vom Security Services Technical Committee des OASIS-Kon­sor­ti­ums (Orga­ni­sa­ti­on for the Advance­ment of Structured Infor­ma­ti­on Standards) ent­wi­ckelt und im November 2002 in einer ersten Version (SAML v1.0) ver­öf­fent­licht. Im Laufe der Zeit hat das Pro­jekt­team diverse An­pas­sun­gen vor­ge­nom­men, die in den über­ar­bei­te­ten Versionen SAML 2.0 und 2.1 (auch 1.1) wie­der­zu­fin­den sind. Der SAML-Standard enthält mehrere Kom­po­nen­ten, die alle re­le­van­ten Funk­tio­nen zur Be­schrei­bung und Über­tra­gung si­cher­heits­be­zo­ge­ner In­for­ma­tio­nen be­reit­stel­len. Damit bildet SAML die optimale Grundlage fürs Federated Identity Ma­nage­ment (FIM).

Die Funk­tio­nen der einzelnen SAML-Kom­po­nen­ten

SAML kann u. a. dazu verwendet werden, Aussagen über die Ei­gen­schaf­ten sowie die Be­rech­ti­gun­gen eines Benutzers gegenüber anderen Benutzern bzw. Part­ner­un­ter­neh­men, vor allem aber gegenüber An­wen­dun­gen zu machen (letztere werden im SAML-Konzept auch als Service-Provider be­zeich­net). Hierfür greift der so­ge­nann­te Identity-Provider (zentrale Be­nut­zer­da­ten­bank), der ent­spre­chen­de Nut­zer­in­for­ma­tio­nen speichert, auf As­ser­ti­ons im XML-Format zurück. Weitere Kom­po­nen­ten einer auf dem SAML-Standard ba­sie­ren­den Ve­ri­fi­zie­rungs­um­ge­bung sind sechs ver­schie­de­ne Pro­to­kol­le sowie Bindings und Profile.

As­ser­ti­ons

Eine SAML-Assertion kann eine oder mehrere Aussagen über die Ei­gen­schaf­ten (Identität, Attribute) und die Be­rech­ti­gun­gen eines Benutzers enthalten. Sie wird durch den je­wei­li­gen Identity-Provider, also die ver­ant­wort­li­che Be­nut­zer­da­ten­bank, erstellt, wobei XML als Aus­zeich­nungs­spra­che zum Einsatz kommt. Jede Assertion erhält zudem eine digitale Signatur, die zunächst durch den zu­grei­fen­den Service-Provider, also die jeweilige Anwendung, geprüft und ve­ri­fi­ziert werden muss. Auf diese Weise ist die In­te­gri­tät und Au­then­ti­zi­tät der Assertion ge­währ­leis­tet, die man in ihrer si­gnier­ten Form auch als SAML-Token be­zeich­net. Nach er­folg­rei­cher Ve­ri­fi­zie­rung ana­ly­siert der Service-Provider den ei­gent­li­chen Inhalt und trifft in der Folge eine Ent­schei­dung, ob und welchen Zugriff er dem Benutzer gewährt.

Folgende drei Typen von Aussagen in As­ser­ti­ons sind im SAML-2.0-Standard spe­zi­fi­ziert:

  • Au­then­ti­ca­ti­on State­ments: Über Au­then­ti­ca­ti­on State­ments in­for­miert der Identity-Provider die Anwendung darüber, dass der Benutzer au­then­ti­fi­ziert wurde. Ferner liefert dieser Auss­agen­typ in einer Assertion auch In­for­ma­tio­nen darüber, wann die Au­then­ti­fi­zie­rung stattfand und welche Methode hierfür zur Anwendung kam.
  • Attribute State­ments: Bei Attribute State­ments handelt es sich um Attribute, die mit dem je­wei­li­gen Benutzer verknüpft sind und so der Anwendung über das ent­spre­chen­de SAML-Token mit­ge­teilt werden können.
  • Aut­ho­riza­ti­on Decision State­ments: Wenn Aut­ho­riza­ti­on Decision State­ments in einer SAML-Assertion enthalten sind, hat der jeweilige Benutzer entweder Zugriff auf spe­zi­fi­sche Res­sour­cen erhalten oder ihm wurde der Zugriff auf spe­zi­fi­sche Res­sour­cen ver­wei­gert.
Hinweis

Die Anzahl an State­ments in einer Assertion hängt in erster Linie von dem An­wen­dungs­be­reich des SAML-Frame­works ab. Soll bei­spiels­wei­se Single Sign-on rea­li­siert werden, enthält ein SAML-Token ty­pi­scher­wei­se je ein einzelnes Au­then­ti­ca­ti­on Statement und ein Attribute Statement.

Pro­to­kol­le

Die SAML 2.0-Spe­zi­fi­ka­ti­on definiert eine Reihe von Abfrage-/Antwort-Pro­to­kol­len, die es der Anwendung bei­spiels­wei­se er­mög­li­chen, eine Assertion an­zu­for­dern bzw. ab­zu­fra­gen oder einen Benutzer auf­zu­for­dern, sich zu au­then­ti­fi­zie­ren. Im Detail handelt es sich dabei um folgende Pro­to­kol­le:

  • Au­then­ti­ca­ti­on Request Protocol: Das Au­then­ti­ca­ti­on Request Protocol definiert Nach­rich­ten vom Typ <Auth­n­Re­quest>, die benötigt werden, um As­ser­ti­ons mit Au­then­ti­ca­ti­on State­ments zu einem aus­ge­wähl­ten Benutzer ab­zu­fra­gen. Auf Basis dieses Pro­to­kolls gelangen die In­for­ma­tio­nen also von der Datenbank zum Service-Provider, wobei für ge­wöhn­lich das weit ver­brei­te­te SAML 2.0 Web Browser SSO Profile (mehr dazu im Abschnitt „Profile“) zum Einsatz kommt.
     
  • Assertion Query and Request Protocol: Für Abfragen, mit denen exis­tie­ren­de SAML-As­ser­ti­ons im All­ge­mei­nen abgerufen werden können, enthält das Framework das Assertion Query and Request Protocol. Die Abfrage der As­ser­ti­ons kann dabei auf Basis ver­schie­de­ner Parameter wie bei­spiels­wei­se der ent­hal­te­nen Aus­sa­ge­ty­pen erfolgen.
     
  • Single Logout Protocol: Das Single Logout Protocol definiert Abfragen, die eine nahezu gleich­zei­ti­ge Abmeldung von allen aktiven Sitzungen eines Benutzers in­iti­ie­ren. Solche Nach­rich­ten können sowohl der Benutzer selbst als auch Identity- oder Service-Provider senden. Letzteres ist vor allem dann denkbar, wenn eine Be­nut­zer­sit­zung ab­ge­lau­fen ist.
     
  • Artifact Re­so­lu­ti­on Protocol: Sollen SAML-Nach­rich­ten separat über einen sicheren Kanal oder in einer res­sour­cen­spa­ren­den Größe trans­por­tiert werden, kommt das Artifact Re­so­lu­ti­on Protocol zum Einsatz. Es er­mög­licht den Versand von Re­fe­ren­zen auf As­ser­ti­ons, die auch als Artefakte be­zeich­net werden und we­sent­lich kleiner als die ei­gent­li­che Nachricht sind. Das Protokoll erlaubt außerdem, diese Re­fe­ren­zen auf­zu­lö­sen, um die Ori­gi­nal­nach­richt zu erhalten.
     
  • Name Iden­ti­fier Ma­nage­ment Protocol: Dieses Protokoll stellt Mittel zur Verfügung, um den Na­mens­wert bzw. das -format einer Be­nut­zer­iden­ti­tät zu verändern. Verfasser des Requests kann entweder der Service- oder der Identity-Provider sein. Ferner lassen sich mit dem Name Iden­ti­fier Ma­nage­ment Protocol ent­spre­chen­de Ver­knüp­fun­gen zwischen Service- und Identity-Provider entfernen, die für die Au­then­ti­fi­zie­rung der ur­sprüng­li­chen Be­nut­zer­iden­ti­tät erzeugt wurden.
     
  • Name Iden­ti­fier Mapping Protocol: Das Name Iden­ti­fier Mapping Protocol definiert Abfrage- und Ant­wort­nach­rich­ten für die Kom­mu­ni­ka­ti­on zwischen zwei Service-Providern. Auf Basis dieses Nach­rich­ten­typs kann eine Anwendung beim Identity-Provider einen Iden­ti­fier für einen Benutzer abfragen, um auf eine andere Anwendung zugreifen zu können.

Bindings

Mappings – also Um­wand­lun­gen – des SAML-Nach­rich­ten­aus­tauschs in Standard-Messaging- oder Kom­mu­ni­ka­ti­ons­pro­to­kol­le werden als SAML-Protokoll-Bindings oder auch einfach nur Bindings be­zeich­net. So definiert das SOAP Binding bei­spiels­wei­se, wie sich SAML-Nach­rich­ten innerhalb von SOAP-Um­ge­bun­gen aus­tau­schen lassen, während das HTTP Redirect Binding festlegt, wie SAML-Protokoll-Nach­rich­ten über das HTTP-Wei­ter­lei­tungs­ver­fah­ren trans­por­tiert werden können. Weitere bereits im SAML-2.0-Standard vor­de­fi­nier­te Bindings sind:

  • Reverse SOAP Binding
  • HTTP POST Binding
  • HTTP Artifact Binding
  • SAML URI Binding

Profile

Als all­ge­mei­ner Standard zeichnet sich SAML durch seine Fle­xi­bi­li­tät aus, die das Framework für zahl­rei­che Ein­satz­sze­na­ri­en qua­li­fi­ziert. Damit bestimmte An­wen­dun­gen die Ver­wen­dung von SAML un­ter­stüt­zen, gilt es al­ler­dings, diese Fle­xi­bi­li­tät teilweise ein­zu­schrän­ken. Hierfür kommen so­ge­nann­te Profile zum Einsatz, die gewählte As­ser­ti­ons, Pro­to­kol­le und Bindings für spe­zi­fi­sche An­wen­dungs­fäl­le bündeln. Eines der am häu­figs­ten ver­wen­de­ten Profile ist das oben erwähnte SAML 2.0 Web Browser SSO Profile, das den Rahmen zur Rea­li­sie­rung einer SAML-SSO-Au­then­ti­fi­zie­rung spe­zi­fi­ziert. So enthält es alle ent­schei­den­den Kom­po­nen­ten, um die Kom­mu­ni­ka­ti­on von SAML-Au­then­ti­fi­zie­rungs­zu­si­che­run­gen zwischen Identity- und Service-Provider zu de­fi­nie­ren, die für die Ein­mal­an­mel­dung über einen be­lie­bi­gen Web­brow­ser notwendig ist. Ferner liefert das Framework folgende weiteren Profile mit:

  • Enhanced Client and Proxy (ECP) Profile
  • Identity Provider Discovery Profile
  • Single Logout Profile
  • Name Iden­ti­fier Ma­nage­ment Profile
  • Artifact Re­so­lu­ti­on Profile
  • Assertion Query/Request Profile
  • Name Iden­ti­fier Mapping Profile

Die wich­tigs­ten Än­de­run­gen in SAML 2.0

Mehr als 24 Un­ter­neh­men und Or­ga­ni­sa­tio­nen waren an der Kon­zep­tio­nie­rung und Er­ar­bei­tung von SAML 2.0 beteiligt, bevor die Version im März 2005 als of­fi­zi­el­ler Nach­fol­ger von SAML 1.0 bzw. 1.1 ver­öf­fent­licht werden konnte. Zu­sätz­lich zu zahl­rei­chen Ver­bes­se­run­gen vor­han­de­ner Features erhielt das Framework dabei auch komplett neue Features, die aus dem Liberty Alliance Identity Fe­de­ra­ti­on Framework (ID-FF) 1.2 und aus der von Internet2 ent­wi­ckel­ten Shib­bo­leth-Ar­chi­tek­tur über­nom­men wurden.

Fakt

Die zentrale Au­then­ti­fi­zie­rungs­da­ten­bank heißt erst seit SAML 2.0 „Identity Provider“, nachdem der Begriff aus der Ter­mi­no­lo­gie von Liberty Alliance über­nom­men wurde. In vor­an­ge­gan­ge­nen Versionen hieß diese Instanz noch „Au­then­ti­ca­ti­on Authority“.

Die folgende Auf­lis­tung zeigt einige der wich­tigs­ten An­pas­sun­gen, die das Framework im zweiten „großen“ Release („major release“) erhalten hat:

  • Ent­fer­nung einiger ver­al­te­ter Elemente wie <Aut­ho­ri­tyB­in­ding> oder <Re­spond­Wi­th> sowie des ver­al­te­ten Iden­ti­fier-Formats
  • Im­ple­men­tie­rung von XML-Signatur und XML-Ver­schlüs­se­lung (nach W3C-Standard)
  • Austausch des As­ser­tio­nID-Attributs durch ein all­ge­mei­nes XML-ID-Attribut
  • Ein­füh­rung von Session-Ma­nage­ment zur Un­ter­stüt­zung au­to­ma­ti­scher Ab­mel­dun­gen von allen An­wen­dun­gen (bei­spiels­wei­se bei langer Ab­we­sen­heit)
  • Anpassung der Metadaten, um den Einsatz von SAML zu ver­ein­fa­chen (u. a. sind nun auch in­vol­vier­te Instanzen wie der Identity-Provider und die Service-Provider in den Metadaten aus­ge­zeich­net)
  • Im­ple­men­tie­rung von Me­cha­nis­men, die es den Providern er­mög­li­chen, Pri­vat­sphä­re-Richt­li­ni­en und -Ein­stel­lun­gen zu kom­mu­ni­zie­ren
  • ver­bes­ser­te Un­ter­stüt­zung mobiler Geräte
  • Im­ple­men­tie­rung der bereits auf­ge­zähl­ten Pro­to­kol­le (in SAML 1.0 und 1.1 exis­tier­te nur das Assertion Query and Request Protocol)
  • Op­ti­mie­rung der Profile (z. B. Zu­sam­men­füh­rung der Profile „Browser/Artifact“ und „Browser/Post“ im „SAML 2.0 Web Browser SSO Profile“)

Eine de­tail­lier­te Auf­lis­tung der Un­ter­schie­de zwischen SAML 2.0 und SAML 1.1 liefert die SAML-Community-Seite saml.xml.org.

Wofür eignet sich das SAML-Framework?

Das Ein­satz­feld des SAML-Frame­works ist schnell definiert: Mit dem ent­spre­chen­den Know-how lässt sich eine zentrale Au­then­ti­fi­zie­rungs­in­stanz auf Basis der Aus­zeich­nungs­spra­che rea­li­sie­ren, die sich durch Effizienz und einen hohen Si­cher­heits­stan­dard aus­zeich­net. Letzteres ist ins­be­son­de­re darauf zu­rück­zu­füh­ren, dass die einzelnen An­wen­dun­gen keinerlei Be­nut­zer­da­ten speichern oder syn­chro­ni­sie­ren müssen, was die Zahl möglicher Si­cher­heits­lecks erheblich minimiert. Der Haupt­fo­kus des Frame­works liegt dabei darauf, diesen hohen Si­cher­heits­le­vel mit der best­mög­li­chen Be­nut­zer­freund­lich­keit zu ver­knüp­fen, weshalb es dank ent­spre­chen­der Pro­to­kol­le und Nach­rich­ten­for­ma­te auch den bereits mehrfach genannten Single Sign-on un­ter­stützt.

Hinweis

In der Praxis un­ter­schei­det man zwischen „Service Provider initiated SAML“ und „Identity Provider initiated SAML“. Die beiden Konzepte un­ter­schei­den sich darin, an welche Instanz die Au­then­ti­fi­zie­rungs­an­fra­ge des Benutzers gesendet wird (Service Provider oder Identity Provider).

Das SAML-SSO-Verfahren, das die Nutzung ver­schie­de­ner An­wen­dun­gen auf Basis einer einzigen Anmeldung er­mög­licht, ist dabei nicht nur bei un­ter­neh­mens­in­ter­nen Ap­pli­ka­ti­ons­pro­zes­sen gefragt: Die prak­ti­sche Ein­mal­an­mel­dung ist heute in den Konzepten diverser Web­ser­vices verankert – ins­be­son­de­re im On­line­ban­king und bei mobilen Apps. Häufig bekommt der Benutzer gar nicht mehr mit, dass er es bei der Nutzung solcher Dienste mit mehreren ver­schie­de­nen An­wen­dun­gen zu tun hat. So wird ein Kunde, der sich einmalig über die Website seiner Bank einloggt, mit großer Wahr­schein­lich­keit auf mehr als ein Backend-System zugreifen, wenn er bei­spiels­wei­se nach­ein­an­der Sparbuch, Depot und Kre­dit­kar­ten­kon­to öffnet. Dank der SAML-Tech­no­lo­gie erscheint es ihm al­ler­dings, als ob er lediglich ein einziges Programm bedient.

Zum Hauptmenü