情報処理技術セミナー「Shibboleth環境の構築」
概要説明

セミナーの目的と内容
 目的

学術認証フェデレーションへの参加に必要なShibbolethに基づくIdPとSPの構築、運用の基本を理解する 内容

1日目：“IdP”の構築実習
 jdk、tomcat、Shibbolethのインストール
 設定、接続テスト



2日目：“SP”の構築実習
 Apache、Shibbolethのインストール（shibd, mod_shib）
 設定、接続テスト

2

学術認証フェデレーションとは学術認証フェデレーションとは

定められた規程（ポリシー）を信頼しあうことで，相互に認証連携を実現し，学術リソースを利用・提供する機関や組織から構成された連合体のこと
機関（IdP）がIDと属性を管理し，サービス提供者（SP）がそれを利用して認可プライバシ保護を考慮したシングルサインオン（SSO）技術






ユーザのユニークネスを保証しつつ個人情報は出さない
SPは必要な情報のみをIdPに要求
ユーザは各SPに対する各属性の公開を制御可能従来：SPでID管理

SP・ID
・属性

ユーザ

SP
アクセス、パスワード

3・ID・属性

SSO：IdPでID管理
アクセス

SP

IdP
・ID
・属性

ユーザ
パスワード

リダイレクトSP

アサーションShibboleth（シボレス）
米国EDUCAUSE／Internet2にて2000年に発足したプロジェクト

http://shibboleth.internet2.edu/

SAML、eduPerson等の標準仕様を利用した，認可のための属性交換を行う標準仕様とミドルウェア （オープンソースソフトウェア）

米国、欧州でShibbolethによるFederationが運用、拡大バージョン1.3系と2.0系が広く利用されている（プロトコルが少し異なる）


最新はShibboleth V2.1

cf.
欧州（特に北欧）では，simpleSAMLphpも利用されている

ノルウェ―UNINETT

日本語化プロジェクト
4

http://rnd.feide.no/simplesamlphp
http://sourceforge.jp/projects/ssp-japan/フェデレーション構築に必要なサーバ
IdP（Identity Provider）



フェデレーション内に構成員の情報を提供するサーバ
 フェデレーションに参加する大学等が構築

SP（Service Provider）



認証を受けた人に対してサービスを行うサーバ 電子ジャーナル，データベース，E-ラーニング等
Webベースのシステムであれば何でも可DS（Discovery Service）



SPへのアクセスの際にIdPを検索するシステム
 フェデレーションが運用
 ここに名前がのることにより「フェデレーションに参加」
 WAYF (Where Are You From) サービスとも呼ばれる(Shib 1.x)


5

IdP (Identity Provider)とはフェデレーション内に情報を提供するサーバであり，大学等が構築
 IdP自身は情報を持たない
 情報はLDAPやActive Directory等，既存の認証基盤を参照
 IdPは単なるフィルタであり，学内認証基盤から特定のデータのみを抽出して提供する
 公開できるデータの制御が可能である

このため，Shibbolethはしばしば個人情報保護に優れていると言われるが，サーバ自体がハッキングに強固という意味ではない。
 慎重な操作が必要なのは，LDAPやActive Directoryと同じ

学内認証基盤

IdP
必要なデータのみを外部へ提供データのフィルタ

LDAP

Active Directory など

機関名，所属非公開データを落とすフィルタ
6

機関名，所属，氏名，肩書き…

SP (Service Provider)とは


サービスを提供するWebサーバのこと“シボレスログイン”等のボタンがあればShibbolethで利用可能なSPである



電子ジャーナルに限らず，いろいろなサービスをShibboleth化することが可能（例：無線LAN認証，サイボウズ）

学内のみの利用ならば，IdP, SPが立ち上がれば完成。
他大学と連携するには何が必要？
7

Shibbolethの基本動作

IdP（所属機関）

SP（リソース提供者）

9
アクセス承認
属性情報

6

7

8

9

2

1

7

3
8

4

DS（ディスカバリサービス）

4

5

ユーザ

1

Cookieによる処理の記憶
メタデータ

登録

配布
（ダウンロード）

登録

配布（ダウンロード）

IdP（所属機関）

SP（リソース提供者）9
アクセス承認
属性情報

67

8

9

2

1

7
Set Cookie

394

DS（ディスカバリサービス）

45

ユーザ

1

メタデータを用いた信頼の構築

SP B

SP C

SP A

フェデレーション

フェデレーション
メタデータ

リポジトリ

エンティティ
メタデータ

DS（ディスカバリサービス）

IdP A
IdP B

IdP C

