\subsection{SAML}

\emph{SAML}, die \emph{Security Assertion Markup Language} ist, im Unterschied
zu den anderen Security-Frameworks keine Implementation von Sicherheitsfeatures
sondern ein industriestandard von OASIS (Organization for the Advancement of
Structured Information Standards). Als solcher konkurriert SAML mit anderen
Protokollen wie etwa OpenID.

In der Welt von \emph{SAML} existieren User, sogenannte \emph{principals},
Authentisierungs-Provider (\emph{identity provider}) sowie \emph{service
provider}, die die Dienste bereitstellen auf die die \emph{principals}
zugreifen wollen. Der typische Ablauf von SAML ist es, dass der
\emph{principal} eine Aktion anfordert, diese Anfrage vom \emph{identity
provider} beglaubigt wird und als sogenannte \emph{Assertion} an den
\emph{service provider} weiterleitet, der je nach seinen Richtlinien
entscheidet ob der authentisierte Benutzer authorisiert ist, diese Aktion
durchzuführen und im Erfolgsfall diese Aktion durchführt.

SAML besteht aus einer Reihe von komponenten die zusammenspielen. Der
Datenaustausch erfolgt über einen speziellen XML-Dialekt, SAML. Die Integrität
der Assertions wird durch XML Signatures sichergestellt, so dass die Assertions
nicht vom \emph{principal} manipuliert werden können. Zusätzlich können
vertauliche Teile der Assertions verschlüsselt werden, um keine geheimen
Informationen preiszugeben. Die Kommunikation erfolgt vornehmlich über SOAP auf
HTTP, obwohl SAML über Bindings auch weitere Kommunikationswege unterstützt.

\subsubsection{Authentifizierung}

Bei der Authentifizierung steht es dem \emph{identity provider} frei, wie er
den User authentifiziert. Er kann dabei beliebige Verfahren nutzen, SAML
spricht sich nicht darüber aus, wie die Authentifizierung stattzufinden hat.
Bei erfolgreicher Authentifizierung stellt der \emph{identity provider} für den
User eine \emph{Assertion} aus.

Diese \emph{Assertion} kann verschiedene Arten von \emph{Statements} enthalten:

\begin{enumerate}
  \item Authorisierungs-Statements: Wer hat wen wie wann authorisiert?
  \item Attributs-Statements: Schlüssel-Wert-Paare die die Nutzdaten
    transportieren, etwa was der \emph{principal} für eine Aktion ausführen will
  \item Authorisierungs-Entscheidungs-Statements: Zusatzbedingungen für die
    Authorisierung, etwa wie lange die Assertion gültig sein soll.
    SAML spezifiziert diese nicht im Detail, für komplexere Szenarios wird
    auf \emph{XACML} verwiesen
\end{enumerate}

Eine beispielhafte \emph{Assertion} ist in Listing~\ref{src:assertion}
dargestellt. Diese teilt dem \emph{service provider} mit, von wem authentisiert
wurde (example.com), wer authentisiert wurde (alice@example.com), für wen diese
authentifikations gilt (example2.com) sowie die Mitteilung über eine
Telefonnummer (+1-888-555-1212).

\begin{figure}
\begin{lstlisting}
<Assertion ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc"
   IssueInstant="2003-04-17T00:46:02Z" Version="2.0"
   xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
   <Issuer>
      example.com
   </Issuer>
   <Subject>
      <NameID
        Format=
        "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
        alice@example.com
      </NameID>
      <SubjectConfirmation
        Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches"/>
   </Subject>
   <Conditions NotBefore="2003-04-17T00:46:02Z"
               NotOnOrAfter="2003-04-17T00:51:02Z">
      <AudienceRestriction>
         <Audience>
            example2.com
         </Audience>
      </AudienceRestriction>
   </Conditions>
   <AttributeStatement>
      <saml:Attribute
   xmlns:x500=
     "urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
   NameFormat=
     "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
   Name="urn:oid:2.5.4.20"
   FriendlyName="telephoneNumber">
         <saml:AttributeValue xsi:type="xs:string">
               +1-888-555-1212
         </saml:AttributeValue>
      </saml:Attribute>
   </AttributeStatement>
</Assertion>
\end{lstlisting}
  \caption{Unsignierte \emph{SAML-Assertion}}
  \label{src:assertion}
\end{figure}

\subsubsection{Authorisierung}

Der \emph{service provider} empfängt die \emph{Assertion} und entscheidet nach
seiner Policy ob er diese Aktion zulässt oder ablehnt. Zusätzlich hat der
\emph{service provider} ebenfalls die Möglichkeit Daten vom \emph{identity
provider} über drei Arten von \emph{Queries} zu empfangen:

\begin{enumerate}
  \item Authentication query
  \item Attribute query
  \item Authorization decision query
\end{enumerate}

Diese entsprechen den Feldern aus der \emph{Assertion} und werden üblicherweise
über SOAP ausgetauscht. 

Weitere Vorgaben wie die Authorisierung abläuft macht SAML nicht. Die Attribute
sind ebenfalls applikationsspezifisch und sollen auf der applikationsebene
gehandhabt werden.

\subsubsection{Einschätzung}

\emph{SAML} ist ein interessanter Ansatz für das Delegieren von Authentisierung
sowie Authorisierung. Der Einsatz von Signierung sowie Verschlüsselung
ermöglicht sichere Übertragung, allerdings die Tatsache dass das
Attributsformat keine spezifizierte Semantik hat, macht es schwierig sinnvoll
interoperable \emph{identity provider} zu haben, die ensprechende
\emph{attribute queries} an die \emph{service provider} weitergeben.

Allerdings ist es bei SAML natürlich noch notwendig sich für eine
Implementation zu entscheiden. Eine mögliche Wahl aus dem Open-Source-Umfeld
ist etwa OpenSAML, jedoch existieren auch eine Reihe von SAML-Implementationen
von IBM, Sun, VeriSign, RSA etc. Zudem bietet SAML eigentlich nur ein Protokoll
zum übermitteln von Authentisierungs-Nachrichten, die tatsächliche
Authorisierung muss auf Applikationsebene gemacht werden, selbiges gilt für die
Authorisierungs-Entscheidungen, diese müssen auch von der Applikation
vorgenommen werden. Daher wäre, wenn man die Authentifizierung und
Authorisierung nicht selbst implementieren will ein Applikationsframework wie
Shiro oder Spring Security notwendig.

Weiterhin hat SAML in letzten Jahren zunehmend Konkurrenz von
OpenID\footnote{\url{https://openid.net/}} für die Authentisierung sowie
OAuth\footnote{\url{http://oauth.net/}} im Web-Umfeld bekommen. \emph{SAML} ist
ein wesentlich breiteres Protokoll, dass mit dem Web Browser SSO Profil auch
Single-Sign-On unterstützt, dadurch aber auch umfangreicher im Vergleich zu
OpenID/OAuth. Zudem letztere immer breitere Unterstützung finden, u.a. von
Twitter, Yahoo, AOL, Google und VeriSign muss man sich fragen, ob man für einen
auf das Web begrenzten Service nicht lieber auf die auf REST besierende
Konkurrenz setzt. Spring Security, als Applikationsframework bietet Integration
mit OAuth an, daher ist dies ein schwerwiegendes Argument wenn man sowohl
einfache und integrierte Authentisierung will als auch Interoperabilität mit
\emph{service providern}.
