0

内部リレーショナルデータベースに認証および承認データを保持するレガシーカスタム「IDハブ」があります。LDAPやActiveDirectoryなどはありません。「IDハブ」は、カスタムの「ログイントークン」を使用して動作するカスタムのレガシーAPIを公開します。ログイン操作が正常に呼び出されると、認証情報などの取得に再利用されるトークンが返されます。

「IDハブ」を再設計して、その認証データをLDAPインターフェイスを提供する適切なディレクトリに抽出できるようにします。ユーザー名が認証と承認のエントリを照合するための「キー」になることを考えると、IDハブのインターフェイスは変更せずに維持できると思いますが、実装は次のように調整されます。IDハブから認証ディレクトリへのアクセス。私のアプリケーションはIDハブに依存しているため、IDハブのレガシーインターフェイスはまだ廃止できません。

私の問題は次のとおりです。2番目のステップでは、IDハブを最新化して、役割を切り替える必要があります。アプリケーションは、認証専用ではなくなった前述のディレクトリにアクセスしますが、承認インターフェイスも公開します(例: LDAPを使用)、「IDハブ」の代わりにエントリポイントとして機能します。同時に、認証データが従来の「IDハブ」に保持されることが重要です。

私の質問は、「IDハブ」をそのディレクトリから信頼できる方法で呼び出すことができるようにするにはどうすればよいですか。つまり、「IDハブ」が認証されたユーザーに関する「フロントエンドディレクトリ」からの信頼できる情報を必要とするという問題を解決するにはどうすればよいですか。 ?2つのコンポーネントは共通の信頼できる環境で実行されますが、唯一の情報としてユーザー名(=ジョイント、主キー)を渡したくありません。

ディレクトリとレガシーIDハブの間で使用できるインターフェイスはどれですか?これはSAML2.0またはLDAPを使用して可能ですか?また、ディレクトリがKerberosを介してユーザーを認証する場合も考慮する必要があります。

アドバイスをいただければ幸いです。

ミク

4

1 に答える 1

0

ディレクトリとIDハブの間で使用できるインターフェイスを尋ねます。これは、両方に共通するプロトコルによって異なります。

ディレクトリの前にSAMLIDPを配置すると、SAMLを使用できます。IDハブがコース外のSAMLをサポートしている場合。その場合、SAMLが1つの方法になります。私は認証情報を交換するための業界標準です。

于 2013-01-30T20:00:52.777 に答える