シングルサインオンアプリケーション

シングルサインオン (シングルサインオン、SSO と呼ばれる) は、ユーザーが一連の資格情報 (ユーザー名とパスワードなど) を使用して、複数のアプリケーションやシステムにログインすることなく、複数のアプリケーションやシステムにログインできるようにする認証テクノロジです。各アプリケーションまたはシステムシステムに個別にログインします。この技術により、ユーザーエクスペリエンスが向上し、パスワード管理の負担が軽減され、セキュリティが向上します。この記事では、シングルサインオンテクノロジの原理、利点、実装について詳しく説明します。

1. シングルサインオンの原理

シングルサインオンの原理は、認証と認可に基づいています。ユーザーがアプリケーションまたはシステムにログインすると、アプリケーションまたはシステムは認証リクエストをアイデンティティプロバイダー (略して IdP) に送信します。ID プロバイダーはユーザーの資格情報を検証し、アプリケーションまたはシステムに認可トークンを送信します。トークンには、ユーザー名、役割、権限などのユーザーの ID に関する情報が含まれています。ユーザーが他のアプリケーションまたはシステムにアクセスしようとすると、それらのアプリケーションまたはシステムは認証リクエストを ID プロバイダーに送信し、以前に取得した認可トークンを使用して認可します。これにより、ユーザーはアプリケーションやシステムごとに個別にログインする必要がなく、複数のアプリケーションやシステムにわたるリソースにシームレスにアクセスできるようになります。

2. シングルサインオンのメリット

シングルサインオンテクノロジには、次のような多くの利点があります。

1. ユーザーエクスペリエンスの向上: シングルサインオンにより、ユーザーが覚えておく必要があるユーザー名とパスワードの数が減り、ユーザーエクスペリエンスが向上します。ユーザーは 1 回ログインするだけで、複数のアプリケーションまたはシステムにアクセスできます。

2. パスワード管理の負担の軽減: シングルサインオンにより、ユーザーが管理する必要があるパスワードの数が減り、パスワード管理の負担が軽減されます。ユーザーは 1 つのパスワードを覚えておくだけで、複数のアプリケーションやシステムにアクセスできます。

3. セキュリティの向上: シングルサインオンにより、ユーザーは資格情報を複数のアプリケーションやシステムに入力するのではなく、1 か所に入力するだけで済むため、セキュリティが向上します。これにより、パスワード侵害のリスクが軽減され、認証の信頼性が高まります。

4. コストの削減: シングルサインオンにより、パスワードのリセットとアカウント管理にかかる支出が削減されるため、コストが削減されます。さらに、ユーザーが自分のアカウントを自分で管理できるため、IT サポートの必要性が軽減されます。

3. シングルサインオンの実現方法

シングルサインオンは、次のようなさまざまな方法で実現できます。

1. Cookie ベースのシングルサインオン: Cookie を使用してユーザーの認証情報を保存する方法です。ユーザーがアプリケーションまたはシステムにログインすると、アプリケーションまたはシステムはユーザーの認証情報を Cookie に保存します。ユーザーが他のアプリケーションまたはシステムにアクセスしようとすると、それらのアプリケーションまたはシステムは Cookie 内の認証情報をチェックし、その情報を認証と認可に使用します。

2. トークンベースのシングルサインオン: この方法では、トークンを使用してユーザーの認証情報を保存します。ユーザーがアプリケーションまたはシステムにログインすると、アプリケーションまたはシステムはアイデンティティプロバイダーに認証リクエストを送信し、認可トークンを取得します。ユーザーが他のアプリケーションまたはシステムにアクセスしようとすると、それらのアプリケーションまたはシステムは認証リクエストを ID プロバイダーに送信し、以前に取得した認可トークンを使用して認可します。

3. SAML ベースのシングルサインオン: この方法では、Security Assertion Markup Language (略して SAML) を使用してシングルサインオンを実装します。ユーザーがアプリケーションまたはシステムにログインすると、アプリケーションまたはシステムは認証リクエストをアイデンティティプロバイダーに送信し、SAML アサーションを取得します。ユーザーが他のアプリケーションまたはシステムにアクセスしようとすると、それらのアプリケーションまたはシステムは認証リクエストをアイデンティティプロバイダーに送信し、以前に取得した SAML アサーションを承認に使用します。

