12
2014/10/2 1 www.incommon.org A Welcome to Federated Identity Nate Klingenstein, Internet2, USA Prepared for Matsuyama University, December 2013 www.incommon.org www.incommon.org 認証連携の基盤 ネイト・クリンゲンステーン, Internet2, USA 松山大学 2013年12月 www.incommon.org www.incommon.org Welcome to the presentation and thanks to our hosts What is Federated Identity? Why is Federated Identity valuable? Who is it valuable for? How you can get started using Federated Identity Challenges, especially the ones unique to libraries and Japan www.incommon.org 本日の講演内容は以下の通りです。 認証連携とは何か? なぜ認証連携は有用か、また誰にとっ て有用か? 認証連携の利用をどう始め得るか 課題、 とくに図書館および日本に特有 の課題について 認証連携へ ようこそ * *InCommonは、Internet2が運営する米国における研究教育分野 の認証フェデレーション(訳注)

A Welcome to Federated Identity Nate Klingenstein ...mu-libcourse.jp/htdocs/Nenpo/2013/26-p.2-13.pdf• SAML 2.0, OAuth 2.0, legacy SAML 1.1/Shibboleth 1.x, some legacy OpenID, eventually

  • Upload
    others

  • View
    2

  • Download
    0

Embed Size (px)

Citation preview

Page 1: A Welcome to Federated Identity Nate Klingenstein ...mu-libcourse.jp/htdocs/Nenpo/2013/26-p.2-13.pdf• SAML 2.0, OAuth 2.0, legacy SAML 1.1/Shibboleth 1.x, some legacy OpenID, eventually

2014/10/2

1

www.incommon.org

A Welcome to Federated Identity

Nate Klingenstein, Internet2, USA

Prepared for Matsuyama

University, December 2013

www.incommon.org

www.incommon.org

認証連携の基盤 ネイト・クリンゲンステーン, Internet2, USA

松山大学

2013年12月

www.incommon.org

www.incommon.org

Welcome to the presentation and

thanks to our hosts

What is Federated Identity?

Why is Federated Identity

valuable? Who is it valuable for?

How you can get started using

Federated Identity

Challenges, especially the ones

unique to libraries and Japan

www.incommon.org

本日の講演内容は以下の通りです。

認証連携とは何か? なぜ認証連携は有用か、また誰にとっ

て有用か? 認証連携の利用をどう始め得るか 課題、 とくに図書館および日本に特有

の課題について

認証連携へ ようこそ

*

*InCommonは、Internet2が運営する米国における研究教育分野の認証フェデレーション(訳注)

Page 2: A Welcome to Federated Identity Nate Klingenstein ...mu-libcourse.jp/htdocs/Nenpo/2013/26-p.2-13.pdf• SAML 2.0, OAuth 2.0, legacy SAML 1.1/Shibboleth 1.x, some legacy OpenID, eventually

2014/10/2

2

www.incommon.org

Why is Shared Identity Important?

• Authoritative user data(attributes), expressed to a

service

• Many applications, many users, not many credentials

– People and applications are complicated, so any identity system

that serves many of them will also be complicated

• Regulatory compliance

– Excellent auditability of who, what, when, and how for data

release

• Cloud services

– SaaS, PaaS, IaaS, NET+

www.incommon.org

なぜ認証共有は重要か?

• サービスに対して示される信頼できるユーザのデータ(属性)

• 多くのアプリケーション、多くのユーザ、少ないクレデンシャル*

• 人とアプリケーションは複雑である。 したがってそのIDシステムもまた複雑になるだろう

• 法規制の遵守

– 誰が、どんなデータを、いつ、どのように発出するかに関する優れた監査性

• クラウドサービス

– SaaS, PaaS, IaaS, NET+ *IDおよびパスワード等の認証情報のこと(訳注)

www.incommon.org

Federated Identity

• Single Sign-On (SSO) with a variety of features added to

fit a multi-domain world

– More evolution of local SSO systems like Kerberos than

innovation

• Single Log-Out(SLO)... becomes a very difficult problem

• Provisioning

– Can be a challenge, depends on the application

• Federations scale trust and simplify operations

– Distinct from federated identity, as you'll find out with some

vendors

www.incommon.org

認証連携

• シングルサインオン(SSO):複数領域の世界に合うように付加された多様な特徴を持っている

