基本的にルビー (レール、シナトラなど) で、分散システムのアーキテクチャに取り組んでいます。
API_C1、API_C2、API_C3 など、いくつかの純粋な API のみのコンポーネントがあります。これには、いくつかの Web クライアント アプリケーション (Portal1、Portal2 など) と、いくつかのネイティブ クライアント アプリケーション (Native1 など) があります。
要件:
- すべての Web クライアント (Portal1、Portal2) の SSO、集中認証。
- すべての API コンポーネントは、承認を得て API を公開する必要があります。
- 一元化された API 承認。
いくつかのオプションを試すためにいくつかの POC を実行しましたが、まだ全体像がわかりません。
SSO用のrubycasサーバーを試しました。それはかなりうまくいきます。必要に応じて、Java cas 実装を使用することを検討します。
一元化された API 承認は、私にとってはややこしいものです。私は OAuth2 を使用する傾向がありますが、いくつか質問があります。
- すべての API コンポーネントを提供する一元化された OAuth プロバイダーを持つことは可能ですか? その場合、どのように機能し、どのライブラリ/ジェムを使用する必要がありますか?
- Web アプリ (Portal1 と Portal2) を既定で信頼できるようにするにはどうすればよいですか? 信頼できるアプリケーションへのアクセスをユーザーに許可してほしくありません。
ネイティブ クライアント アプリ (非 Web 環境) の場合、2 レッグ OAuth をサポートしたいと考えています。正しい選択ですか?3本足と2本足の両方を稼働させることは可能ですか?
ユーザー資格情報はどのように oauth トークンに変換されますか? 次の使用例を想定します。
- ユーザーが (CAS サーバー経由で) Portal1 にログインし、いくつかのページを開きます
- Portal1 バックエンド サーバーは、API_C1 と API_C2 からデータをプルして、ページを表示する必要があります。ここでAPIを承認する方法は?
同じ SSO CAS セッションで API コンポーネントを使用するような考えがあります。これにより、私のシナリオ 4) が解決され、ここでコーディングする必要がなくなります。しかし、API にセッションを使用するのは悪い習慣であり、API にセッションと OAuth 承認を混在させるにはどうすればよいでしょうか?
どうか、私を正しい方向に向けてください。SSO をサポートするために、カスタマイズされた OpenId や OAuth プロバイダーなど、あらゆることを行うためのオプションが他にいくつかあるのではないでしょうか?