OpenID
OpenID は、ユーザーが複数のアカウントや資格情報セットを管理することなく、複数のエンティティーに対して自身を認証できるオープン・スタンダードです。Liberty は OpenID 2.0 をサポートし、Web シングル・サインオンにおいてリライング・パーティーの役割を果たします。
- OpenID プロバイダー (OP)
- ユーザーが固有 ID を制御しているかどうかを表明できる OpenID 認証サーバー。
- リライング・パーティー (RP)
- ユーザーが固有 ID を制御していることの証拠を必要とするエンティティー。
- OpenID 識別子:
- OpenID プロバイダーまたはユーザーに属する HTTP または HTTPS の URL。
Web サイトなど、さまざまなエンティティーにアクセスするには、それぞれのエンティティーに関連付けられた固有のアカウントが必要になることがよくあります。OpenID により、OpenID プロバイダーによって処理される単一の資格情報セットで、OpenID をサポートする任意の数のエンティティーへのアクセスを許可できます。
OpenID をサポートし、リライング・パーティーとして機能する Web サイトなどのエンティティーにサインインする必要がある場合、ユーザーは、資格情報を RP 自体に提供するのではなく、OP と直接対話することで、認証を実行します。OP は、ユーザーの ID を検証し、認証確認を RP に返送します。RP は、この確認を OP から受信すると、認証されたものとしてユーザーを受け入れます。
標準的な OpenID 認証フローを以下に示します。
- ユーザーが、Web ページなどの保護リソースにアクセスしようとします。
- RP として機能している Liberty サーバーが、保護リソース用のフォーム・ログイン・ページを表示します。
- ユーザーが、OpenID ID を入力します。
- RP が ID を取得し、ユーザーを該当する OP にリダイレクトします。
- OP が、資格情報を求めるプロンプトをユーザーに出します。
- ユーザーが、OP に関連付けられているアカウントの資格情報を入力します。
- OP がユーザーを認証し、オプションとして、RP へのユーザー情報の提供を承認または拒否するように求めるプロンプトをユーザーに出し、その後、認証結果とともにユーザーを RP に再びリダイレクトします。
- OP での認証が成功した場合、RP が、ユーザーの許可を試行します。
- ユーザー許可が成功した場合、RP が、ユーザーとの認証済みセッションを確立します。

OpenID は、ユーザー資格情報または機密情報が誤った取り扱いを受ける可能性を最低限に抑えるのに役立ちます。OpenID では、ユーザーの資格情報は、OpenID プロバイダーのみと交換されます。つまり、OP 以外の Web サイトからユーザーの資格情報が可視になることはありません。この標準を使用することで、悪意のある Web サイトや安全ではない Web サイトによってユーザーの ID が漏えいしてしまう可能性を低減することができます。また、ユーザーは、訪問した Web サイトに共有する個人情報の量を制御します。例えば、ユーザーは、ある Web サイトにはユーザーの OpenID アカウントと関連付けられた名前および E メール・アドレスを共有することを許可し、別の Web サイトには E メール・アドレスを提供しない、あるいは、何も情報を提供しないことを選択できます。
サポートされる OpenID 標準仕様は次のとおりです。
E メールなどの一部の OpenID 属性は、OpenID プロバイダーによって検証されない可能性があることが分かっています。プロバイダーが検証済み E メール・アドレスを提供していると信頼できない場合は、WebSphere Application Server で認証済みユーザー名としてプロバイダーの E メールは使用してはなりません。