– イノベーションというより、ケルベロスのような局所的なSSOシステムが発達してきた

• シングルログアウト(SLO)... かなり難しい問題になってきた

• プロビジョニング

– アプリケーションに依存するが、課題となり得る。

• フェデレーションにより、信頼が拡大され、運用が単純になる

– 認証連携とは区別される

Page 3: A Welcome to Federated Identity Nate Klingenstein ...mu-libcourse.jp/htdocs/Nenpo/2013/26-p.2-13.pdf• SAML 2.0, OAuth 2.0, legacy SAML 1.1/Shibboleth 1.x, some legacy OpenID, eventually

2014/10/2

3

www.incommon.org

9

1. Tedious user registration at all

resources

2. Unreliable and outdated user

data at resources

3. Different login process at each

resource

4. Many different passwords

5. Identity provider may need to

support multiple custom

authentication methods and/or

be asked for access to its

identity database

www.incommon.org

10

個別認証では、

1. すべてのリソースでユーザ登録 - うんざり

2. リソースのユーザデータは信頼できず、古くて役に立たない

3. リソース毎に異るログイン手順

4. たくさんの異るパスワード

5. アイデンティティ・プロバイダは複数の特別な認証方法をサポートすることが必要になるだろうし、そのIDデータベースへのアクセスを求められることにもなるだろう

利用先

たくさんの管理ID

複数のID

www.incommon.org

11

1. Single sign on

2. Services no longer manage

user accounts & personal data

stores

3. Reduced help-desk load

4. Standards-based technology

5. Home organization and user

controls privacy

www.incommon.org

12

認証連携では、

1. シングルサインオンが可能

2. サービスについては、もうユーザアカウントや個人データを管理しなくてもよい

3. ヘルプデスクの作業の軽減

4. 標準に基づく技術

5. 各機関およびユーザがプライバシーを管理できる 単一のID

自機関のアカウント

利用先

Page 4: A Welcome to Federated Identity Nate Klingenstein ...mu-libcourse.jp/htdocs/Nenpo/2013/26-p.2-13.pdf• SAML 2.0, OAuth 2.0, legacy SAML 1.1/Shibboleth 1.x, some legacy OpenID, eventually

2014/10/2

4

n

www.incommon.org

アイデンティティ

プロバイダ

サービス

プロバイダ

ユーザ

7. これが私のデータ です。

2. 所属機関はどこ ですか?

3. 所属機関で ログインしてください。

4. SPにアクセス するためにログイン したい。

5. ログイン

6. これがSPにアク セスするための あなたのデータです。 送ってください。

8a. ページをご覧くだ さい。

8b. アクセスが拒否 されました。

1. アクセスしたい。

ディレクトリ データベース

www.incommon.org

Federated Identity Protocols

• We don't want applications or users to know anything about

federated identity protocols

– Implementations of security software by non-specialists

almost always has vulnerabilities, sometimes serious

vulnerabilities

– Hardwiring an application to a protocol means the

application must change every time the protocol changes

– Users want it to “just work”

• SAML 2.0, OAuth 2.0, legacy SAML 1.1/Shibboleth 1.x, some legacy

OpenID, eventually OpenID Connect

• Many dead federated identity protocols like IMI/Infocards, WS-

*(except for ADFS), Liberty Alliance, etc.

www.incommon.org

認証連携のプロトコル

• アプリケーションやユーザに認証連携プロトコルについて何も知って欲しくない

– 専門家でない人がセキュリティソフトを実装すると、ほとんどの場合脆弱性が発生する。ときには深刻な脆弱性になる

– プロトコルにアプリケーションを組み込むと、プロトコルが変わる都度アプリケーションを変更しなければならなくなる

– ユーザはちゃんと動いて欲しいだけ

• SAML 2.0, OAuth 2.0, 従来の SAML 1.1/Shibboleth 1.x, 従来の OpenID, 最終的にOpenID Connect

• 使われなくなった認証連携プロトコル:IMI/Infocards, WS-*(except for

ADFS), Liberty Alliance, etc.

Page 5: A Welcome to Federated Identity Nate Klingenstein ...mu-libcourse.jp/htdocs/Nenpo/2013/26-p.2-13.pdf• SAML 2.0, OAuth 2.0, legacy SAML 1.1/Shibboleth 1.x, some legacy OpenID, eventually

