既存のアカウントとサービスプロバイダの間のSAML

Question

背景： ユーザー名（電子メール）とパスワードを持つ基本的なユーザーデータベースがあります。ユーザーは、これらの資格情報で私のWebサイトにサインインすることができます。ウェブサイトからは、アクセス可能な異なるサービスへのリンクが得られますが、ユーザー名とパスワードは異なります。そこで彼らは "My Service Xを開く"というリンクをクリックし、サービスの一意のログイン資格情報でログインする必要があります。私はユーザーサービスのログインユーザー名を持っています。だから私はローカルユーザ< =>サービスユーザをマップすることができます。

SAMLと私のWebサイトをサポートするサービスXの間にSSOが必要です。

質問/問題： は、私は、ユーザーが自分のデータベース内のユーザー/パスワード、サービスXがSAMLをサポートしているサービスXに向けた上、その後のシングルサインを使ってログインします。私は、サービスXのSAMLサポートを使用して、ユーザーが自分のウェブサイトに新しいユーザーアカウントを登録できるようにしたくありません。ユーザーは既にデータベースにアカウントを持っている必要があります。

私の質問はむしろあいまいかもしれませんが、これがどのように達成できるか把握するのに苦労していますか？

ウェブアプリケーションをSAMLアイデンティティプロバイダにすることを考えていました。そのため、SSOリクエストは私のwebappに戻され、サービスユーザのために確認されました。それが正しいアプローチだろうか？

Answer 1

あなたはSAMLIdPで正しい軌道に乗っています。基本的には3つの部分があります。あなたの電子メールデータベース（アイデンティティ）、既存のアプリケーションフロントエンド、およびSAMLをサポートするリモートサービス最近は通常、SAML2です。アプリケーションのポートフォリオ全体でのシングルサインオン（SSO）を取得するに

（独自のアプリやリモートサービス）あなたがShibboleth IdPようIdPをインストールし、あなたのアプリがログインする電子メール/パスワードを使用するのではなく、それを使用して変換することができ。これは、リモートサービスと同じように、アプリをSAML SPに変換する必要があるため、かなりの労力を要します。

もっと簡単な方法は、リモートサービスにSAML用のIdPを使用し、IdPにユーザーが既に電子メール/パスワードでログインしていることを認識させることです。クッキー？したがって、IdPはログインページを表示することは決してありません。これは、アプリケーションのCookieを認識し、データベース内のユーザーと一致させるためです。次に、そのユーザーの情報に基づいてSAML属性をリモートサービスに解放します。これは、リモートサービスからのSAML経由のアカウント作成を許可しないというユースケースもカバーしています。あなたは以下のURLで終わるかもしれない意味します

：

• https://yourapp.com/
• https://yourapp.com/idp/

あなたのユーザーは、通常のように最初のURLにログインし、リモートサービスは、2番目のURLを使用します。そうすれば、あなたのアプリケーションのクッキーは/ idpエンドポイントに見えるようになりますが、それをデータベースのユーザーと一致させるコードを書く必要があります。