※上記の広告は60日以上更新のないWIKIに表示されています。更新することで広告が下部へ移動します。

動作概要

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が割り当てられているならば、問題なく利用することができるでしょう。