3

仕事では、高度にモジュール化されており、相互に強い依存関係を持つべきではない複数のシステムを開発しています。ここで、これらのシステムが認証とセキュリティの共通のメカニズム、つまりSSO（シングルサインオン）を共有する必要があります。承認、認証、セキュリティの管理を扱う別のモジュール、SSOモジュールを作成する必要があることは明らかです。重要なのは、他のシステムと適切に統合することです。

私が考えることができる2つのアプローチは次のとおりです。

1）認証および承認操作を他の2つのシステムで実行できるようにするRESTfulサービスをSSOから公開します。

2）認証と承認用の共通APIを公開します。これにより、SSO機能がラップされ、2つのシステムがAPIを参照して直接使用するようになります。

現時点では、この分野でサードパーティのソリューションを使用することは検討しておらず、SSOモジュールについてはすでにいくつかの作業を行っているため、既存の取り組みを最大限に活用するシンプルなソリューションに固執することをお勧めします。

どのアプローチを選択する必要があり、その理由は何ですか？それぞれの重要な利点は何ですか？より良い代替案はありますか？

4

1 に答える 1

1

「RESTに公開する必要がありますか、それともAPIでラップする必要がありますか？」

両方の長所を目指してください。

  1. 認証および承認モジュールをRESTfulサービスとして公開し、各モジュールに選択された言語、フレームワーク、またはプラットフォームに関係なく、最大の相互運用性を実現します。HTTPを介して通信できるものなら何でも使用できます。
  2. 次に、RESTfulサービスと通信する選択した言語のライブラリを開発します。これにより、複数のモジュールが一元化された認証メカニズムを簡単に使用できるようになります。したがって、モジュールに使用する言語に応じて、ruby、javaなどで記述された小さなクライアントがあります。

この種のコードの再利用は、サービス指向アーキテクチャーの主要なテナントの1つであり、私の意見ではそうです。数人の同僚と私は、BrightTagや他の企業での経験に基づいた最近のプレゼンテーションで、これについてさらに詳しく説明しました。

CASのような多くの「エンタープライズ」SSOシステムは、非常によく似たアプローチを使用します（ただし、CASプロトコルはRESTfulではありません）。より高度な機能が必要な場合は、CASをぜひご覧ください。

于 2012-10-19T02:20:04.187 に答える