要約

  • Kenneth J. Klingensteinは、組織ごとの場当たり的な接続を、ローカル認証、共通属性、署名付きメタデータ、ローカル認可から成る連合へ移すための制度づくりを推進した。
  • 連合は信頼を自動化しない。IdP、SP、連合運用者の責任を分け、越境したアクセス判断を検証できる部品にする。

図書館の電子資料を開く。所属大学を選び、いつもの画面でサインインすると、元のページに戻って本文が読める。利用者には一つの扉にしか見えない。しかし実際には、異なる組織が別々の時点で別々の判断を下している。

所属機関は自らの手続きで本人を認証し、その出来事についてアサーションを発行する。必要なら所属や権利を示す属性も添える。受け手のサービスはメッセージを検証し、自らの規則で許可を決める。その間には、送信先、役割、検証鍵、属性の意味、参加資格を共有する層が要る。一連の結果を一者だけで支配することはできない。

Klingensteinの業績は、この継ぎ目にある。Internet Hall of Fameは、米国西部のネットワーク普及に関わった初期の仕事と、1998年以降のアイデンティティ／トラスト基盤への貢献を記録している。コロラド大学ボルダー校のchief technologistだった1999年、彼はInternet2 Middleware Initiativeを率いる立場に就いた。Internet2は、その活動からShibboleth、InCommon、eduPersonなどが育ったと説明する。

ただし、これは単独発明者の物語ではない。Klingenstein自身はInCommonの20周年回顧で、初期チームを導いた人物としてR. L. “Bob” Morganを挙げている。大学のアーキテクト、開発者、図書館、研究共同体、OASIS標準の参加者が技術と運用を作った。彼の役割は、共通課題に長期の方向と組織的な居場所を与えたことにある。

初期の合言葉は、ローカルで認証し、グローバルに行動することだった。大学には既にアカウント、ディレクトリ、入退職・在籍管理、セキュリティ慣行がある。それらを一つの世界的アカウント基盤に移せば、身元情報の管理権を集約し、多様な組織に同じ運用を強いる。連合は、一次的な認証を所属機関に残し、限定された主張だけを相互運用可能にする道を選んだ。

Shibbolethは2000年にInternet2のミドルウェア活動から生まれ、同年にOASISのSAML作業と接続した。1.0は2003年に公開された。2004年、Morgan、Scott Cantor、Steven Carmody、Walter Hoehn、Klingensteinは、所属機関側のIdentity Providerと、資源側のService Providerという二つの構成要素を説明した。

IdPは利用者に馴染みのあるログインを扱い、アサーションを出す。SPはそれを検証し、アプリケーションへ属性を渡す。最後にアクセスを許すのはアプリケーションのローカル規則である。したがって、認証済みと認可済みは同義ではない。署名が正しいアサーションでも、古い規則や広すぎる規則、誤った属性解釈に投入されれば、不適切な許可を生む。

属性は、恒久的なユーザー名だけを相手に渡す必要を減らした。出版社なら契約対象の機関に属することだけ、研究基盤なら特定のentitlementだけが必要かもしれない。氏名、メールアドレス、学内IDが判断に不要なら、それらを送ることは決定を強くせず、露出だけを増やす。

そこでeduPersonが共通語彙を与えた。同仕様は高等教育向けの属性を定義し、組織間のaffiliationは定義と運用について広い合意がなければ実用的な価値を持たないと明記する。さらに識別子のスコープ、持続性、プライバシー、唯一性、再割り当てを区別する。

この区別は実務そのものである。ある大学の「member」は現役の教職員だけを指し、別の大学では卒業生や委託者まで含むかもしれない。再利用される識別子は、新しい人物を以前の履歴につなげかねない。持続的な識別子は必要な記録を保つ一方、利用者が想定しない追跡も可能にする。属性の意味にも、鍵と同じく版と変更履歴が要る。

Shibbolethは受け手ごとの属性リリース方針も備え、不透明または一時的な識別子によって既知のログイン名を出さない選択肢を用意した。これはデータ最小化の手段であって、完全なプライバシーの保証ではない。既定値、管理者判断、利用者の理解、受け手のログ、後のデータ結合が実際の識別可能性を左右する。

SAMLを話せることだけでも足りなかった。2004年の共同論文は、セキュリティ機構、属性定義、相手サーバーの発見、利用者管理の正確さ、個人情報の扱い、参加できる組織について合意が必要だと述べる。各大学と各サービスがすべてを二者間で結べば、契約と設定は組み合わせの数だけ増える。

InCommonは、その交渉を共同制度にした。Klingensteinの回顧によれば、技術交換が可能になっても、受け手が他機関の認証情報と属性を信頼するための組織的機構が必要だった。参加組織と権限者の確認、メタデータ処理、共通の期待、運用、紛争解決、参加終了がその仕事になる。

メタデータは制度の一部を機械可読にする。OASISの仕様では、エンティティの役割、サービスのendpoint、binding、署名検証や暗号化に用いる鍵材料を表現できる。InCommonの運用規程は、参加者の情報を集め、変更を評価し、メタデータを電子署名して公開し、参加者が取得すると定める。

この仕組みでは自己署名証明書も利用可能になり得る。価値は証明書単体ではなく、管理された登録と署名済みメタデータ配布によって、その鍵が組織に結び付けられることから生まれる。ただし、メタデータへの掲載は組織内のあらゆる対策を保証しない。Baseline ExpectationsがIdP、SP、連合運用者の義務を分けるのは、その飛躍を避けるためである。

二つのログイン領域の間にある登録簿は、中央の個人名簿ではない。相互運用に必要なシステム記述と委任を扱う。IdPは認証と開示に、SPは検証と認可に、連合運用者は登録と配布に責任を持ち続ける。

歴史的な成果は、自治を消さずに、手作業の接続を減らしたことだ。メタデータが鍵とendpointの個別交換を減らし、eduPersonが意味の翻訳を減らし、共通規則が参加資格の再交渉を減らした。オープンソースは各機関に検証可能な実装を与えた。信頼は自動になったのではなく、反復可能な形を得た。

「シングルサインオン」は操作感を示す言葉であり、判断記録ではない。問題のあるアクセスを説明するには、どのIdPがいつ、どの認証コンテキストで確認したか、アサーションの発行者・対象・有効期間は何か、どの属性がどの定義とリリース規則で出たか、SPはどの版のメタデータと鍵を信じ、どのローカル規則で許可したかを組み直す必要がある。

ページが開いたという事実だけでは、その答えは残らない。Klingensteinのより深い遺産は、見えない組織境界を、統治できる信頼インターフェースとして扱う道を作ったことにある。二つの領域は別々でいてよい。ただし、共同で生んだ決定は、部品ごとに名前を持たなければならない。

出典