2014/10/2

5

www.incommon.org

Federations

• A federation is not necessary for federated identity

– It makes federated identity easier, more scalable, and

more maintainable

• Typically one federation per sector, per country

– This is usually because of different privacy and data

protection laws

– There are also cultural differences

– We're working hard on connecting countries, too

• InCommon in the USA

• GakuNin in Japan

• 7125 Entities registered in 35 Federations

www.incommon.org

フェデレーション • 認証連携にフェデレーションは必ずしも必要ではない

– しかし、フェデレーションがあると、認証連携が容易になり、規模も拡大し、維持もしやすくなる

• 一般にセクター単位、国単位でひとつのフェデレーションをつくる

– プライバシーやデータ保護の法令が異なるところから、これが普通となる

– 文化的な差異もある

– 我々は国同士を接続することについても一生懸命作業をしている

• アメリカでは、InCommon

• 日本では、「学認」(学術認証フェデレーション)

• 世界では、35のフェデレーションに7,125件が登録されている

www.incommon.org

Federations

• Federated identity is happening everywhere – business to business,

business to consumer, medical, defense, aerospace, etc.

• But federations are only really happening in academia

• Business and consumer federated identity tend to use bilateral

relationships

– Both of these are smaller scale than academic federation

– Consumer world: only a few IdP's(Facebook and Twitter

and Google)

• We already have many thousands

– Business world: tight business relationships and contracts

already exist

www.incommon.org

フェデレーション

• 認証連携はいたるところでできている– ビジネスとビジネス、 ビジネスと消費者、 医療、 防衛、 宇宙産業など

• しかし、フェデレーションが本当にできたのは学術界だけである

• ビジネスと消費者の認証連携は双務関係の傾向がある

– これらはともに学術フェデレーションより規模が小さい

– 消費者の世界: IdPは少数(Facebook、TwitterおよびGoogle)

• しかし、我々にはすでに何千というIdPがある

– ビジネス界: 厳密な取引関係と契約がすでに存在している

Page 6: A Welcome to Federated Identity Nate Klingenstein ...mu-libcourse.jp/htdocs/Nenpo/2013/26-p.2-13.pdf• SAML 2.0, OAuth 2.0, legacy SAML 1.1/Shibboleth 1.x, some legacy OpenID, eventually

2014/10/2

6

www.incommon.org www.incommon.org

稼働中のフェデレーション 試験中のフェデレーション

研究教育の認証フェデレーション

www.incommon.org www.incommon.org

*SURFconextは、オランダの研究教育ネットワークSURFnetが運営する フェデレーション(訳注)

実際に増えている!

Page 7: A Welcome to Federated Identity Nate Klingenstein ...mu-libcourse.jp/htdocs/Nenpo/2013/26-p.2-13.pdf• SAML 2.0, OAuth 2.0, legacy SAML 1.1/Shibboleth 1.x, some legacy OpenID, eventually

2014/10/2

7

www.incommon.org

InCommon Participants Year-by-Year

25

• 400+ InCommon Participants

• Almost 6 million end-users (faculty, staff, students)

www.incommon.org

InCommon Participants Year-by-Year

26

• InCommonの参加機関は400以上

• 約600万人のエンドユーザ (教員、スタッフ、学生)

InCommon参加機関数の推移(2004-2010)

www.incommon.org

More Recent InCommon Numbers

Now almost 600 participants

Now has 400+ university members from the USA

More than 7.5 million users(staff, students, faculty)

29 Government agencies, labs, research centers

156 Corporate Sponsored Partners

http://www.incommon.org/participants/

www.incommon.org

最新のInCommon 統計

600以上の参加機関

400以上の米国大学が参加

7.5 百万人以上のユーザ(スタッフ、学生、教員)

29 の政府機関、研究所、研究センター

156 の企業の支援会員

http://www.incommon.org/participants/

Page 8: A Welcome to Federated Identity Nate Klingenstein ...mu-libcourse.jp/htdocs/Nenpo/2013/26-p.2-13.pdf• SAML 2.0, OAuth 2.0, legacy SAML 1.1/Shibboleth 1.x, some legacy OpenID, eventually

2014/10/2

8

www.incommon.org

