.NET と Java EE という 2 つの異なるシステム間でのシングル サインオンのオプションを調査しています。それらはそれぞれ独立して管理され、一部の重複するユーザーとは別のユーザー管理があります。
パスワードを再度要求することなく、一方から他方にリンクできるようにしたいと思います。
SSO 製品とプロトコルには多くのオプションがあるようです。私は、自分自身の安全なトークンを生成して検証するために 1 回限りのコードを作成できるとかなり確信していますが、車輪を再発明したくはありません。
アプローチや製品 (できればオープン ソース) に関して、何をお勧めしますか?
まず、SAML、OpenID、OAuth をサポートするもの、または上記のいずれもサポートしないものを使用しますか?
2 つ目は、無料またはオープンソースの製品として、OpenAM、Shibboleth、JOSSO、および CAS を認識しています。良い、悪い、または醜い、それらのいずれかと共有する経験はありますか?
まず、プロトコルを見てみましょう。
SAML 2.0は、集中型/分散型 SSO プロトコルです。これは最も高度なプロトコルであり、フェデレーションを提供します。つまり、ユーザーが X システムのいずれかを使用してサインインできるようにしたり、単一のシステム (IDP と呼ばれる) を介してすべてのユーザーをチャネル化したりできます。SAML 2.0 は、いくつかの主要なホスト アプリケーション (Google アプリや Saleforce など) とともに、金融および政府部門で広く使用されています。最も複雑なプロトコルでもあります
OpenIDは分散型プロトコルであり、イントラネット/エクストラネット アプリケーションではなく、インターネットに最も適しています。ユーザーは、任意の OpenId プロバイダーからサインインすることを選択できます。Stackoverflow は OpenId の良い例です。Google または Facebook アカウントを使用してサインインすることを選択できます。消費するアプリケーション (Relying Party と呼ばれる) と SSO システム (Service Provider と呼ばれる) との間のデフォルトの関連付けを強制することにより、OpenId を一元的に実装できます。
OAuthは実際には SSO プロトコルではありません。これにより、ユーザーは、アプリケーション B の資格情報をアプリケーション A に提供することなく、アプリケーション A にアプリケーション B の自分の情報へのアクセスを許可できます。一部の人々は、システムがユーザー X に属する写真にアクセスできる場合など、疑似認証の形式として OAuth を使用しています。その場合、ユーザーは X でなければなりません。これはハックであり、推奨されません。
ロックインを避けるために、標準化されたプロトコルを使用することは間違いなく良い考えです。Microsoft は最近 SAML 2.0 のサポートを導入し、Java で利用できるオープン ソースおよび商用製品が多数あります。Java で利用できる OpenId の実装はありますが、.NET の世界についてコメントできるほどの知識はありません。
おっしゃったように、さまざまなオープン ソース SAML 製品 (OpenAM、Shibboleth、JOSSO、CAS) が利用可能です。1 つの注意点 - SAML は複雑なプロトコルであるため、オープン ソース ルートをたどる場合は、多少のハードワークを覚悟する必要があります。Cloudseal SSO プラットフォーム (SAML 2.0 ベース)を構築したとき、物事を単純化して複雑さを抽象化することに多くの時間を費やしました。他の商用ベンダーも同じことをしていますが、あなたが言及したオープンソース製品はシンプルさよりも機能性に重点を置いています - 私見! :)