smart sso -Download - smart sso -Quellcode herunterladen

smart sso

JAVA-Quellcode

1.0.0

Herunterladen

Smart-SSO

QQ-Kommunikationsgruppe: 454343484, 769134727

Kurze Beschreibung

Smart-SSO basiert auf der beliebten SpringBoot-Technologie und basiert auf der OAuth2-Authentifizierung in Kombination mit dem RBAC-Berechtigungsdesign, um für Sie ein leichtes, hochverfügbares Single-Point-Authentifizierungs- und Autorisierungszentrum zu schaffen.

Funktionsbeschreibung

Leicht: minimalistische Implementierung des Autorisierungscodemodus basierend auf den Protokollen SpringBoot und OAuth2;
Single-Point-Exit: Wenn die Client-Anwendung das Token erhält, übergibt sie implizit ihre Abmeldeadresse an den Server. Wenn eine Client-Anwendung den Vorgang zum Beenden ausführt, benachrichtigt der Server alle Client-Anwendungen aus der Ferne, um das lokale Token abzumelden, wodurch ein Single-Point-Exit durchgeführt wird.
Automatische Erneuerung: Verwenden Sie die accessToken-Richtlinie des OAuth2-Protokolls. Bei Ablauf ruft das Client-Backend automatisch die RefreshToken-Aktualisierungsschnittstelle auf und aktualisiert die serverseitige Zertifikat-Stub-Alterung, um die automatische Erneuerung nach Ablauf abzuschließen.
Domänenübergreifende Unterstützung: Der Server und der Client ermöglichen domänenübergreifende Single-Sign-On- und Exit-Mechanismen unter verschiedenen Domänennamen.
Front-End- und Back-End-Trennung: Benutzer können Single-Sign-On-bezogene Funktionen unter der Architektur der Front-End- und Back-End-Trennung problemlos implementieren (kein Cookie-Modus).
Berechtigungen auf Schaltflächenebene: Der Server klassifiziert Berechtigungen in Menüs und Schaltflächen und implementiert die Steuerung auf Berechtigungsschaltflächenebene, indem er den Anforderungs-URI und die Anforderungsmethode abgleicht.
Verteilte Bereitstellung: Sowohl der Server als auch der Client unterstützen Bereitstellungsszenarien mit mehreren Instanzen basierend auf dem gemeinsam genutzten Redis-Token.

Code-Hosting

Gitee: https://gitee.com/a466350665/smart-sso
Github: https://github.com/a466350665/smart-sso
Gitcode: https://gitcode.com/openjoe/smart-sso

Projektstruktur

 smart - sso
├── smart - sso - demo -- 客户端示例
├── smart - sso - demo - h5 -- 前后端分离客户端示例
├── smart - sso - server -- 单点登录权限管理服务端
├── smart - sso - starter -- 依赖装配模块
│   ├── smart - sso - starter - base -- 公用的基础常量、工具、凭证清理机制
│   ├── smart - sso - starter - client -- 客户端依赖包，客户端Token生命周期管理
│   ├── smart - sso - starter - client - redis -- 客户端依赖装配，分布式部署场景redis支持
│   ├── smart - sso - starter - server -- 服务端依赖包，服务端凭证生命周期管理
│   ├── smart - sso - starter - server - redis -- 服务端依赖装配，分布式部署场景redis支持

Modulabhängigkeiten

Notiz:
1. Die rote durchgezogene Linie kann so verstanden werden, dass der Server auch Single Sign-On benötigt und auch sein eigener Client ist.
2. Die rot gepunktete Linie zeigt an, dass unabhängig davon, ob es sich um einen Server oder einen Client handelt, die Redis-Versionsabhängigkeit zum Implementieren der Token-Freigabe verwendet werden kann, wenn eine Clusterbereitstellung erforderlich ist.

Technologieauswahl

Technologie	Version	veranschaulichen
Federstiefel	3.3.4	Container + MVC-Framework
spring-boot-starter-data-redis	3.3.4	Verteilte Szenen-Token-Verwaltung
Spring-Boot-Starter-Freemarker	3.3.4	Template-Engine
Springfox-Boot-Starter	3.0.0	dokumentieren
mybatis-plus-spring-boot3-starter	3.5.7	ORM-Framework
MySQL-Connector-Java	8.0.28	Datenbankgesteuert
httpclient	4.5.14	Autorisierungscode-Authentifizierung, Client- und Serverkommunikation

Warum OAuth2 wählen?