4. シングルサインオンの適用シナリオ

シングルサインオンテクノロジは、次のような多くのシナリオに適用できます。

1. 社内企業アプリケーション: 企業内には、電子メール、CRM、ERP システムなど、複数のアプリケーションまたはシステムが存在する場合があります。シングルサインオンテクノロジを使用すると、従業員は各アプリケーションまたはシステムに個別にログインすることなく、これらのアプリケーションまたはシステム間をシームレスに切り替えることができます。

2. クラウドアプリケーション: 多くの企業は、Office 365 や Salesforce などのクラウドアプリケーションを使用しています。シングルサインオンテクノロジを使用すると、従業員は各アプリケーションに個別にログインすることなく、これらのアプリケーションをシームレスに切り替えることができます。

3. フェデレーション ID: 多くの企業は、サプライチェーンパートナーや顧客など、他の企業とリソースを共有する必要があります。シングルサインオンテクノロジを使用することで、これらの企業はフェデレーション認証を実装し、セキュリティと利便性を向上させることができます。

5. シングルサインオンのセキュリティに関する考慮事項

シングルサインオンテクノロジはセキュリティを向上させることができますが、次のような考慮が必要なセキュリティ上の問題もいくつかあります。

1. ID プロバイダーのセキュリティ: ID プロバイダーはユーザーの認証情報を保存するため、攻撃者の標的になる可能性があります。したがって、ID プロバイダーは、ユーザーの認証情報を保護するために、暗号化やアクセス制御などの適切なセキュリティ対策を実装する必要があります。

2. トークンのセキュリティ: トークンは攻撃者によって盗まれたり、改ざんされたりする可能性があります。したがって、トークンには、暗号化、署名、偽造防止マークなど、セキュリティを保護するための特定のセキュリティ対策を講じる必要があります。さらに、トークンの使用には、安全でないネットワーク環境でトークンを使用しない、他人にトークンを開示しないなど、特定のセキュリティ規制に従う必要もあります。トークンが盗まれたり改ざんされたりした場合は、ユーザーのセキュリティを保護するために、トークンの失効、パスワードの変更などの措置をタイムリーに講じる必要があります。

シングルサインオンの認証プロセスは次のとおりです。

ユーザーがアプリケーション A にアクセスすると、アプリケーション A はユーザーがログインしていないことを検出し、ユーザーを認証センターにリダイレクトします。
ユーザーは、認証のために認証センターにユーザー名とパスワードを入力します。
認証センターはユーザーの本人確認を行い、認証に合格するとトークン（Token）が生成されます。
認証局はトークンをアプリケーション A に返します。
アプリ A はトークンをアプリ B に送信します。
アプリケーション B は、検証のためにトークンを認証局に送信します。
認証センターはトークンを検証し、検証に合格した場合は認可トークン（アクセストークン）を返します。
アプリケーション B は、認可トークンを使用して認証センターにアクセスし、ユーザー情報を取得します。
認証センターはユーザー情報をアプリケーション B に返します。
アプリケーション B は、ユーザー情報を使用してユーザーログインを完了します。

ユーザーがログインに成功すると、SSO認証センターと各サブシステムとの間でセッションが確立されます。ユーザーとSSO認証センター間で確立されるセッションをグローバルセッション、ユーザーと各サブシステム間で確立されるセッションを「グローバルセッション」と呼びます。ローカルセッションが確立されると、ユーザーはサブシステムの保護されたリソースに SSO 認証センターを通過しなくなり、グローバルセッションとローカルセッションには次の制約があります。

ローカルセッションが存在します。グローバルセッションが存在する必要があります。グローバルセッションが存在します。ローカルセッションは必ずしも存在する必要はありません。グローバルセッションは破棄されます。ローカルセッションは破棄する必要があります。

