Frage

Ich frage mich, ob ich das verwenden sollte CAS Protokoll oder OAuth + Ein Authentifizierungsanbieter für Single Sign-On.

Beispielszenario:

  1. Ein Benutzer versucht, auf eine geschützte Ressource zuzugreifen, ist jedoch nicht authentifiziert.
  2. Die Anwendung leitet den Benutzer auf den SSO -Server um.
  3. Wenn BEEING authentifiziert hat, erhält der Benutzer ein Token vom SSO -Server.
  4. Die SSO leitet zur ursprünglichen Anwendung weiter.
  5. Die ursprüngliche Anwendung überprüft das Token mit dem SSO -Server.
  6. Wenn das Token in Ordnung ist, ist der Zugriff zulässig und die Anwendung kennt die Benutzer -ID.
  7. Der Benutzer führt ein Abmelden aus und wird gleichzeitig von allen verbundenen Anwendungen ausgeloggt (einzelne Anmeldung).

Soweit ich weiß, wurde genau das, wofür CAS erfunden wurde. CAS -Clients müssen das CAS -Protokoll implementieren, um den Authentifizierungsdienst zu verwenden. Jetzt frage ich mich, dass ich Cas oder OAuth auf der Kunden -Website (Verbraucher) verwenden möchte. Ist OAuth ein Ersatz für diesen Teil von CAS? Sollte OAuth als neuer De-Facto-Standard bevorzugt werden? Gibt es einen einfachen (nicht Sonne OpenSo!) Ersatz für den Authentifizierungsteil von CAS, der verschiedene Methoden wie Benutzername/Passwort, OpenID, TLS -Certifactes unterstützt ...?

Kontext:

  • Verschiedene Anwendungen sollten sich auf die Authentifizierung des SSO-Servers verlassen und etwas Sitzungsähnliches verwenden.
  • Die Anwendungen können GUI -Webanwendungen oder (Rest-) Serivces sein.
  • Der SSO -Server muss eine Benutzer -ID bereitstellen, die erforderlich ist, um weitere Informationen über den Benutzer wie Rollen, E -Mail usw. in einem zentralen Benutzerinformationsspeicher zu erhalten.
  • Einer Anmeldung sollte möglich sein.
  • Die meisten Kunden sind in Java oder PHP geschrieben.

Ich habe gerade Entdeckte Wrap, was zum Nachfolger von OAuth werden könnte. Es ist ein neues Protokoll, das von Microsoft, Google und Yahoo angegeben ist.

Nachtrag

Ich habe erfahren, dass OAuth nicht für die Authentifizierung ausgelegt war, selbst wenn es zur Implementierung von SSO verwendet werden konnte, sondern nur zusammen mit einem SSO -Dienst wie OpenID.

OpenID scheint mir der "neue CAS" zu sein. CAS verfügt über einige Funktionen von OpenID-Misses (wie ein einzelner Anmelde), aber es sollte nicht schwierig sein, die fehlenden Teile in einem bestimmten Szenario hinzuzufügen. Ich denke, OpenID hat eine breite Akzeptanz und es ist besser, OpenID in Anwendungen oder Anwendungsserver zu integrieren. Ich weiß, dass CAS auch OpenID unterstützt, aber ich denke, CAS ist mit OpenID entbehrlich.

War es hilfreich?

Lösung

OpenID ist kein "Nachfolger" oder "Ersatz" für CAS, sie sind unterschiedlich, in der Absicht und in der Umsetzung.

CAS zentralisiert Authentifizierung. Verwenden Sie es, wenn alle Ihre (wahrscheinlich internen) Anwendungen die Benutzer auffordern, sich bei einem einzelnen Server anzumelden (alle Anwendungen sind so konfiguriert, dass sie auf einen einzelnen CAS -Server verweisen).

OpenID dezentralisiert Authentifizierung. Verwenden Sie es, wenn Sie möchten, dass Ihre Anwendung die Benutzer anmelden, die sich für den gewünschten Authentifizierungsdienst anmelden (der Benutzer liefert die OpenID -Serveradresse - tatsächlich ist der 'Benutzername' die URL des Servers).

Keine der oben genannten Behörden (ohne Erweiterungen und/oder Anpassung).

OAuth kümmert sich um die Autorisierung, ist jedoch kein Ersatz für die traditionelle "user_roles table" (Benutzerzugriff). Es behandelt die Autorisierung für Dritte.