Im Folgenden finden Sie einen Vergleich mehrerer gängiger SSO-Authentifizierungsmethoden:

Merkmal	Traditionelles Token	JWT	OAuth2
Einmaliges Anmelden	Unterstützung	Unterstützung	Unterstützung
einzelner Ausgang	Unterstützung	Schwer zu erreichen	Unterstützung
Kicke Leute offline	Unterstützung	Schwer zu erreichen	Unterstützung
Verlängerung nach Ablauf	Schwer zu erreichen	Unterstützung	Unterstützung
Leistung	allgemein	hoch	besser
Sicherheit	allgemein	besser	hoch
Komplexität	allgemein	höher	hoch

erklären:
Bei der herkömmlichen Token-Methode ist der Mechanismus relativ einfach. Normalerweise generiert der Server eine zufällige Zeichenfolge als Token und leitet sie dann zwischen dem Client und dem Server weiter, um die Identität des Benutzers zu überprüfen. Allerdings liegen auch die Mängel dieser Methode auf der Hand. Aufgrund fehlender Aktualität und Aktualisierungsmechanismen ist es schwierig, die automatische Erneuerungsfunktion zu implementieren. Benutzeranfragen vom Client an den Server müssen den Server häufig zur Token-Verifizierung aufrufen. Für einige kleine Projekte, insbesondere Szenarien, in denen die Leistungs- oder Sicherheitsanforderungen nicht besonders hoch sind, kann diese Methode jedoch ausreichend sein.

Aufgrund der zustandslosen Natur von JWT muss der Server nur den Schlüssel und keine Token-Informationen speichern, wodurch der Speicherdruck auf dem Server verringert wird. Im SSO-Szenario ist es jedoch schwierig, die Single-Point-Exit- und Offline-Kick-Funktionen zu implementieren. Diese Funktionen müssen häufig auf das Back-End-Speichertoken in Kombination mit der Remote-Abmeldebenachrichtigung oder dem gemeinsam genutzten Speicher angewiesen sein, was zu Konflikten führt Konzept von JWT. Für manche Projekte mit extrem hohen Sicherheitsanforderungen sind diese Features unverzichtbar.

OAuth2 wird häufig für die autorisierte Anmeldung von Drittanbieteranwendungen verwendet und ist vollständig an SSO-Szenarien angepasst, ist jedoch relativ schwierig zu implementieren. Es verfügt natürlich über den Alterungs- und Aktualisierungsmechanismus des Tokens und kann eine Token-Erneuerung realisieren, während JWT zur Vervollständigung auf eine duale Token-Methode verbessert werden muss. Für jede Anwendung, die auf das OAuth2-Authentifizierungs- und Autorisierungszentrum zugreifen muss, muss sie auf ihrem Server registriert werden und Schlüsselinformationen (ClientId, ClientSecret) ausgeben. Nur auf diese Weise kann das Token gemäß dem Prozess abgerufen werden. Durch diesen Vorgang kann eine doppelte Überprüfung der Benutzeridentität (Erfassungsphase des Autorisierungscodes) und der Identität der Clientanwendung (Erfassungsphase des AccessTokens) erreicht werden. Für das Authentifizierungs- und Autorisierungssystem besteht die erste Aufgabe nach erfolgreicher Anmeldung darin, die Berechtigungsinformationen des angemeldeten Benutzers in der aktuellen Anwendung abzurufen. Daher muss der Server das Token für jede Clientanwendung des Benutzers separat ausstellen und kann diese nicht einfach abrufen Mit einem einzigen Client-Anwendungstoken können Sie alle vom Authentifizierungs- und Autorisierungszentrum verwalteten Anwendungsressourcenberechtigungen erhalten, was auch mit der ursprünglichen Absicht von OAuth2 übereinstimmt.

abschließend:
Smart-SSO hat sich für die Erstellung mit OAuth2 entschieden. Um die Mängel auszugleichen, wurden einige Funktionen sorgfältig verbessert. Beispielsweise speichert das Client-Backend das Token im Cache, und die Anforderung des Benutzers, die das Token enthält, kann lokal in der Clientanwendung überprüft werden, wodurch die Interaktion zwischen der Clientanwendung und dem Server erheblich reduziert wird. Der Erneuerungsmechanismus wurde ebenfalls verbessert. Wenn das lokale Token des Clients abläuft, initiiert das Backend des Clients eine RefreshToken-Anfrage an den Server, generiert das Token neu und schreibt es zurück an das Frontend Zertifikats-Stub, wodurch eine automatische Erneuerung nach Ablauf erreicht wird.