大体、認証で発行するクレーム(トークン)的なものを使用して認可する仕掛けになっている。Provider)が行う。Service)が行う。Provider)が行う。Service)が発行する~クレーム(トークン)的なものにより、認証(Idp)と認可(SP)を分離できるのが醍醐味。従って、分散型の認証方式を提供するオープンな認証システムと言える。[#h4a44b62]各用語については下記を参照。Foundation)に関連する用語。Provider)に対しても認証要求を遂行する必要がある。Party(RP)と名称が変更されている。~OpenIDでは、STS相当が独立しておらず、当該機能がRPとIdp内に同梱されている。User--Consumerに対して自分のIdentityの認証を要求しようとするユーザ--自分のIdentityを認証しConsumerに紹介状(OpenIDトークン)を送るIdPに加入する必要がある。2.0};からはXRIというURIを拡張した形式で表されたものを指す。Identifierの暗号化された証明(紹介状)を発行。Provider(OP)とも呼ばれる。Identifier---使用するOPが内部的に使用するユーザID。---OPがOP上の認証処理等で使用する。[#qa5b24ca][[OpenID]]と≒。2.0の用語>#w507f337]]を使用する(ただし実装は、OAuthの拡張)。FS)]]などの実績のあるSSOをサポートする認証連携(IDフェデレーション)基盤-異なるベンダのアクセス制御製品間の相互運用性を推進し、~企業間の独立したサービスをグローバルなSSOで連携させることが可能。-認証されたアカウントを偽装するにはカスタムの実装が必要。-認証連携(IDフェデレーション)の利点~http://www.atmarkit.co.jp/fwin2k/operation/adfs2sso02/adfs2sso02_01.html--上記のフェデレーションの動作におけるポイントの1つとしては、サービス・プロバイダ側で直接認証(IDやパスワードの入力)を行っていないので、サービス・プロバイダへのネットワーク経路上をパスワードが流れないという点がある。~もう1つ、サービス・プロバイダが直接アイデンティティ・プロバイダと通信を行っていないので、アイデンティティ・プロバイダとサービス・プロバイダは別々のネットワークに存在してもよいという点も挙げられる。--これらにより、イントラネット上のアイデンティティ・プロバイダを利用して、クラウド上のサービス・プロバイダへセキュアなアクセスを行うといったことが可能になる。~また同時に、イントラネット上の社内アプリケーションにも同様の仕組みを導入することにより、イントラネットとクラウドにまたがったセキュアなシングル・サインオンという非常に利便性の高いシステムを構築できる。[#sa6cf928]-クッキー認証チケットを使用しない。--クッキーを第三者が不正使用してなりすましを許す可能性がある。--クッキーはクッキードメインの中でしか有効ではない。Assertionsを使用。--以下のプロファイルがある。[#bd876705]中央集権型でない、分散ID認証システムのオープン仕様。-ブラウザベースの認証APIの標準化から始まった。-認可するクレーム(トークン)として、~紹介状(OpenIDトークン)を受け取るか、合鍵を受け取るかの違いがある。紹介状(OpenIDトークン)として、提供元となるIdpが転送するプロトコル。1.1:Consumer経由で紹介状を作成して送信する公証人Idpを呼び出す。2.0};:RP経由で紹介状を作成して送信する公証人OPを呼び出す。-[[OpenID]]の仕様上、誰でもConsumer(RP)やIdp(OP)になれるという点から、~特にConsumer(RP)はどのIdp(OP)を信用したらよいかという問題が残る。[#k66961ce]紹介状(OpenIDトークン)ではなく、~合鍵を渡し、認証+権限付与を行うプロトコル。~-ユーザが外部サービスにパスワードを教えることなく、~サービス間でユーザの同意のもとにセキュアにユーザの権限情報(合鍵)を受け渡しする。--エンドユーザはサービスAに対してあるサービスB上のリソースや機能に~取得/追加/更新/削除などのアクセス許可を与える。--サービスAは、エンドユーザの許可を受けたサービスB上のリソースや機能にアクセスする。-[[OpenID]]よりもOAuth認証をしたいというサイトが増えてきている。2.0を拡張し、正しく認証する次世代OpenID。Connect]]によって置換えられた。2.0の認可の仕組みを使用して認証する仕組み。-違いは、紹介状(OpenIDトークン)のコピーだけが入っているロッカーの鍵を渡す所。Provider)はこの鍵の発行者を信頼し、鍵の正統性の検証が可能。1.0--仕様は、同時期に策定された。--ユーザから見た画面遷移もほぼ同じ--開発者の間で機能が比較された。2.0を置き換えたもの。2.0-メリット--一度の実装で複数のOPに対応できる。1.0のように、サービス上のAPIに権限を付与する機能はない。1.0-メリット--認証+APIに対する権限付与ができる。--プロフィール情報を取得できるAPIが提供されれば認証+認可ができる。-デメリット--認証結果と属性情報(クレーム)から認可するポリシーの指定方法が存在しない。Client側の実装を作りこむ必要がある。2.0を置き換えたもの。--これまで足りなかった以下のような機能拡張がされている。2.0のリクエストを少し変更するだけで、利用できる。2.0のリクエストパラメータに特定の値を指定するだけ。--複数のクライント・フローを実装するのは手間。~しかし、Idpを開発するのに比べれば、RPを開発する方が楽。800-63-1で定義されている全ユーザ認証要件(LoA)への対応が可能。--金融システムや電子政府/行政システムにも利用できることを意味している。