integration - レガシー アプリケーションでのシングル サインオンの戦略

Question

レガシー アプリケーションでのサインオンを減らすために人々がどのような戦略を使用し、それらがどの程度効果的であるかを知りたいのですが?

私たちは ASP.Net ベースのイントラネットを所有しており、多くのレガシー アプリケーションを所有していますが、すべてではありません。また、BizTalk もあり、その SSO エンジンも使用することを検討しています。

Answer 1

労力/やり直しとシングル サインオンの利便性との間の適切な妥協点は、従来のアプリでユーザー、特権、ロールなどのリストを維持し続けることです。ユーザー アカウント (通常は Windows アカウントまたはネットワーク アカウント) に基づいて、ユーザーをアプリケーションに自動的にログインさせるために必要な変更を行います。

私は現在、このサインオン方法を使用するいくつかのアプリケーションを実行しています。統合されていないにもかかわらず、より統合されているように見えます。

私たちが見つけたもう 1 つの利点は、人々がレガシー アプリケーションにパスワードを共有するのを防ぐことです。他の人が自分の電子メールや給与の詳細にアクセスできるようにする管理者パスワードを配布する可能性ははるかに低くなります。

Answer 2

アプリケーションごとに複数の ID ストレージ? シングル サインオン ソリューションではないかもしれませんが、MS Identity Lifecycle Manager のようなよりターゲットを絞ったソリューションを検討してみましたか? アプリケーション間の ID 同期を簡素化し、プラグインも可能です。つまり、独自のコードを接続して、異なるシステム間で同期を行うことができます。そのため、ILM ポータルで ID 情報 (つまり、ログイン情報) を変更すると、それらを別のシステムに伝達できます。ID のプロビジョニングとプロビジョニング解除についても同じことが言えます。単一のエントリ ポイント。
同様の用途でbiztalkも使えると思います。

真のシングル サインオン ソリューションについては、一度ログインするだけで、別のアプリケーションに再度ログインする必要はありません。私はまだそれを見つけていません。

レガシー アプリにプラグイン可能な ID プロバイダー モジュールがあれば、それは実行可能です。つまり、ログイン システムをカスタマイズして、信頼できる単一の ID ソースに接続することができます。

Answer 3

従来のアカウントで 2 つのことを行いました。(従来の Web ベースのアプリ)

まず、従来のアカウントをシステム ログオン アカウント (Windows Active Directory で実行) にマッピングしました。

次に、レガシー アプリケーション (Web ベース) の上にファサード ログオン画面が適用されました。これにより、AD ログオンが要求され、レガシー アプリケーションのログオン アカウントに逆マップされ、レガシー アプリケーションを使用して適切な権限がユーザーに割り当てられます。システム セキュリティ モデル。ユーザーは、ドアを開いたままにするセッションのトークンを受け取りました。

これにより、従来のアプリを改造する必要がないという利点が得られました (たとえば、アプリ x には ID の番号しかなく、ユーザーは Windows ログオン (英数字) を使用し、クライアントの観点から疑似シングル サインオンも実現します)。

意味のあるもう1つのオプションは、新しいログオン画面で、複数のセキュリティリポジトリをチェックするため、ユーザーがWindowsログオンを使用することを決定しなかった場合でも、従来のアカウント名でログオンできました. 明らかに、これにはいくつかの副作用がありますが、エンド ユーザーがシステム間を移動する際に感じることがある移行の苦痛を軽減するのにも役立ちます。

この問題に対してまったく異なるアプローチをとるCitrix XenApp Single Signonのようなプログラムもあります。

Answer 4

ILM の使用に関する Jimmy のポイントに加えて、この特定のシステムでは AD PCNS (Password Change Notification Service) サービスとの統合が可能であり、ILM で使用できます (ILM はパスワード変更イベントを「認識」し、それを他の消費アプリケーションに発行できます)。 /サービス) 少なくとも、あるシステムでユーザーのパスワードが変更されると、それが他のシステムに反映されるようにします。