4

基本的にルビー (レール、シナトラなど) で、分散システムのアーキテクチャに取り組んでいます。

API_C1、API_C2、API_C3 など、いくつかの純粋な API のみのコンポーネントがあります。これには、いくつかの Web クライアント アプリケーション (Portal1、Portal2 など) と、いくつかのネイティブ クライアント アプリケーション (Native1 など) があります。

要件：

  1. すべての Web クライアント (Portal1、Portal2) の SSO、集中認証。
  2. すべての API コンポーネントは、承認を得て API を公開する必要があります。
  3. 一元化された API 承認。

いくつかのオプションを試すためにいくつかの POC を実行しましたが、まだ全体像がわかりません。

SSO用のrubycasサーバーを試しました。それはかなりうまくいきます。必要に応じて、Java cas 実装を使用することを検討します。

一元化された API 承認は、私にとってはややこしいものです。私は OAuth2 を使用する傾向がありますが、いくつか質問があります。

  1. すべての API コンポーネントを提供する一元化された OAuth プロバイダーを持つことは可能ですか? その場合、どのように機能し、どのライブラリ/ジェムを使用する必要がありますか?
  2. Web アプリ (Portal1 と Portal2) を既定で信頼できるようにするにはどうすればよいですか? 信頼できるアプリケーションへのアクセスをユーザーに許可してほしくありません。

  3. ネイティブ クライアント アプリ (非 Web 環境) の場合、2 レッグ OAuth をサポートしたいと考えています。正しい選択ですか？3本足と2本足の両方を稼働させることは可能ですか?

  4. ユーザー資格情報はどのように oauth トークンに変換されますか? 次の使用例を想定します。

    • ユーザーが (CAS サーバー経由で) Portal1 にログインし、いくつかのページを開きます
    • Portal1 バックエンド サーバーは、API_C1 と API_C2 からデータをプルして、ページを表示する必要があります。ここでAPIを承認する方法は?

同じ SSO CAS セッションで API コンポーネントを使用するような考えがあります。これにより、私のシナリオ 4) が解決され、ここでコーディングする必要がなくなります。しかし、API にセッションを使用するのは悪い習慣であり、API にセッションと OAuth 承認を混在させるにはどうすればよいでしょうか?

どうか、私を正しい方向に向けてください。SSO をサポートするために、カスタマイズされた OpenId や OAuth プロバイダーなど、あらゆることを行うためのオプションが他にいくつかあるのではないでしょうか?

4

1 に答える 1

2

これは古い質問 (2 年前) ですが、誰かが同様の問題を解決しようとしている場合に備えて、ここに回答を残します。

OAUTH の使用を考えて正しい方向に進んでいると思いますが、OAUTH プロトコルのバージョン 2.0を使用することをお勧めします。

集中承認

すべての API コンポーネントを提供する一元化された OAuth プロバイダーを持つことは可能ですか? その場合、どのように機能し、どのライブラリ/ジェムを使用する必要がありますか?

  • OAUTH 2.0 では、承認サービスをスタンドアロンのシステム/サービスとして動作させることで、このシナリオを可能にします。システム内の他のサービスは、そのサービスを信頼し、発行されたトークンを検証する方法を知ることができます (x.509 証明書公開鍵を使用することにより)。例えば）

  • Auth0のように、セットアップ費用なしで使用できる SaaS ベースの認証サーバーがあります。

ウェブ クライアント

Web アプリ (Portal1 と Portal2) を既定で信頼できるようにするにはどうすればよいですか? 信頼できるアプリケーションへのアクセスをユーザーに許可してほしくありません。

  • リソース所有者のパスワード grantを使用すると、ユーザー (リソース所有者) はusername&passwordと既知のclient_id(既知の HTTP オリジンに関連付けることもできる) を使用してクライアント (Web サイト/ポータル/アプリ) に対して認証されます。

  • または、ポータルがユーザーを既知の承認サービス URL にリダイレクトし、ユーザーがそこで認証するためのいくつかの URL パラメーターを使用してポータルにリダイレクトされる承認コード付与。

ネイティブ アプリ

ネイティブ クライアント アプリ (非 Web 環境) の場合、2 レッグ OAuth をサポートしたいと考えています。正しい選択ですか？

  • OAuth 2.0 では、このシナリオでクライアント資格情報の付与を使用します。このシナリオでは、client_id&を保存し、client_secretそれらを承認サーバーに送信して、信頼できるクライアントとして認証することができます (ユーザー資格情報は必要ありません)。

すべてを混ぜ合わせる

3本足と2本足の両方を稼働させることは可能ですか?

  • 上記の OAuth 2.0 の許可タイプはすべて、同じ認証サービス/サーバーで連携できます (私の知る限り、実際には Microsoft OWIN for ASP.netで動作しています) 。

ユーザー資格情報はどのように oauth トークンに変換されますか? 次の使用例を想定します。

  • 承認サービスには、クライアントがフォームを投稿したり、リダイレクトして取得するために使用するエンドポイント (url) がありますaccess_tokenが、実際の方法は、使用している認証フロー (投稿とリダイレクト) によって異なります。

ユーザーは (CAS サーバー経由で) Portal1 にログインし、いくつかのページを開きます。ここでAPIを承認する方法は?

  • リソース所有者のパスワード許可を使用して、ユーザーがusername&passwordを portal1 に入力すると、access_tokenが取得されます。次に、portal1 が API_C1 を呼び出しているときに、 をaccess_token呼び出しに添付するだけです (HTTP ヘッダー: Authorization) (ログイン ユーザーになりすます) 。

  • 認証コード許可を使用して、ユーザーは Auth Service にリダイレクトされ、そこで資格情報を入力し、その後、access_tokenAPI_C1 への呼び出しに添付されて、ログインしているユーザーになりすます

類似のトピック

最後に、あなたの質問に関連する同様の回答をチェックしてください

于 2016-02-16T23:08:36.307 に答える