自動ダウンロードするフェデレーションメタデータの信頼性は、フェデレーションの証明書で担保（事前に入手・検証し、事前にIdP/SPにインストール）
10（検証は、別チャンネルで入手したfingerprintとの比較等による）

メタデータ(XML形式)の構成
フェデレーションメタデータ
署名の情報

エンティティメタデータ (IdP)
IdPの情報・IdP１の情報
・IdP２の情報
・・・・・
・・・・・

・IdP１のID＝entityID・利用する証明書・利用可能なプロトコル
・組織情報
・・・・・

エンティティメタデータ(SP)SPの情報
・SP１の情報
・SP２の情報・・・・・
・・・・・
11・SP１のID＝entityID・利用する証明書・利用可能なプロトコル
・組織情報
・・・・・

Shibbolethの実装
IdP
Attribute
Authority

front channel
Browser

SSO
ProfileAttribute
DB

https

httpsAuthN
EngineAuthN
DB
LDAP/ADSession
Initiator DS
Assertion
Consumer
SAML POST

Username
Password
AuthN

Shibboleth Module(mod_shib)Form

Shibboleth
Daemon(shibd)Tomcat

12

SPback channel

Web
Resource# .htaccess
AuthType shibboleth
ShibRequireSession
Onrequire valid-user

Apache/ IIS

ポート番号は443または4443、8443

Shibboleth動作の詳細 (Shibboleth 2.x)

http://www.switch.ch/aai/demo/ より
13

実習環境
テスト用
Training-SP

Training-DS

テスト用
Training-IdP

Trainingrepository

講師用PC

DNS

実習用
TrainingLDAP

実習用
TrainingIdP-testXX

実習用
Training-SPtestXX

CentOS(VM)

CentOS(VM)

受講生用PC
14

すでに準備されているもの
 テスト用IdP、SP

他機関が用意したものと想定

 Training-DS

フェデレーションが用意するもの

 DNSサーバ

IdP、SPのサーバ名を登録

 NTPサーバ


Shibbolethの動作には時間同期が重要

 鍵ペア、サーバ証明書

実際には、鍵の生成と証明書発行申請が必要

 LDAPサーバ
15

別途用意されていると想定各種情報
１．学術認証フェデレーションに関するWebサイト
UPKIイニシアティブ 「学術認証フェデレーション」
https ://upki-portal.nii.ac.jp/docs/fed

２．ポリシー、申請書
UPKIイニシアティブ 「学術認証フェデレーション」－「参加」
https ://upki-portal.nii.ac.jp/docs/fed/join

３．IdP、SP構築ガイド
UPKIイニシアティブ 「学術認証フェデレーション」－「技術ガイド」
https ://upki-portal.nii.ac.jp/docs/fed/technical

４．IdP構築用VMWareServerイメージ
UPKIイニシアティブ 「学術認証フェデレーション」－「技術ガイド」－「IdP構築関連ファイル」
https ://upki-portal.nii.ac.jp/docs/fed/technical/idp/files

５．テンプレート（メタデータ、IdP属性管理）
学術認証フェデレーションのリポジトリ
http ://upki-repo.nii.ac.jp/Template/index.html

６．情報交換メーリングリスト（アーカイブ）
UPKIイニシアティブ 「学術認証フェデレーション」－「情報交換ML」
https ://upki-portal.nii.ac.jp/docs/fed/ml
16

追加課題１（IdPでの属性制御）
 属性情報を全くSPに送出されないように設定を変更し、動作確認する
 eduPersonTargetedID、eduPersonPrincipalNameのみが送出されるように設定を変更し、動作確認する
 あるSPに対してeduPersonTargetedID のみが送出されるように設定を変更し、動作確認する
 あるユーザについて、eduPersonEntitlementの値としてadminを送出するように設定し、動作確認する
 eduPersonEntitlementの値について、あるSPに対して必要な値のみ通過させるように設定し、動作確認する

17

追加課題２（SPでの属性制御）
 受信した全ての属性がフィルタされるように設定を変更

し、動作確認する
 IdPからeduPersonEntitlementについて複数の値を送出するようにし、SPで一方の値のみを通過させるように設定を変更し、動作確認する
 IdPでtrainingTestAttributeという新たな属性を送出し、SPでその属性を受信するように設定を変更し、動作確認する

18

追加課題３（SPでのアクセス制御）
 シングルサインオン（SSO）の動作を確認

 eduPersonAffiliationがstaff の場合にだけアクセスを許可するように設定し、動作確認する
 eduPersonEntitlementにtestが含まれる場合にだけアクセスを許可するように設定し、動作確認
 LazySession の設定を行い動作確認する

 ForceAuthentication を指定した場合の SSO の動作を確認する
 PassiveAuthentication を設定した場合の動作を確認する
19