まず、ユーザーはシステム 1 の保護されたリソースにアクセスします。システム 1 は、ログインしていないことを検出すると、SSO 認証センターにジャンプし、独自のパラメーターを渡します。
SSO 認証センターは、ユーザーがログインしていないことを検出し、ユーザーをログインページに誘導します。
ユーザーはユーザー名とパスワードを入力し、SSO 認証センターに送信します。
SSO 認証センターはユーザー情報を検証し、ユーザーと SSO 認証センターの間にグローバルセッションと呼ばれるセッションを作成し、同時に認可トークンを作成します。
SSO 認証センターはトークンを取得して元の要求アドレス (システム 1) にジャンプします。
システム 1 はトークンを取得し、SSO 認証センターにアクセスしてトークンが有効かどうかを確認します。
SSO 認証センターはトークンを検証し、有効な登録済みシステム 1 アドレスを返します。
システム 1 は、このトークンを使用してユーザーとのセッション (ローカルセッションと呼ばれる) を作成し、保護されたリソースをユーザーに返します。
ユーザーがシステム 2 の保護されたリソースにアクセスする
システム 2 は、ユーザーがログインしていないことを検出し、SSO 認証センターにジャンプし、自身のアドレスをパラメータとして渡します。
SSO 認証センターは、ユーザーがログインしていることを検出し、システム 2 のアドレスにジャンプして戻り、トークンを添付します。
システム 2 はトークンを取得し、SSO 認証センターにアクセスしてトークンが有効かどうかを確認します。
SSO 認証センターはトークンを検証し、有効なトークンを返し、システム 2 のアドレスを登録します。
システム 2 は、このトークンを使用してユーザーとの部分セッションを作成し、保護されたリソースをユーザーに返します。

シングルサインオンの実装: 1.cookie+redis は、ユーザーの ID、IP をキーとして、ユーザーアカウントのパスワードデータ情報を値として redis に保存します。ユーザーの資格情報を cookie に保存し、ユーザーがログオンした後に暗号化されたメッセージを返します。 Cookie をシステムに取り込み、ユーザーが他のシステムにアクセスするときにこの Cookie を持ち込んで、sso 認証センターに確認し、検証に合格した後にログインします。 2、セッションブロードキャストユーザーがいずれかのシステムにログインすると、システムはサーバーはユーザーのログイン情報を別のシステムのサーバーにコピーしますこのうち、ユーザーが別のシステムにログインする際、サーバーはユーザー情報があるかどうかを確認し、あれば直接ログインします 3. トークンは jwt を使用して生成されます文字列、文字列にユーザー情報を保存し、Cookie またはアドレスバーを通じてそれを返します。フロントエンド。フロントエンドは、受信したトークンをリクエストまたは URL アドレスに保存します。各リクエストはリクエストを行うためのトークンを運ぶことができます。他のシステムにアクセスするときに、アドレスバーまたはリクエストヘッダーでトークンを取得し、文字列に従ってユーザー情報を取得すると、トークンをredisに配置して有効期間を設定できます

コード

1 Tomcat HTTPS サポート

注: キーストアを生成するときは、姓名とドメイン名を入力する必要があります。

# 1 生成密钥库
	1)d盘下面建一个文件夹cas，文件夹下面再建一个文件夹keystore(存放证书的地方)
	2)keytool -genkey -v -alias laohan -keyalg RSA -keystore D:\cas\keystore\laohan.keystore 
	输入口令（随便输，自己记得就行）
# 2 从密钥库导出证书
	keytool -export -trustcacerts -alias laohan -file D:/cas/keystore/laohan.cer -keystore D:/cas/keystore/laohan.keystore
# 3 将证书导入到JDK证书库
	keytool -import -trustcacerts -alias laohan -file D:/cas/keystore/laohan.cer -keystore "D:\java\jdk8\jre\lib\security\cacerts"
	密码：laohan
# 4 查看证书列表：
	keytool -list -keystore "D:\java\jdk8\jre\lib\security\cacerts"
# 5 删除证书
	keytool -delete -alias laohan -keystore "D:\java\jdk8\jre\lib\security\cacerts"

2 Tomcat 設定 https サポート

tomcat の下の conf の下にあるserver.xml ファイルを開き、保存するために保存します。プロトコルの最大スレッドにより ssl が有効になります。

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"  
               maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS"
			   keystoreFile="D:\cas\keystore\laohan.keystore"
			   keystorePass="laohan"/>

