大阪大学でのUPKIシングルサインオン実証実験
大阪大学サイバーメディアセンター

1. Identity Provider の機能調査・構築
大阪大学サイバーメディアセンターでは、学内サービスの認証基盤として構築した全学IT認証基盤を大学間認証連携およびサービス連携の基礎として発展させるため、UPKI認証連携基盤の実証実験に参加し、既存の認証基盤の拡張方針について検討を進めている。本センターでは特に既に認証基盤を構築した大学をターゲットとして、既存の認証基盤に対する変更を最小限に抑えた上で、UPKI認証連携基盤に参加する方法について検討していきたいと考えている。以下では、本学の認証基盤を例にUPKI認証連携基盤にシームレスに統合するためのアプローチについて今年度の調査状況、実証実験の実施状況について報告する。

Shibboleth IdP の属性マッピング機能の検証
各大学で構築した認証基盤で管理しているユーザ属性がeduPerson 属性に対応する属性をもっているケースは少なく、eduPerson 属性を追加して適当な値を設定する作業が必要になる。
運用中のディレクトリサーバに対するデータ書き換えや新たな機能追る方法について調査した。調査の結果、Mapped AttributeDefinitionを用いた静的な属性マッピングおよびRelationalDatabaseDataConnector を用いた動的な属性マッピングにより本学で管理しているユーザ属性をeduPerson属性に変換できることを確認した。詳細SAMLアサーション

ユーザ属性取得
LDAP
ユーザ属性の例

Shibbolethの属性変換機能

categoryCode
1-7,8-9,10-11

eduPerson
属性の例
eduPerson
Affiliation
student,
faculty,staff

Organizational
UnitCode
10001
::

ou
Cybermedia
Center::加は作業工数が多くなるため、Shibboleth の属性変換機能で既存の属性情報から eduPerson 属性を生成しSAMLアサーションに設定すShibboleth SP

Shibboleth IdP

独自schemaの既存LDAPについてはWikiページに報告している。
SQLiteWikiページ（http://ssowiki.nii.ac.jp/）：「00̲各参加機関の取り組み＞大阪大学＞Shibboleth 2.0 の属性マッピング機能の検証」

OpenSSO, Access ManagerとShibboleth SPのSAML2.0連携
既存のWeb SSOサーバがある大学では別にShibbolethサーバを運用するよりは、既存のWeb SSOを用いた方がコストを低減できる可能性がある。本学でWeb SSOサーバとして採用しているSun Java System Access Managerについて、そのオープンソース版であるOpenSSOを調査し、Shibboleth SPとのSAML2.0での連携方法について検討した。OpenSSOは図に示すように想定している連携スタイルなどがShibbolethとは異なるため、SAML2.0に関して実装されている機能に相違がある。そこで、OpenSSOが提供するSDKを利用して機能をカスタマイズし、Shibboleth SPと連携可能にした。また、そこで蓄積したノウハウを用いて、Access
ManagerとShibboleth SPの連携を可能にした。詳細についてはWikiページに報告している。今後の課題としては、SAML2.0での連携を前提として、OpenIDなど他のプロトコルもサポートするOpenSSO，CASといったシステムも含めて、大学における認証基盤の機能を満たすSSOシステムの構築方法について引き続き検討していく必要がある。

Wikiページ（http://ssowiki.nii.ac.jp/）：「00̲各参加機関の取り組み＞大阪大学＞OpenSSO と Shibboleth 2.0 の SAML 2.0 連携」
A大学

B大学

A大学

B大学
IdP

SPSAML
独自SSO

OpenSSO の認証連携の例

Shibboleth の認証連携の例

2.グリッド証明書発行SPの構築•

大阪大学サイバーメディアセンターでは、本センターの大規模計算機システムを利用するための既存の全国共同利用業務のIDデータベース (Microsoft Active Directory≒Kerberos) に付随するShibboleth IdPを設置した。

•

さらに、当該IdPによる認可を受けた利用者に対して本センターのグリッド認証局からグリッド証明書を発行するために必要となるライセンスIDを自動的に払い出すSPを構築し試験的なサービス提供を行っている。また、さらに、本学の全学IT認証基盤とのフェデレーションを検証した。

•

このように、NISやLDAP、ADSなどによる既存のIDレポジトリにShibboleth IdPを付随して設置し、本センターと業務協力関係を結ぶことで、これまでのような人手による事務作業を省略して、本センターが発行するグリッド証明書を取得可能になる。

•

このような業務フローはIGTF (International Grid Trust Federation) が規定するMICS (MemberIntegrated Credential Service) プロファイルによる認証局運用業務規定に合致するものと考えており、将来的にIGTF/APGrid PMA (Policy Management Authority) によってプロダクション・レベルのグリッド証明書発行業務として認定され得るものと考えている。

