動作概要
Claimed Identifierの宣言
End UserがどのようにしてConsumerに対して、自分のClaimed Identifierを認証するIdP（Identity Provider）を知らせるか？
IdPの宣言
- End Userは、自分のClaimed Identifierを認証してくれるIdPを明示する必要がある。
- この明示の仕方は具体的には、そのClaimed IdentifierをWebブラウザで開いたときに表示されるhead要素の中にlink要素として記載。
<link rel="openid.server" href="http://example.openid-idp.com/server" />
- link要素の各属性
- rel ： openid.server と記載
- href ： IdPが提供するサーバのエンドポイントURLを記載
- IdPの宣言。HTML文書中の宣言がこの1つで済むのは、サーバのエンドポイントURLが同一ホストにある場合のみ(サブドメインは異なっても構わない)
Delegateの仕組み
- End UserがClaimed Identifierとして用いるURLのホストと同一ホストで、IdPを立ち上げなければならないわけではありません。
- 自分のClaimed Identifierを認証する認証サーバーと、認証サーバーと同一ホストにあるIdentifierの明示によって、元のClaimed Identifierの認証を外部の認証サーバーに委ねることが可能。
- head要素の子要素
<link rel="openid.server" href="http://example.openid-idp.com/server" /> <link rel="openid.delegate" href="http://example.openid-idp.com/user/zigorou" />
- link要素の各属性
- rel ： openid.delegateと記載
- href ： IdPと同一ホストのClaimed Identifierとして使用するURLを記載
URLをIdentifierとするメリットとデメリット
- メリット
- OpenIDではIdentifierはURLそのものであり、なおかつopenid.server、openid.delegateの解決のためにHTML、もしくはXHTMLで表現する必要がある。
- デメリット
- 認証サーバーは分散モデルなので複数存在することから、それらの認証サーバーを手放しに信頼してよいかどうか判断ができない。
- 信頼できない認証サーバーで認証されたIdentifierへの認可はどのように行うか判断ができない。
- URLをIdentifierとすることから、必然的にイントラネット内での利用が難しい。 【注2】
- 【注2】
- Identifierがイントラネット内部にあるようなケースだと、外部ネットワークにあるConsumerが、そのIdentifierのページを見ることができないので、少なくともConsumerからIdentifierが見える状態でないと利用できない。
- Consumerもイントラネット内部にありIdentifierにURLが割り当てられているならば、問題なく利用することができるでしょう。