Federated Identity Benefits: Users

• Fewer credentials

• Single sign-on

• Privacy and control over identity data release(when appropriate)

• Access to services from anywhere, on any device, on any network

• A more consistent experience for services hosted by the

organization or in the cloud

www.incommon.org

認証連携の利点:ユーザにとって

• より少ないクレデンシャル

• シングルサインオン

• プライバシーおよびIDデータ発出に関する管理(適切な場合)

• どこからでも、どんな装置からでも、どのネットワークからでもサービスにアクセスできる

• 一貫したサービス経験(機関提供あるいはクラウドによるサービス)

www.incommon.org

Federated Identity Benefits: Application

• Applications no longer need to authenticate users themselves

– Saves time, especially with password resets, which

means it saves money

– Better access control than, for example, IP addresses

• Applications hosted anywhere are better integrated with the

organization

– Great for cloud services, or online library services

• Applications can get trusted user attributes too

– You know who's really a student, or who's really a

graduate

• If a user does something bad, you can always work with the

school to figure out exactly whose account it was

www.incommon.org

認証連携の利点:アプリケーション

• アプリケーション側は、もはや自分で認証をする必要がない

– 時間の節約、とくにパスワードの再設定にかかる時間、それはまた経費の節約を意味する

– よりよいアクセス管理(たとえばIPアドレスによるものより)

• 大学がいろいろなところで提供されているアプリケーションをうまく統合する

– クラウドサービスやオンライン図書館サービスにとってはすばらしいこと

• アプリケーション側もまた信頼できるユーザの属性を入手することができる

– だれが本当に学生か、大学院生かがわかる

• もしユーザが何か悪いことをしたら、学校といっしょにそれが誰のアカウントかをはっきりさせることができる

Page 9: A Welcome to Federated Identity Nate Klingenstein ...mu-libcourse.jp/htdocs/Nenpo/2013/26-p.2-13.pdf• SAML 2.0, OAuth 2.0, legacy SAML 1.1/Shibboleth 1.x, some legacy OpenID, eventually

2014/10/2

9

www.incommon.org

Federated Identity Benefits: School

• The university can choose to use a wide variety of cloud services

not directly owned or hosted by the university

– All services can be connected through a single point that

has been designed for diverse services, reducing the

amount of infrastructure you must run

• IP address ranges, VPN's, etc. become more

flexible and disconnected from service

authentication

• A very good idea of which user data is going where

– Makes audits much less painful

• Positions you to support bring-your-own-device and bring-your-

own-credential

www.incommon.org

認証連携の利点: 学校にとって

• 大学は、多様なクラウドサービスを選択して利用することができる:自機関で所有したり、提供したりしなくてよい

– すべてのサービスは、要稼働の基盤を減らしつつ、多様なサービスに対応するように設計された単一のポイントで接続される。

• IPアドレス域やVPN等は、より柔軟になり、サービスの認証とは切り離される

• どのユーザデータがどこへ行っているかに関するとてもよいアイデア

– 監査の手間がかからないようになる

• 各自の装置やクレデンシャルの持ち込みをサポートできる

www.incommon.org

How can I get started using federated

identity? • This used to be a very difficult question because there were few

partners to talk to

– The “chicken and egg” problem – which comes first

– Network effect: your implementation becomes more and

more useful as you can talk to more and more partners

• Today, there are thousands of services offered with federated

identity that are interesting

– Office 365, Google Apps

– Canvas, Moodle, BlackBoard, Desire2Learn, Webassign

– Elsevier, Ezproxy, Ex Libris, HighWire Press, JSTOR,

ProQuest

www.incommon.org

認証連携の利用をどう始め得るか?

• これはかっては大変難し質問であった:話をもっていくパートナーが殆どいなかったから

– 鶏と卵の問題 – どちらが先か

– ネットワークの効果: ますます多くのパートナーと話ができるようになったので、実装の有用性はますます高まっている

• 今日では、認証連携に対応した興味深いサービスが何千とある

– Office 365, Google Apps

– Canvas, Moodle, BlackBoard, Desire2Learn, Webassign

– Elsevier, Ezproxy, Ex Libris, HighWire Press, JSTOR, ProQuest