•

これまでのClassicプロファイルに基づくグリッド証明書発行に際しては、窓口に写真付きの身分証明書を提示して本人確認を受ける必要があったが、これを既存の情報基盤センターの全国共同利用の利用登録情報で代替することが可能となり、ソーシャル・フローを大幅に簡素化し、より広範にグリッド証明書を発行可能になるものと期待している。

阪大CMCのアプローチ – その1「NAREGI連携なんて無理」と考えていた頃･･･阪大だけでも• 第1段階
– すべての登録ユーザにグリッド証明書を• “1-click” によるグリッド証明書発行– すべての計算機資源をグリッドに提供• ローカルスケジューラのパイプキューを閉塞・開放することで提供資源を適宜制
御阪大CMCの大規模計算機システム構成

Total: 46.1 TFLOPS, 16.0 TB

ヘテロ型クラスタ• NEC SXとPCクラスタの混在• フェアシェアによる定額利用• NQSによる連成ジョブ記述• FC-SANによるストレージ共有

CMC

NEC SX-9

遊休時利用PCクラスタ
NEC Express-5800 56Xd

16.4 TFLOPS
10.0 TB

18.3 TFLOPS
1.0 TB

1PB
FC-Storage

NEC SX-8R
ILE

学内
全国共同利用センター
連携

集約型仮想サーバファーム
NEC Express-5800 120Rg1

RCNP
6.1 TFLOPS
2.0 TB

5.3 TFLOPS
3.0 TB

動的な資源拡張• キューが伸びると遊休時利用PCクラスタが動的に組み込まれる• 10GbE w/TOE NIC
によるクラスタリング

NAREGI M/Wの各コンポーネントと阪大CMCの構成との位置関係
LocalAuthentication

CA/RA

Grid LDAP

NAREGI Grid Middleware β2

VOMSUMS(CMC Proprietary)

GridVM Server
for PC-Cluster

MyProxy

MyProxy+

Grid Portal

SS

GridVM Server
for SX

IS-NAS

user

GridVM Server
for PC-Cluster

IS-CDAS

frontend
login

Kerberos KDC

Local Scheduler:
NEC NQS-II

w/JobManipulator
w/GridScheduleMaster

既存の全国共同利用システムとNAREGIミドルウェアβ2の共存• ローカル認証にKerberosを導入し、CUI/GUI共に連動するSingle SignOnを実現すると同時に、NAREGI認証システムをWebインターフェイスに隠蔽• ローカル・スケジューラNEC NQS-II対応のNAREGIコンポーネントを既存運用と併存可能なように開発

NAREGIグリッドミドルウェアの認証メカニズム• シングルサインオンは行わない･･･– UMS (User Management Server)• ローカルアカウントで初期認証• 別途、RAから発行されたライセンスIDで認証を行ってグリッド用ユーザ証明書を払い出し– Grid Portal• UMSから払い出したプロキシ証明書を復号化するパスフレーズによって認証• 2007年度、阪大CMCでは、これらの認証をKerberosクレデンシャルに基づくシングルサインオンに置き換えた– 残念ながら、NAREGIミドルウェア最終版の発注仕様決定後だったため貢献できず･･･8Issuing Grid User Certificate with
“License ID” pre-obtained from the RA
and storing it to the UMS (first time)
Issuing Proxy Certificate
with decrypting
Grid User Certificate

Logging in tothe NAREGI UMS(User Management Server)
with its local accountSigning on to
the NAREGI Portal
with decrypting
issued Proxy Certificate

Original NAREGI Authentication Flow9Showing Kerberos Credential,
Grid User Certificate is able to issue
for all users without exchanging“License ID” (first time)

Issuing Proxy Certificate
with decrypting
Grid User Certificate

Logging in to
the NAREGI UMS(User Management Server)
with its local accountSigning on to
the NAREGI Portal
with decrypting
issued Proxy Certificate

Original NAREGI Authentication FlowShowing Kerberos Credential,
no decryption is neededon issuing Proxy Certificate
and signing on to the NAREGI Portal

Our Replacement using Kerberized SSO

Obtaining Kerberos Credential for SSO
to the NAREGI UMS and Portal

Note: Certificates have been
encrypted by a system generated
passphrase,
users don’t aware and don’t bother10最初に行う初期認証が十分に強固であるべき• 阪大CMCの全国共同利用アカウント– KerberosによるSSO+12文字のパスワード– IGTF (International Grid Trust Federation) が規定するプロ
ダクション・レベルのグリッド用ユーザ証明書を操作するために十分な強度• APGrid PMA議長の田中さんと議論しMICSプロファイルとして認定を受け得ることを示唆される

