タグ付けされた質問 「single-sign-on」

5
CASまたはOAuthを使用したSSO?
シングルサインオンにCASプロトコルまたはOAuth +一部の認証プロバイダーを使用する必要があるのか​​と思います。 シナリオ例: ユーザーが保護されたリソースにアクセスしようとしましたが、認証されていません。 アプリケーションはユーザーをSSOサーバーにリダイレクトします。 認証されている場合、ユーザーはSSOサーバーからトークンを取得します。 SSOは元のアプリケーションにリダイレクトします。 元のアプリケーションは、SSOサーバーに対してトークンをチェックします。 トークンに問題がなければ、アクセスが許可され、アプリケーションはユーザーIDを認識します。 ユーザーはログアウトを実行し、接続されているすべてのアプリケーションから同時にログアウトされます(シングルサインアウト)。 私が理解している限り、それはまさにCASが発明したものです。CASクライアントは、認証サービスを使用するためにCASプロトコルを実装する必要があります。今、私はクライアント(コンシューマー)サイトでCASまたはOAuthを使用することを考えています。OAuthはCASのその部分の代替品ですか?新しい事実上の標準としてのOAuthを優先すべきですか?ユーザー名/パスワード、OpenID、TLS証明書などのさまざまな方法をサポートするCASの認証部分の使いやすい(Sun OpenSSOではありません!)置き換えはありますか? 環境: さまざまなアプリケーションがSSOサーバーの認証に依存し、セッションのようなものを使用する必要があります。 アプリケーションは、GUI Webアプリケーションまたは(REST)サービスにすることができます。 SSOサーバーは、ユーザーIDを提供する必要があります。これは、中央のユーザーインフォメーションストアからロールや電子メールなどのユーザーに関する詳細情報を取得するために必要です。 シングルサインアウトが可能である必要があります。 ほとんどのクライアントはJavaまたはPHPで記述されています。 OAuthの後継となる可能性のあるWRAPを発見しました。これは、Microsoft、Google、Yahooによって指定された新しいプロトコルです。 補遺 OAuthは、SSOを実装するために使用することもできますが、OpenIDのようなSSOサービスと一緒にのみ使用できるように認証用に設計されていないことを知りました。 OpenIDは「新しいCAS」のようです。CASにはOpenIDが欠落する機能(シングルサインアウトなど)がいくつかありますが、特定のシナリオで欠落しているパーツを追加することは難しくありません。OpenIDは広く受け入れられていると思います。OpenIDをアプリケーションまたはアプリケーションサーバーに統合することをお勧めします。CASもOpenIDをサポートしていることは知っていますが、CASはOpenIDを必要としないと思います。

3
クロスドメイン認証にJWTを使用するシングルサインオンフロー
WebにはJson Web Token、認証にJWT()を使用することに関する多くの情報があります。しかし、マルチドメイン環境でシングルサインオンソリューションに JWTトークンを使用する場合のフローの明確な説明はまだわかりませんでした。 私は、さまざまなホスト上に多数のサイトがある会社で働いています。example1.comとexample2.comを使用してみましょう。シングルサインオンソリューションが必要です。つまり、ユーザーがexample1.comで認証された場合、そのユーザーもexample2.comで自動的に認証されるようにします。 OpenId Connectフローを使用して、example1.comで認証するユーザーが最初に認証サーバー(またはOP「OpenIdプロバイダー」)にリダイレクトされることを理解しています。ユーザーはそのサーバーで認証され、署名されたJWTトークンを使用して元のexample1.comサイトにリダイレクトされます。(後でそれ自体が実際のJWTトークンと交換できる中間トークンを返す別のフローがあることを理解していますが、これは私たちには必要ではないと思います)... これで、ユーザーはexample1.comに戻り、認証されました。AuthenticationヘッダーでJWTトークンを渡して要求を出すことができ、サーバーは署名されたJWTを検証できるため、ユーザーを識別できます。いいね! 最初の質問: JWTトークンはどのようにクライアントに保存する必要がありますか?繰り返しになりますが、これについては多くの情報があります。人々Web Storageは、古き良き時代というよりは、使用することが道のりであることに同意しているようですcookies。JWTをブラウザーの再起動間で永続的にしたいのでLocal Storage、ではなくを使用しましょうSession Storage... これで、ユーザーはブラウザを再起動でき、JWTトークンの有効期限が切れていない限り、example1.comで認証されます。 また、example1.comが別のドメインにAjaxリクエストを行う必要がある場合、CORSを構成するとそれが可能になることを理解しています。ただし、主な使用例はクロスドメインリクエストではなく、シングルサインオンソリューションです。 したがって、主な質問: ここで、ユーザーがexample2.comにアクセスして、すでに持っているJWTトークンを使用して認証されるようにした場合、フローはどうなりますか?Local Storageはクロスドメインアクセスを許可していないようです。そのため、この時点ではブラウザはJWTトークンを読み取ってexample2.comにリクエストを送信できません。 する必要があります: ユーザーは再び認証サーバーにリダイレクトされますか?ユーザーがexample1.comに対して認証されると、 認証サーバーはユーザーにCookieを設定している可能性があるため、example2.comに対するこの新しい認証要求はそのCookieを使用して、ユーザーがすでに認証されていることを確認し、すぐにexample2.comにリダイレクトします 。同じJWTトークンで? または、ブラウザがexample2.comで、認証サーバーに再度アクセスすることなくJWTトークンにアクセスできますか?私はそこにある参照クロスストレージ・ソリューションは、しかし、それらの広く使用されていますか?それらは、クロスドメインSSO環境の推奨ソリューションですか? 私たちは空想したいものは何もありません、私たちは主に使用されるソリューションで満足します!

4
複数のドメインにわたるシングルサインオン[終了]
現在のところ、この質問はQ&A形式には適していません。私たちは回答が事実、参考文献、専門知識によってサポートされることを期待しますが、この質問はおそらく議論、議論、投票、または拡張された議論を誘います。この質問が改善され、場合によっては再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 当社には複数のドメインが設定されており、それぞれのドメインでホストされている1つのウェブサイトを使用しています。現時点では、各ドメインには、Cookieを介して行われる独自の認証があります。 あるドメインにログオンしたユーザーが別のドメインの何かにアクセスする必要がある場合、ユーザーは他のドメインにある他のWebサイトで別の資格情報を使用して再度ログインする必要があります。 この手間を省くことができるように、シングルサインオン(SSO)に移行することを考えていました。私はこの点についての経験がありませんので、これがどのように達成されるかについてのアイデアをいただければ幸いです。 ありがとう。 編集: Webサイトは、インターネット(外部)とイントラネット(社内で使用)のサイトが混在しています。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.