Single-Sign-On (SSO) bedeutet, dass mit einer einmaligen Anmeldung am Rechner alle weiteren Dienste, auf die der Benutzer Zugriff haben soll, automatisch ohne weitere Anmeldung freigeschaltet sind. Andererseits sollen nur die Dienste genutzt werden können, für die auch der Zugriff freigeschaltet wurde. Damit verbunden ist ein aussagekräftiges Logfile, welches eben auch das login enthält.

siehe auch PAM, Kerberos, UCSC Identity Management Project, Build and implement a single sign-on solution (developerWorks)

Standardlösung

Um das Prinzip von SSO zu verstehen, soll das folgende Beispiel zur Veranschaulichung dienen. In einem Netz stehen auf jeweils eigener Hardware ein Samba-, ein Web-, ein Proxy- und ein Mailserver zur Verfügung. Jeder dieses Dienste kann auf eine Datenbank zugreifen, wo die User verzeichnet sind, die diesen Dienst nutzen können (oder auch nicht). Das kann natürlich auch die gleiche Datenbank sein, üblicherweise die shadow oder eine modifizierte Kopie der shadow, es kann aber auch wie im Fall von Samba eine völlig andere Datei/Datenbank (smbpasswd) sein.
Es liegt natürlich nahe, den Verwaltungsaufwand zu minimieren, indem man diese Daten in einer Datenbank bereitstellt, üblicherweise durch einen LDAP-Server. Damit hätten wir jetzt die Situation, das ich mich an jeden Server anmelde und diese holen die Zugriffsberechtigungen aus dieser Datenbank. Als Vorteil ergibt sich, das nur eine Datenbank gepflegt wird, insbesondere brauchen für die verschiedenen Dienste nicht verschiedene Passwörter gepflegt zu werden. diese Situation wird häufig schon single-sign-on genannt, ist es aber nicht.
Trotzdem ist die Situation noch so, das ich mich zum surfen an Squid anmelden muß, zum Mail abholen muß ich wieder mein Passwort eingeben usw. - wenn also 'jemand' meine Anmeldung beim ersten Mal überprüft hat, dann könnte dieser jemand mich doch bei den Diensten anmelden. Dieser 'jemand', also der Anmeldeserver, muß natürlich wissen, wo ich mich überhaupt anmelden darf.

Das wird üblicherweise so realisiert: als Anmeldeserver fungiert standardmäßig ein Kerberosserver. An dem erfolgt die eigentliche Anmeldung. Dieser fragt beim LDAP-Server nach, welche Dienste überhaupt genutzt werden können und für jeden dieser freigegebenen Dienste wird eine Eintrittskarte (Ticket) erstellt. Wenn man nun surfen will, also den Proxy aufruft, dann übernimmt jetzt der Kerberosserver die Anmeldung, wenn ein entsprechendes Ticket vorliegt. Ebenso für die anderen Dienste.

Allerdings ergibt sich folgendes Problem. Der Proxy 'liefert' normalerweise das Anmeldefenster an den Client, der diesen Proxy aufruft (Browser). Jetzt muß aber die Konversation zwischen dem Proxy und dem Kerberosserver erfolgen, das heißt, jeder der betreffenden Dienste muß kerberisiert sein. Beispielsweise liegt m.E. Squid noch nicht in einer kerberisierten Form vor.

so wie ich das verstehe, muss der Dienst nicht kerberisiert sein, wenn er PAM(pam_krb5) oder SASL(GSSAPI) verwendet. -- RonnyBuchmann 2003-09-11 17:13:02 siehe pam_krb5(5):

       When a user logs in, the module's authentication  function  performs  a
       simple password check and, if possible, obtains Kerberos 5 and Kerberos
       IV credentials, caching them  for  later  use.   When  the  application
       requests  initialization of credentials (or opens a session), the usual
       ticket files are created.  When the application  subsequently  requests
       deletion  of  credentials or closing of the session, the module deletes
       the ticket files.

eine Lösung nach Dieter Klünter

Benötigte Dienste:

auf W2K Clients die pGina Module PAM und LDAP (http://pgina.xpasystems.com)
auf Linux Clients PAM mit pam_krb5 und pam_ldap
Kerberos v5 Clients und OpenLDAP-Clients auf den Linuxhosts
OpenLDAP-Server
Kerberos v5 KDC, vorzugsweise Heimdal

Jeder Anwender hat einen Eintrag im Verzeichnisdienst mit Passwort und dem zusätzlichen Attribut krb5PrinzipalName.

Heimdal KDC kann den Verzeichnisdienst als Database nutzen.

Alle Dienste müssen entweder durch SASL oder PAM authentifizieren können.

sofern für den Dienst PAM genutzt wird, wird pam_krb5 aufgerufen
- PAM kann praktisch jedes Programm
wird SASL benötigt, kann mittels GSSAPI die Authentifizierung vorgenommen werden.
- GSSAPI kann kaum eines

Web SSO

tequila.epfl.ch (Perl)
Yale CAS (Java)

-- HansDietrichKirmse

SingleSignOn

Standardlösung

Links