インターフェースで表されるように、リソースサーバーがトークンをデコードする方法を提供します。アプリケーションを実行し、コマンドラインクライアントでホームページにアクセスします。SecurityContext"}また、ベアラートークンが必要であることを示す「WWW-Authenticate」ヘッダーを持つ401が表示されます。トークンをデコードする方法でリソースサーバーを接続する唯一の方法ではありません。Foundry、Githubなど)から非常に頻繁に利用でき、他の選択肢も利用できます。使用)か、共有バックエンドストアを使用します。エンドポイントもあり、ユーザー情報エンドポイントよりも詳細な情報を提供しますが、より完全な認証が必要です。さまざまなオプションが(当然)さまざまな利点とトレードオフを提供しますが、それらの詳細な説明はこのセクションの範囲外です。アノテーションも追加しました。これは、デフォルトで「/oauth/*」エンドポイントを除く認可サーバーのすべてを保護します。エンドポイントを配置したら、認可サーバーによって作成されたベアラートークンを受け入れるようになったため、それとグリーティングリソースをテストできます。localhost:9999/uaa/user{"details":...,"principal":{"username":"user",...},"name":"user"}(自分で認証サーバーから取得したアクセストークンの値を代入して、それを自分で動作させます)。完了する必要があるこのアプリケーションの最後の部分は、認証部分を抽出し、認可サーバーに委譲するUIサーバーです。OAuth2に置き換える必要があります。使用します(これにより、プロキシを介してトークンを中継するための自動構成が設定されます)。アノテーションを使用)。Gatewayとして機能し、YAMLでルートマッピングを宣言できることを思い出してください。そのため、「/user」エンドポイントを認可サーバーにプロキシできます。変更する必要があります。XHR要求は正常に戻ります。アノテーションには、適切な認可サーバーと通信して認証できるようにするためのいくつかの必須の外部構成プロパティもあります。http://localhost:9999/uaa/userその大部分は、OAuth2クライアント(「acme」)と認可サーバーの場所に関するものです。あります(リソースサーバーの場合と同様)。挿入する必要があります。context);}クライアントフロントエンドのUIアプリケーションには、認可サーバーへのリダイレクトをトリガーするためにまだ行う必要がある調整がいくつかあります。この簡単なデモでは、Angularアプリを必要最低限の要素にまとめて、何が起こっているかをより明確に確認できます。そのため、今のところ、フォームやルートの使用を控え、単一のAngularコンポーネントに戻ります。すべてを処理し、ユーザーの詳細と、成功した場合は挨拶を取得します。次に、この新しいコンポーネントのテンプレートを作成する必要があります。<app-root/>として含めます。(Angularルートではない)との通常のリンクであることに注意してください。Securityによって処理され、ユーザーが認証されない場合、認可サーバーへのリダイレクトが行われます。仕組みは?すべてのサーバーを一緒に実行し、http://localhost:8080のブラウザーでUIにアクセスします。Basicポップアップ)にリダイレクトされ、トークン付与(ホワイトラベルHTML)が認可されます。UIを認証したのと同じトークンを使用するリソースサーバー。一部の開発者ツールを使用すると、ブラウザーとバックエンド間の相互作用をブラウザーで確認できます(通常、F12はこれを開き、デフォルトでChromeで動作し、Firefoxでプラグインが必要になる場合があります)。概要は次のとおりです。動詞パス状況レスポンスGET/200index.htmlGET/*.js200角度からのアセットGET/user302ログインページにリダイレクトGET/login302認証サーバーにリダイレクトするGET(uaa)/oauth/authorize401(無視)GET/login302認証サーバーにリダイレクトするGET(uaa)/oauth/authorize200HTTP基本認証はここで発生するPOST(uaa)/oauth/authorize302ユーザーは許可を承認し、/loginにリダイレクトするGET/login302ホームページにリダイレクトGET/user200(プロキシ)JSON認証済みユーザーGET/app.html200ホームページのHTMLパーシャルGET/resource200(プロキシ)JSONグリーティング接頭辞(uaa)が付いた要求は、認可サーバーへのものです。「無視」とマークされた応答は、XHR呼び出しでAngularが受信した応答であり、そのデータを処理していないため、床にドロップされます。「/user」リソースの場合、認証されたユーザーを探しますが、最初の呼び出しには存在しないため、その応答はドロップされます。UIの「/trace」エンドポイント(一番下までスクロール)で、「/user」と「/resource」へのプロキシバックエンドリクエストが表示されます。Securityがこれを処理しました。あることを認識することで、(デフォルトで)プロキシされたバックエンドにトークンをリレーしたいことがわかります。前のセクションと同様に、「/trace」に別のブラウザーを使用して、認証のクロスオーバーが発生しないようにしてください(たとえば、UIのテストにChromeを使用した場合はFirefoxを使用します)。ログアウトエクスペリエンス「ログアウト」リンクをクリックすると、ユーザーがUIサーバーで認証されなくなるため、ホームページが変更される(グリーティングが表示されなくなる)ことがわかります。(ログアウトしていないため)。理想的なユーザーエクスペリエンスは技術的に実現可能ではないかもしれません。ユーザーが望むことを本当に望んでいることを疑わなければならないこともあります。「ログアウト」リンクをクリックしましたか?」興味がある場合は、このチュートリアルの後のセクションで詳細に説明されています。SecurityおよびAngularスタックの浅いツアーのほぼ終わりです。Gateway、リソースサーバー、認可サーバー/トークン付与者という3つの個別のコンポーネントに明確な責任を負う素晴らしいアーキテクチャがあります。すべてのレイヤーの非ビジネスコードの量は最小限になり、より多くのビジネスロジックを使用して実装を継承および改善する場所を簡単に確認できます。次の手順では、認可サーバーでUIを整理し、おそらくJavaScriptクライアントでのテストを含むいくつかのテストを追加します。Sessionの自動構成と、Angularピースのナビゲーションコントローラー用のいくつかのwebjarリソースを含むライブラリ(たとえば、「spring-security-angular」)に入れることです。Securityのいずれかの内部動作を学びたいと思っていた人はおそらく失望するでしょうが、それらがどのようにうまく機能し、少しの構成がどのように長くなるかを見たいなら方法、うまくいけば、良い経験をしたことでしょう。フィードバックを送信してください。シリーズの次のセクションでは、アクセス決定(認証以外)について説明し、同じプロキシの背後で複数のUIアプリケーションを使用します。ログインページを作成したのと同様に、きれいなログインページとユーザー承認ページが実装されているこのアプリケーションの別のバージョンがあります。使用してトークンをエンコードするため、リソースサーバーは「/user」エンドポイントを使用する代わりに、トークン自体から十分な情報をプルして単純な認証を行うことができます。使用する方法について引き続き説明します。Cloudを使用して、パートIIとIVで構築したシステムの機能を組み合わせ、実際にはまったく異なる責任を持つ3つの単一ページアプリケーションを構築する方法を示します。パートIVのような)ゲートウェイを構築することです。ゲートウェイを使用して認証をバックエンドに渡すことにより、パートIIのトークンの問題を単純化します。次に、システムを継承して、ゲートウェイでIDと認証を制御しながら、バックエンドでローカルで詳細なアクセス決定を行う方法を示します。これは、一般に分散システムを構築するための非常に強力なモデルであり、構築するコードに機能を導入する際に検討できる多くの利点があります。Basic資格情報を必ずクリアしてください。Chromeでこれを行う最善の方法は、新しいシークレットウィンドウを開くことです。ターゲットアーキテクチャ以下は、最初に構築する基本システムの写真です。このシリーズの他のサンプルアプリケーションと同様に、UI(HTMLおよびJavaScript)とリソースサーバーがあります。セクションIVのサンプルと同様に、ゲートウェイがありますが、ここではUIの一部ではなく、別個のものです。UIは事実上バックエンドの一部になり、機能を再構成および再実装するための選択肢がさらに広がります。これから説明する他の利点ももたらします。ブラウザはすべてのためにゲートウェイにアクセスし、バックエンドのアーキテクチャを知る必要はありません(基本的に、バックエンドがあることを知りません)。このゲートウェイでブラウザが行うことの1つに認証があります。セクションIIのようにユーザー名とパスワードを送信し、代わりにCookieを取得します。後続の要求では、Cookieが自動的に提示され、ゲートウェイはそれをバックエンドに渡します。Cookieの受け渡しを有効にするために、クライアントでコードを記述する必要はありません。バックエンドはCookieを使用して認証し、すべてのコンポーネントがセッションを共有するため、ユーザーに関する同じ情報を共有します。これと比較して、ゲートウェイでCookieをアクセストークンに変換する必要があり、アクセストークンはすべてのバックエンドコンポーネントで個別にデコードする必要があるセクションVと比較してください。セクションIVと同様に、ゲートウェイはクライアントとサーバー間の対話を簡素化し、セキュリティを処理するための小さく明確に定義された表面を提供します。ついて心配する必要はありません。これは間違いを犯しやすいため、歓迎されます。あるため、必要に応じてプロジェクトを複製し、そこから直接作業することができます。このシステムの終了状態には追加のコンポーネント(「二重管理者」)があるため、今は無視してください。サンプルに非常に似ていますが、実際にはログインページは必要ありません。サンプルからUIを取得することです。最初に使用したときのように)。<artifactId>spring-boot-starter-redis</artifactId></dependency>これは現在UIであるため、「/resource」エンドポイントは不要です。これを実行すると、非常に単純なAngularアプリケーション(「基本」サンプルと同じ)が作成され、その動作に関するテストと推論が大幅に簡素化されます。application.propertiesで)リッスンするデフォルト以外のポートを指定します。全体である場合、アプリケーションは安全であり、ランダムなパスワードを持つ「user」というユーザーがアクセスできますが、起動時にコンソール(ログレベルINFO)に出力されます。Securityが認証トークンとしてCookieを受け入れますが、Cookieが既に存在しない限り作成しないことを意味します。リソースサーバーリソースサーバーは、既存のサンプルの1つから簡単に生成できます。セクションIIIの「Springセッション」リソースサーバーと同じです。application.propertiesで)。NEVERこのチュートリアルの新しい機能であるメッセージリソースへの変更をPOSTする予定です。SecurityをAngularとうまく動作させるために通常のトリックを行う必要があります。アノテーションを追加するだけです。使用してスケルトンプロジェクトを生成することです。アプリケーション用です。セクションIと同じ一連のコマンドライン操作を使用します。Javaプロジェクト)をお気に入りのIDEにインポートするか、コマンドラインでファイルと「mvn」を操作するだけです。バージョンがありますが、まだ必要のない追加機能がいくつかあります。Session依存関係を追加します(上記のUIのように)。プロパティを使用してCookieをダウンストリームで渡します。Securityに常にセッションを作成するように伝えます)認証)。認証とセッションをゲートウェイで管理する必要があるため、この最後のビットは重要です。現在、3つのポートで実行される3つのコンポーネントがあります。Basicチャレンジを取得する必要があり、「ユーザー/パスワード」(ゲートウェイの資格情報)として認証できます。これを行うと、バックエンド経由でUIに挨拶が表示されます。プロキシを介してリソースサーバーに呼び出します。一部の開発者ツールを使用すると、ブラウザーとバックエンド間の相互作用をブラウザーで確認できます(通常、F12はこれを開き、デフォルトでChromeで動作し、Firefoxでプラグインが必要になる場合があります)。概要は次のとおりです。動詞パス状況レスポンスGET/ui/401認証のためのブラウザプロンプトGET/ui/200index.htmlGET/ui/*.js200AngularアセットGET/ui/js/hello.js200アプリケーションロジックGET/ui/user200認証GET/resource/200JSONグリーティングブラウザはホームページの読み込みを単一の対話として扱うため、401が表示されない場合があります。すべての要求はプロキシされます(管理用のアクチュエーターエンドポイントを超えて、ゲートウェイにはまだコンテンツがありません)。2つのバックエンドサーバーがあり、その1つはUIであり、それぞれが独立した機能を持ち、独立してテストすることができ、それらは制御し、認証を構成したセキュアゲートウェイと一緒に接続されます。ブラウザがバックエンドにアクセスできない場合は重要ではありません(実際、物理的なセキュリティをさらに制御できるため、おそらく利点です)。ログインフォームの追加セクションIの「基本」サンプルのように、ログインフォームをゲートウェイに追加できます。セクションIIからコードをコピーします。それを行うとき、ゲートウェイにいくつかの基本的なナビゲーション要素を追加することもできるため、ユーザーはプロキシのUIバックエンドへのパスを知る必要がありません。どこか)に挿入します。btn-primary">Submit</button></form></div>メッセージのレンダリングの代わりに、素敵な大きなナビゲーションボタンがあります。Interface</a></div>githubでサンプルを見ている場合、「ログアウト」ボタンのある最小限のナビゲーションバーもあります。スクリーンショットのログインフォームは次のとおりです。関数を実装するコンポーネントを含むTypeScriptが必要です。フラグを設定して、ユーザーが認証されているかどうかに応じてホームページのレンダリングが異なるようにする必要があります。関数の実装はセクションIIの実装に似ています。フラグを格納できます。この強化されたゲートウェイを実行する場合、UIのURLを覚える必要はなく、ホームページを読み込んでリンクをたどることができます。認証済みユーザーのホームページは次のとおりです。バックエンドでのきめ細かいアクセス決定これまでのアプリケーションは、機能的にはセクションIIIまたはセクションIVのものと非常によく似ていますが、専用のゲートウェイが追加されています。余分なレイヤーの利点はまだ明らかではないかもしれませんが、システムを少し拡張することで強調できます。ユーザーがメインUIでコンテンツを「管理」するために、そのゲートウェイを使用して別のバックエンドUIを公開し、この機能へのアクセスを特別なロールを持つユーザーに制限するとします。プロキシの背後に「管理」アプリケーションを追加すると、システムは次のようになります。application.ymlのゲートウェイには、新しいコンポーネント(Admin)と新しいルートがあります。http://localhost:9000「USER」ロールのユーザーが既存のUIを使用できることは、管理アプリケーションにアクセスするために「ADMIN」ロールが必要であるという事実と同様に、ゲートウェイボックス(緑色の文字)の上のブロック図に示されています。「ADMIN」ロールのアクセス決定は、ゲートウェイで適用できます。その場合、WebSecurityConfigurerAdapterに表示されるか、管理アプリケーション自体に適用できます(これを行う方法については後述します)。Bootアプリケーションを作成するか、UIをコピーして編集します。UIアプリで変更する必要はありませんが、最初に名前を変更する必要があります。管理アプリケーション内で、「READER」ロールと「WRITER」ロールを区別し、監査者であるユーザーに、メイン管理者ユーザーによる変更の表示を許可できるようにするとします。これはきめ細かいアクセス決定であり、ルールはバックエンドアプリケーションでのみ知られ、知られるべきです。ゲートウェイでは、ユーザーアカウントに必要なロールがあることを確認するだけでよく、この情報は利用可能ですが、ゲートウェイはそれを解釈する方法を知る必要はありません。ゲートウェイでは、ユーザーアカウントを作成して、サンプルアプリケーションを自己完結型に保ちます。}}「admin」ユーザーは3つの新しいロール(「ADMIN」、「READER」、「WRITER」)で拡張され、「ADMIN」アクセス権を持つ「audit」ユーザーも追加されましたが、「WRITER」アクセス権はありません。本番システムでは、ユーザーアカウントデータは、Spring構成でハードコードされていないバックエンドデータベース(ほとんどの場合、ディレクトリサービス)で管理されます。インターネットで簡単に見つけることができます。アクセスの決定は、管理アプリケーションで行います。Securityでそれを行います。}}「READER」ロールと「WRITER」ロールの場合、アプリケーション自体が分割されます。アプリケーションはJavaScriptに実装されているため、ここでアクセスを決定する必要があります。これを行う1つの方法は、計算されたビューがルーターを介して埋め込まれたホームページを持つことです。class="container"><h1>Admin</h1><router-outlet></router-outlet></div>ルートは、コンポーネントがロードされるときに計算されます。}...}アプリケーションが最初に行うことは、ユーザーが認証されているかどうかを確認し、ユーザーデータを見てルートを計算することです。ルートはメインモジュールで宣言されます。ChangesComponent}];これらの各コンポーネント(各ルートに1つ)は個別に実装する必要があります。同様ですが、バックエンドでメッセージを変更する形式があります。関数では次のように表示されます。エンドポイントが必要です。Securityのことです)。Security構成では必要ありません。Security構成では、"ロール"が操作の焦点であることはメソッド名から明らかです。管理UIをサポートするためのゲートウェイの変更ロールを使用してGatewayでもアクセスを決定します(したがって、管理UIへのリンクを条件付きで表示できます)。Gatewayの「/user」エンドポイントにも「ロール」を追加する必要があります。それができたら、JavaScriptを追加して、現在のユーザーが「ADMIN」であることを示すフラグを設定できます。リセットする必要があります。});}その後、HTMLで条件付きで新しいリンクを表示できます。Interface</a></div>すべてのアプリを実行し、http://localhost:8080に移動して結果を確認します。すべてが正常に機能し、現在認証されているユーザーに応じてUIが変更されます。私達、どうしてここに?これで、2つの独立したユーザーインターフェースとバックエンドリソースサーバーを備えたすてきな小さなシステムができました。これらはすべて、ゲートウェイで同じ認証によって保護されています。ゲートウェイがマイクロプロキシとして機能するという事実により、バックエンドセキュリティの関心事の実装が非常に簡単になり、ビジネス上の懸念に自由に集中できます。Sessionの使用により、(再び)膨大な量の手間と潜在的なエラーが回避されました。強力な機能は、バックエンドが任意の種類の認証を独自に持つことができることです(たとえば、物理アドレスと一連のローカル認証情報がわかっている場合は、UIに直接アクセスできます)。ゲートウェイは、ユーザーを認証し、バックエンドのアクセスルールを満たすメタデータをユーザーに割り当てることができる限り、完全に無関係な一連の制約を課します。これは、バックエンドコンポーネントを個別に開発およびテストできる優れた設計です。必要に応じて、ゲートウェイでの認証のために外部OAuth2サーバー(セクションVなど、またはまったく異なるもの)に戻ることができ、バックエンドに触れる必要はありません。このアーキテクチャのボーナス機能(認証を制御する単一のゲートウェイ、およびすべてのコンポーネントにわたる共有セッショントークン)は、セクションVで実装が困難であると判断した機能である「シングルログアウト」が無料で提供されることです。正確には、シングルログアウトのユーザーエクスペリエンスに対する特定のアプローチが完成したシステムで自動的に使用可能になります。ユーザーがUI(ゲートウェイ、UIバックエンド、または管理バックエンド)からログアウトすると、すべてのログアウトその他、個々のUIが「ログアウト」機能を同じ方法で実装したと仮定します(セッションを無効にします)。セクションIが公開されて以来、あまり変更されていませんが、他のすべての部分は読者からのコメントやインサイトに応じて進化しています。セクションを読んで議論に参加してくれた皆さんにも感謝します。使用する方法について引き続き説明します。ここでは、Angularテストフレームワークを使用して、クライアント側コードの単体テストを作成および実行する方法を示します。進むことができます(パートIと同じソースコードですが、テストが追加されています)。Securityを使用したコードはほとんどありませんが、通常のAngularコミュニティリソースでは簡単に見つけられない方法でクライアント側のテストを扱います。Springユーザー。Basic資格情報を必ずクリアしてください。Chromeでは、単一サーバーでこれを行う最良の方法は、新しいシークレットウィンドウを開くことです。仕様を書く「基本」アプリケーションの「アプリ」コンポーネントは非常にシンプルなので、徹底的にテストするのにそれほど時間はかかりません。コードのリマインダーは次のとおりです。オブジェクトを提供することです。オブジェクトの使用メソッドについてアサーションを作成できます。実際、その課題に直面する前であっても、コンポーネントインスタンスを作成できる必要があります。そのため、ロード時に何が起こるかをテストできます。以下にそのメソッドを示します。作成されたアプリのAngularビルドには、すでに仕様とそれを実行するための構成があります。app」にあり、次のように始まります。...}この非常に基本的なテストスイートには、次の重要な要素があります。(この場合は「AppComponent」)。コールバックを提供します。it()の呼び出しを通じて表現されます。ここでは、期待が何であるかを言葉で表明し、アサーションを行う関数を提供します。テスト環境は、他の何かが発生する前に初期化されます。これは、ほとんどのAngularアプリの定型です。ここでのテスト関数は非常に単純なため、実際にはコンポーネントが存在することをアサートするだけなので、それが失敗するとテストは失敗します。HTTPバックエンドのモック仕様を製品グレードに改善するには、コントローラーのロード時に何が起こるかについて実際にアサートする必要があります。呼び出すため、単体テストのためだけにアプリケーション全体を実行する必要がないように、その呼び出しをモックする必要があります。HttpClientTestingModuleを使用します。include::basic/src/app/app.component.spec[indent=0]ここでの新しい部分は次のとおりです。/」への呼び出しを期待するように伝え、応答をどうするかを伝えます。build)を実行できます。テストを実行する良い方法でもあります。CIビルドで何が起こるかです。エンドツーエンドのテストAngularには、ブラウザーと生成されたJavaScriptを使用した「エンドツーエンドテスト」用にセットアップされた標準ビルドもあります。ディレクトリに「仕様」として書き込まれます。実行すると、ブラウザーウィンドウがポップアップ表示されます)。結論Javascriptの単体テストを実行できることは、最新のWebアプリケーションでは重要であり、このシリーズではこれまで無視(または回避)したトピックです。今回の記事では、テストを記述する方法、開発時にテストを実行する方法、さらに重要なこととして、継続的インテグレーション設定の基本的な要素を導入しました。取ったアプローチはすべての人に適しているわけではないため、別の方法でやるのを気にしないでください。ここで行った方法は、おそらく従来のJavaエンタープライズ開発者にとって快適であり、既存のツールやプロセスとうまく統合できるため、そのカテゴリにいるなら、出発点として役立つと思います。ある可能性があります。このチュートリアルの「基本」サンプル用に記述する必要があるコード。使用する方法について引き続き説明します。ここでは、OAuth2サンプルを取得し、別のログアウトエクスペリエンスを追加する方法を示します。OAuth2シングルサインオンを実装する多くの人々は、「きれいに」ログアウトする方法を解決するためのパズルがあることに気付いていますか?それがパズルである理由は、それを行うための単一の正しい方法がないことであり、選択する解決策は、探しているユーザーエクスペリエンスと、引き受けたい複雑さの量によって決定されます。サンプルのログアウトのユーザーエクスペリエンスは、authserverからではなく、UIアプリからログアウトすることです。そのため、UIアプリに再度ログインしても、autheserverは資格情報を求めません。これは、autheserverが外部にある場合、完全に予期され、正常であり、望ましいです-Googleおよびその他の外部認証サーバープロバイダーは、信頼されていないアプリケーションからサーバーからログアウトすることを望んでおらず、許可もしません-しかし、認証サーバーが実際の場合、最高のユーザーエクスペリエンスではありませんUIと同じシステムの一部。大まかに言えば、OAuth2クライアントとして認証されたUIアプリからログアウトするための3つのパターンがあります。外部認証サーバー(EA、元のサンプル)。ユーザーは、認証サーバーをサードパーティーとして認識します(たとえば、FacebookまたはGoogleを使用して認証します)。アプリセッションの終了時に認証サーバーからログアウトする必要はありません。すべての助成金の承認が必要です。oauth2-vanilla)サンプルは、このパターンを実装しています。ゲートウェイおよび内部認証サーバー(GIA)。ログアウトする必要があるのは2つのアプリのみであり、それらはユーザーが認識する同じシステムの一部です。通常、すべての助成金を自動承認する必要があります。シングルログアウト(SL)。1つの認証サーバーと複数のUIアプリはすべて独自の認証を備えており、ユーザーが1つからログアウトすると、すべてのアプリがそれに追従する必要があります。ネットワークパーティションとサーバーの障害のために、単純な実装で失敗する可能性が高い-基本的には、グローバルに一貫したストレージが必要です。外部認証サーバーを使用している場合でも、認証を制御し、アクセス制御の内部レイヤー(認証サーバーがサポートしていないスコープやロールなど)を追加したい場合があります。次に、認証にEAを使用することをお勧めしますが、必要な追加の詳細をトークンに追加できる内部認証サーバーを用意します。サンプルは、非常に簡単な方法でそれを行う方法を示しています。その後、内部認証サーバーを含むシステムにGIAまたはSLパターンを適用できます。EAが必要ない場合のオプションは次のとおりです。ブラウザークライアントのauthserverおよびUIアプリからログアウトします。シンプルなアプローチであり、いくつかの注意深いCRSFおよびCORS構成で動作します。SLなしトークンが利用可能になり次第、authserverからログアウトします。authserverのセッションCookieがないため、トークンを取得するUIでの実装は困難です。認証コードが生成されるとすぐに、認証サーバーのセッションを無効にします。Githubの課題には、セッションの無効化を実装する側面が含まれていますが、HandlerInterceptorとして行う方が簡単です。SLなしUIと同じゲートウェイを介して認証サーバーをプロキシし、1つのCookieでシステム全体の状態を管理するのに十分であることを望みます。共有セッションが存在しない限り機能しません。共有セッションは、オブジェクトをある程度無効にします(それ以外の場合、authserverのセッションストレージはありません)。セッションがすべてのアプリ間で共有される場合にのみSL。ゲートウェイのCookieリレー。認証の真のソースとしてゲートウェイを使用しています。認証サーバーは、ブラウザーではなくCookieを管理するため、必要なすべての状態を保持しています。ブラウザに複数のサーバーからのCookieが含まれることはありません。SLなしトークンをグローバル認証として使用し、ユーザーがUIアプリからログアウトするときにトークンを無効にします。欠点:クライアントアプリによってトークンを無効にする必要がありますが、これは実際には意図されたものではありません。SLは可能ですが、通常の制約が適用されます。authserverで(ユーザートークンに加えて)グローバルセッショントークンを作成および管理します。採用したアプローチであり、SLにいくつかのオプションを提供しますが、いくつかの追加の機械が必要になります。通常の分散システムの制限から影響を受けるオプションはありません。ネットワークとアプリケーションノードが安定していない場合、必要に応じてすべての参加者間でログアウト信号が共有されるという保証はありません。バックチャンネルログアウト(英語)。SLが困難または不可能な場合、すべてのUIを単一のゲートウェイの背後に配置する方がよい場合があることに注意してください。次に、より簡単なGIAを使用して、不動産全体からのログアウトを制御できます。サンプルを取得して、そこから作業します)。ブラウザーからの両方のサーバーのログアウトUIアプリがログアウトされるとすぐにauthserverからログアウトするコードをブラウザクライアントに追加するのは非常に簡単です。}).subscribe();};このサンプルでは、authserverログアウトエンドポイントURLをJavaScriptにハードコードしましたが、必要に応じて外部化するのは簡単です。セッションCookieも一緒に送信するため、authserverに直接POSTする必要があります。XHRリクエストは、withCredentials:trueを明確に要求した場合にのみ、Cookieが添付されたブラウザから送信されます。逆に、リクエストは別のドメインから送信されるため、サーバーではCORS構成が必要です。source;}「/logout」エンドポイントには特別な扱いが与えられています。任意のオリジンからの呼び出しが許可され、資格情報(Cookieなど)の送信が明示的に許可されます。許可されるヘッダーは、Angularがサンプルアプリで送信するヘッダーのみです。ヘッダーを送信しないため、CORS設定に加えて、ログアウトエンドポイントのCSRFを無効にする必要があります。authserverはこれまでCSRF設定を必要としませんでしたが、ログアウトエンドポイントの無視を簡単に追加できます。...}CSRF保護をドロップすることは実際にはお勧めできませんが、この制限されたユースケースでは許容する準備ができているかもしれません。UIアプリクライアントとauthserverの2つの簡単な変更により、UIアプリからログアウトすると、再度ログインすると、常にパスワードの入力が求められることがわかります。1つの便利な変更点は、OAuth2クライアントを自動承認するように設定することです。これにより、ユーザーはトークンの付与を承認する必要がなくなります。これは、ユーザーが別のシステムとして認識しない内部認証サーバーでは一般的です。クライアントの初期化時にフラグが必要です。.autoApprove(true);}認証サーバーのセッションを無効化ログアウトエンドポイントでCSRF保護を放棄したくない場合は、他の簡単なアプローチを試すことができます。これは、トークンが許可されるとすぐに(実際は認証コードとなるとすぐに、認証サーバーのユーザーセッションを無効にする生成されます)。これも非常に簡単に実装できます。OAuth2エンドポイントに追加するだけです。RedirectViewを探します。これは、ユーザーがクライアントアプリにリダイレクトされていることを示す信号であり、場所に認証コードまたはエラーが含まれているかどうかを確認します。この簡単な変更により、認証するとすぐに、authserverのセッションはすでに停止しているため、クライアントからセッションを試行および管理する必要はありません。UIアプリからログアウトしてから再度ログインすると、認証サーバーはユーザーを認識せず、資格情報の入力を求めます。サンプルによって実装されたものです。このアプローチの欠点は、本当のシングルサインオンがもはやないことです。システムの一部である他のアプリは、authserverセッションが停止していることを発見し、再度認証を要求する必要があります。複数のアプリがある場合の優れたユーザーエクスペリエンス。結論このセクションでは、OAuth2クライアントアプリケーションからログアウトするためのいくつかの異なるパターンを実装する方法を見てきました(開始点としてチュートリアルのセクション5のアプリケーションを使用)。他のパターンのオプションについても説明しました。これらのオプションはすべてを網羅しているわけではありませんが、トレードオフの適切なアイデアと、ユースケースに最適なソリューションを検討するためのいくつかのツールを提供する必要があります。このセクションにはJavaScriptの行が2、3行しかなく、Angularに固有のものではなかったため(XHRリクエストにフラグを追加します)、このガイドのサンプルアプリの狭い範囲を超えてすべてのレッスンとパターンを適用できます。繰り返し発生するテーマは、複数のUIアプリがあり、単一の認証サーバーに何らかの欠陥がある傾向があるシングルログアウト(SL)へのすべてのアプローチです:できることは、ユーザーの不快感を最小限に抑えるアプローチを選択することです。内部authserverと多くのコンポーネントで構成されるシステムがある場合、単一のシステムのようにユーザーに感じる唯一のアーキテクチャは、すべてのユーザーインタラクションのゲートウェイである可能性があります。投稿ガイドラインを参照してください(GitHub)。リリースされています。GatewayOAuth2を使用したシングルサインオン複数のUIアプリケーションとゲートウェイAngularアプリケーションのテストOAuth2クライアントアプリケーションからのログアウト先にジャンプPivotalは、あなたの進歩を加速させるトレーニングと認定を提供します。Tomcat®のサポートとバイナリを提供します。1つの簡単なサブスクリプションで。学習したい方に(英語)今後のイベントSpringOneプラットフォーム(英語)9月21〜24日、シアトルSpringOneツアー(英語)最高のクラウドネイティブJavaコンテンツが直接提供されます。