文字化けした conflogging.properties ファイルを見つけて次の設定変更を見つけ、UTF-8 を次の GBK に変更します。

 java.util.logging.ConsoleHandler.encoding = GBK

war パッケージをダウンロードして tomcat/webapp ディレクトリに置き、war パッケージの名前を cas.war に変更します。

ユーザー名とパスワードを変更する

D:\devlop\apache-tomcat-cas\webapps\cas\WEB-INF\classes    如果没有，先启动一下tomcat

找这个文件
application.properties

打开最后一行有用户名密码
cas.authn.accept.users=casuser::Mellon

https://localhost:8443/cas/login

3 サポートデータベースのパスワード

D:\devlop\apache-tomcat-cas\webapps\cas\WEB-INF\classes    

找这个文件
application.properties

cas.authn.jdbc.query[0].url=jdbc:mysql://localhost:3306/test?serverTimezone=GMT
cas.authn.jdbc.query[0].user=root
cas.authn.jdbc.query[0].password=root
cas.authn.jdbc.query[0].sql=select * from t_cas where username=?
cas.authn.jdbc.query[0].fieldPassword=password
cas.authn.jdbc.query[0].driverClass=com.mysql.cj.jdbc.Driver

cas.tgc.secure=false
cas.serviceRegistry.initFromJson=true

次のパッケージを D:\devlop\apache-tomcat-cas\webapps\cas\WEB-INF\lib に配置します。

4 データベース構成 t_cas

CREATE TABLE `t_cas` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `username` varchar(255) DEFAULT NULL,
  `password` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;

4サポートhttp

D:\devlop\apache-tomcat-cas\webapps\cas\WEB-INF\classes\services\HTTPSandIMAPS-10000001.json

http "serviceId" を追加します: "^(https|http|imaps)://.*",

4 Springboot の統合

1 インポート依存関係

<dependency>
    <groupId>net.unicon.cas</groupId>
    <artifactId>cas-client-autoconfig-support</artifactId>
    <version>2.3.0-GA</version>
</dependency>

<dependency>
    <groupId>org.jasig.cas.client</groupId>
    <artifactId>cas-client-core</artifactId>
    <version>3.6.2</version>
</dependency>

<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-cas</artifactId>
</dependency>

 <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-thymeleaf</artifactId>
</dependency>

2 アプリケーション.yml

server:
  port: 7777
cas:
  #  cas服务端地址
  server-url-prefix: https://www.laohan.com:8443/cas
  # 没有带票据或者票据过期,定义的就是服务端的登录地址
  server-login-url: https://www.laohan.com:8443/cas/login
  #  登录成功后回调的地址
  client-host-url: http://www.laohan.com:8888
  #  类型
  validation-type: cas3

3 表紙

<!DOCTYPE html>
<html  xmlns:th="http://www.thymeleaf.org">

    <head>
        <meta http-equiv="Content-Type" content="text/html" charset="UTF-8"/>
        <title>风展超市</title>
    </head>
    <body>
        欢迎：&nbsp;&nbsp;<font th:text="${session._const_cas_assertion_.principal.name}"></font>&nbsp;&nbsp;进入风展超市
        <br>
        <a href="http://www.laohan.com:7777" target="_blank">后台系统</a><br>
        <a href="http://www.laohan.com:8888" target="_blank">前台系统</a><br>
        <br><br>
        &nbsp;&nbsp; <a href="/logout">安全退出</a>
	</body>
</html>

4 バックエンド

@Controller
@EnableCasClient
public class IndexController {
    /**
     * 网站根目录请求
     * @return
     */
    @RequestMapping("/")
    public ModelAndView root(){
        //它可以返回前端页面
        ModelAndView modelAndView = new ModelAndView();
        modelAndView.setViewName("index");
        return modelAndView;
    }

    /**
     * 退出
     * @return
     */
    @RequestMapping("/logout")
    public String logout(){
        return "redirect:https://www.laohan.com:8443/cas/logout";
    }
}

5 異なるポートを持つ 2 つの同一のサーバーを構成する