11

MICSプロファイル

Member Integrated X.509 PKI Credential Service
 「1年1ヶ月」以上存続している既存の認証基盤と連動してグリッド証明書を発行する
 The initial vetting of identity for any entity in the primaryauthentication system that is valid for certification should be basedon a face-to-face meeting and should be confirmed via photoidentification and/or similar valid official documents.

 導入例
 TeraGridのNCSAグリッド認証局 (仮承認?)
 NCSAがこれまで行ってきた「ピアレビュー」によるアカウント発行の枠組みを活かす

 TACCのグリッド認証局
 Classicプロファイルのグリッド認証局と併存?

“IGTF Accrediation Review of MICS Authentication Profile (Update)”by Marg Murray, TACC, 2007/05/30

阪大CMCのアプローチ - その2
T2Kグリッド連携の刺激を受けて共存を考え始める• 第2段階– 他の基盤センターの登録ユーザにもグリッド証明書を発行• MICSプロファイルを満たすShibboleth SP/IdPによる連携– 提供資源を非排他的に共有• ローカルスケジューラの予約マップをメタスケジューラに後方からインジェクション

NAREGIミドルウェアとShibboleth• シングルサインオンの実現– NAREGI Grid Portalへの接続時 (検討中)– グリッド用ユーザ証明書の払出し時 (本年度の成果)• 現時点で実現できていない点– グリッド用ユーザ証明書やプロキシ証明書を複合化するパスフ
レーズによる認証の一元化• 他センターのグリッド認証局が発行したグリッド用ユーザ証明書を格納するUMSとの互換性を保つ必要性からパスフレーズなしの認証とすることは難しい･･･• Shibbolethによるフェデレーションだけでは解消できない問
題点– 資源提供を行う拠点間でのDN (Designated Name) とLN (LocalName) の対応管理

MICSプロファイルを満たすShibboleth IdP/SPを介したグリッド証明書の発行業務連携
CARA
基盤センターA
4

5

Shib SP237

1License ID

6DS: W.A.Y.F.

Shib IdP

ID: Kerberos

業務システム

① Shib SP として実装されたグリッド証明書発行システムにWebブラウザでアクセス② DS にリダイレクトされ、どの基盤センターから認証を受けるかを指定④＋⑤ RAからライセン
スID の払い出しを行い、利用者に通知する③ 基盤センターの全国共同利用登録者である
か否か、Shib IdPを経由して認証

grid-certreq
User
Certificate

UMS

Shib IdP

ID: LDAP

MyProxy
基盤センターB

業務システムShibboleth SP (Service Provider) をアクセス
すると、まずIdPのDS (Discovery Service) にリダイレクトされる:① リストの中から阪大CMCのIdP (Identity Provider) を･･･

② 選択
ポップアップ③ 阪大CMCの大規模計算機システム用の全国共同利用アカウント(MS ActiveDirectory Server – Kerberos) のID/パスワードを入力し認証を受ける

IdPによる認証後、Shibboleth SP (Service Provider) に戻る。
阪大グリッド認証局からユーザ証明書を発行するために必要となるライセンスIDの発行を指示 (阪大CMC開発部分):③ 選択

NAREGIポータル (Web UI) にて、取得したライセンスIDと付帯情報を入力する。
阪大グリッド認証局からユーザ証明書が発行され付随するUMS (User Management Server) に格納される:

④ 入力

⑤ 選択

他センターに設置したUMSにグリッド証明書を格納する場合は、当該UMSのCUIにて“grid-certreq” コマンドを実行する

When accessing to the SP (Service Provider),the access is redirected to DS (DiscoveryService) to select IdP (Identity Provider)① from the list of IdP’s including
IdP of Cybermedia Centerof Osaka University…

② Select!
popup③ Acquire authentication typing ID/Password foraccessing usual services from the Cybermedia
Center of Osaka University maintained byMicrosoft Active Directory (Kerberos)
19

Shibbolethで実現できること、できないこと• Shibbolethで実現できる– ID/パスワードに基づくフェデレーション• Shibbolethだけでは実現できない– DN (またはShibbolethのEPPN属性) と各サービス提供拠点のローカルアカウントの「名寄せ」– EGEEが採用しているプールアカウント (LCAS/LCMAPS) とVOMS (VO Management Server) との連携で解決できる？
• 現時点でNAREGIミドルウェアはgrid-mapfileによる「名寄せ」にのみ対応• 計算機資源提供を行う情報基盤センターのAUPとの整合性？