Page 10: A Welcome to Federated Identity Nate Klingenstein ...mu-libcourse.jp/htdocs/Nenpo/2013/26-p.2-13.pdf• SAML 2.0, OAuth 2.0, legacy SAML 1.1/Shibboleth 1.x, some legacy OpenID, eventually

2014/10/2

10

www.incommon.org

Getting Started with Federated Identity

• Get engaged with GakuNin

• Set up your own identity provider

– A variety of free open-source software can help you do

this

– simpleSAMLphp, Shibboleth

• Get connected with some applications

– The “killer” application will be different everywhere

• It's cloud applications in most countries today

www.incommon.org

認証連携から始める

• 学認に参加する

• 各自のIdPを立ち上げる

– いろいろ無料のオープンソースソフトウエアがあり、それらを使うことができる

– 例えば、simpleSAMLphpやShibboleth

• いくつかのアプリケーションと接続する

– “killer” アプリケーションは、場所によって異なっているだろう

• 今日、それは殆どの国でクラウドアプリケーションになっている

www.incommon.org

Some Examples from the User

Perspective • The hardest part of federated identity is building a good user

experience

• From small to large:

https://staff.internet2.edu/communications/ (and internet2.box.com)

https://shibtest.hampshire.edu/shibtest/

http://www.sciencedirect.com/ and http://onlinelibrary.wiley.com/

https://wiki.shibboleth.net/

http://www.cartoonnetwork.com

https://login.microsoftonline.com/

www.incommon.org

ユーザの視点からの事例

• 認証連携でもっとも難しいところは、よいユーザエクスペリエンスを構築すること

• 規模の小さいものから大きいものの順に:

https://staff.internet2.edu/communications/ (and internet2.box.com)

https://shibtest.hampshire.edu/shibtest/

http://www.sciencedirect.com/ and http://onlinelibrary.wiley.com/

https://wiki.shibboleth.net/

http://www.cartoonnetwork.com

https://login.microsoftonline.com/

Page 11: A Welcome to Federated Identity Nate Klingenstein ...mu-libcourse.jp/htdocs/Nenpo/2013/26-p.2-13.pdf• SAML 2.0, OAuth 2.0, legacy SAML 1.1/Shibboleth 1.x, some legacy OpenID, eventually

2014/10/2

11

www.incommon.org

Challenges

Finding the staff and money to run an identity provider

In Japan, researchers and staff are often conflated

Staff members are measured by research publication

Nowhere else in the world

Universities have little money for staff and services

Building the user database that powers federated

identity

LDAP, SQL

Building it centrally for an entire university

Universities in the Americas, Europe, and Australia already

had this done, which made our job much easier

www.incommon.org

課 題

IdPを稼働させるためのスタッフと予算を確保する

日本では、研究者とスタッフが同一視されている

スタッフが研究出版物によって評価される

他の国では見られないこと

スタッフとサービスに対する大学の予算が乏しい

認証連携を動かすユーザのデータベースを構築する

LDAP, SQL

大学全体にわたるものを一元的に構築する

アメリカ、ヨーロッパ、オーストラリアの大学では既にできていたので、仕事がずっと容易だった

www.incommon.org

Challenges

• Adding SSO to local applications

– Many of these applications already have integration code

written by other people, but they haven't been deployed

with an SSO system

• Finding the right partner applications for your university

– Many great cloud applications exist for other countries,

and probably for Japan too

• User experience

– This is mostly a problem for the service

www.incommon.org

課 題

• 大学等のアプリケーションにSSOを加える

– これらのアプリケーションの多くは、すでに統合のためのコードを有するが、SSOシステムと一緒には整備されてこなかった

• 自分の大学にとって適切なアプリケーションを見つける

– 他の国では、多くの素晴らしいクラウドアプリケーションが存在している、たぶん日本でもそうだろう

• ユーザエクスペリエンス

– これがサービスにとって一番大きな問題

Page 12: A Welcome to Federated Identity Nate Klingenstein ...mu-libcourse.jp/htdocs/Nenpo/2013/26-p.2-13.pdf• SAML 2.0, OAuth 2.0, legacy SAML 1.1/Shibboleth 1.x, some legacy OpenID, eventually

2014/10/2

12

www.incommon.org

Thank you!

Nate Klingenstein

[email protected]

45

www.incommon.org

ありがとうございました!

Nate Klingenstein

[email protected]

46