Sie möchten beispielsweise Ihre Anwendung in Twitter integrieren: Ein Benutzer kann es automatisch twittern, wenn er seine Daten aktualisiert oder neue Inhalte veröffentlichen. Sie möchten im Namen eines Benutzers auf einen Dienst oder eine Ressource von Drittanbietern zugreifen, ohne sein Passwort zu erhalten (was für den Benutzer offensichtlich unsicher ist). Die Anwendung bittet Twitter um den Zugriff, die Benutzer autorisiert es (über Twitter), und dann kann die App Zugriff haben.

Bei OAuth geht es also weder um ein Signal-On (noch einen Ersatz für das CAS-Protokoll). Es geht nicht um Sie Steuern, auf die der Benutzer zugreifen kann. Es geht darum, das zu lassen Benutzer zu kontrollieren, wie ihr Ressourcen können von Dritten zugegriffen werden. Zwei sehr unterschiedliche Anwendungsfälle.

In dem Kontext, den Sie beschrieben haben, ist CAS wahrscheinlich die richtige Wahl.

Aktualisiert

Sie können SSO jedoch mit OAuth implementieren, wenn Sie die Identität des Benutzer als eine gesicherte Ressource betrachten. Dies ist es, was sich mit Github anmelden und im Grunde genommen tun. Wahrscheinlich nicht die ursprüngliche Absicht des Protokolls, aber es kann getan werden. Wenn Sie den OAuth -Server steuern und die Apps nur dann mit ihm authentifizieren, ist das SSO.

Keine Standardmethode, um Abmelden zu erzwingen (CAS hat diese Funktion).

Andere Tipps

Ich neige dazu, so darüber nachzudenken:

Verwenden Sie CAS, wenn Sie das Benutzerauthentifizierungssystem steuern/besitzen und einen heterogenen Satz von Servern und Apps unterstützen müssen, die eine zentralisierte Authentifizierung benötigen.

Verwenden Sie OAuth, wenn Sie die Benutzerauthentifizierung von Systemen unterstützen möchten, die Sie nicht besitzen/unterstützen (dh Google, Facebook usw.).

OpenID ist ein Authentifizierungsprotokoll, OAuth und OAuth Wrap sind Autorisierungsprotokolle. Sie können mit dem kombiniert werden Hybrid OpenID -Erweiterung.

Ich würde es dringend vorziehen, dass Menschen auf dem neuesten Stand der Normen aufbauen, die viel Schwung haben (mehr verfügbare Unterstützung, einfacher zu beteiligen Dritten), auch wenn sie nicht genau für die anstehende Anwendung geeignet sind. In diesem Fall hat OAuth den Schwung, nicht CAS. Sie sollten in der Lage sein, alle oder zumindest fast alle zu tun, was Sie mit OAuth tun müssen. Zu einem späteren Zeitpunkt in der Zukunft sollte OAuth Wrap die Dinge weiter vereinfachen (es macht einige lohnende Kompromisse durch die Verwendung eines Trägermodus und die Verschlüsselung auf die Protokollschicht), aber es steckt noch in den Kinderschuhen und in der Zwischenzeit OAuth, OAuth wird den Job wahrscheinlich gut machen.

Wenn Sie sich für OpenID und OAuth entscheiden, gibt es letztendlich mehr Bibliotheken für weitere Sprachen und alle anderen, die sich in das System integrieren müssen. Sie haben auch viel mehr Augäpfel, die sich die Protokolle ansehen und sicherstellen, dass sie wirklich so sicher sind, wie sie sein sollen.

Alter Beitrag, aber das könnte nützlich sein:

CAS 3.5 unterstützt OAuth als Client und Server. Sehen: https://wiki.jasig.org/display/casum/oauth

Für mich ist der wahre Unterschied zwischen SSO und OAuth Grant, nicht Authentifizierung, da ein Server, der OAuth offensichtlich implementiert hat Authentifizierung (Sie müssen bei Ihrem Google, OpenID oder Facebook angemeldet werden, damit OAuth mit der Client -App stattfindet)

In SSO gewährt ein Power User/sysadmin den endgültigen Benutzerzugriff auf eine Anwendung im Voraus "SSO -App" in OAuth, der endgültige Benutzer gewährt den Zugriff auf die Anwendung zu seinen "Daten" in der "OAuth -App".

Ich verstehe nicht, warum OAuth -Protokoll nicht als Teil eines SSO -Servers verwendet werden konnte. Nehmen Sie einfach den Grant -Bildschirm aus dem Fluss heraus und lassen Sie den OAuth -Server den Zuschuss aus der DB -Backing -DB suchen.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top