この記事の一部(バージョン3.0関連部分)は更新が必要です。(2019年4月) |
| シボレト | |
|---|---|
| タイプ | シングルサインオンシステム |
| ライセンス | アパッチ 2.0 |
| Webサイト | www.shibboleth.net |
Shibbolethは、コンピュータネットワークとインターネットのためのシングルサインオンログインシステムです。これにより、ユーザーは単一のIDで、異なる組織や機関の連合によって運営される様々なシステムにサインインできます。連合には、大学や公共サービス組織などが含まれることが多いです。
Shibboleth Internet2ミドルウェア・イニシアチブは、セキュリティ・アサーション・マークアップ言語(SAML)に基づくアイデンティティ管理およびフェデレーション・アイデンティティベースの認証・認可(またはアクセス制御)インフラストラクチャのためのアーキテクチャとオープンソース実装を開発しました。フェデレーション・アイデンティティは、あるセキュリティ・ドメインのユーザー情報をフェデレーション内の他の組織と共有することを可能にします。これにより、ドメイン間のシングル・サインオンが可能になり、コンテンツ・プロバイダーがユーザー名とパスワードを管理する必要がなくなります。アイデンティティ・プロバイダー(IdP)がユーザー情報を提供し、サービス・プロバイダー(SP)がその情報を使用して安全なコンテンツへのアクセスを許可します。
ShibbolethプロジェクトはInternet2から発展しました。2025年6月現在、このプロジェクトはShibbolethコンソーシアムによって管理されています。[ 1 ] Shibbolethコンソーシアムが管理する最も人気のあるソフトウェアコンポーネントの2つは、Shibboleth Identity ProviderとShibboleth Service Providerであり、どちらもSAMLの実装です。
このプロジェクトは、エフライム人が「sh」を発音できなかった ため、聖書(士師記12:4–6)で使用されている識別パスフレーズにちなんで名付けられました。
Shibbolethプロジェクトは、互換性のない認証・認可インフラストラクチャを持つ組織間のリソース共有を容易にすることを目的として、2000年に開始されました。ソフトウェア開発に先立ち、1年以上かけてアーキテクチャ構築作業が行われました。開発とテストを経て、2003年7月にShibboleth IdP 1.0がリリースされました。[ 2 ]その後、2005年8月にShibboleth IdP 1.3がリリースされました。
Shibbolethソフトウェアのバージョン2.0は、2008年3月にリリースされたメジャーアップグレードでした。[ 3 ] IdPとSPの両方のコンポーネントが含まれていましたが、さらに重要なのは、Shibboleth 2.0がSAML 2.0をサポートしていたことです。
ShibbolethプロトコルとSAMLプロトコルは同時期に開発されました。当初からShibbolethはSAMLをベースとしていましたが、SAMLに不足している点についてはShibbolethが改良を加え、Shibboleth開発者はSAML 1.1の不足機能を補う機能を実装しました。これらの機能の一部は後にSAML 2.0に組み込まれ、その意味でShibbolethはSAMLプロトコルの進化に貢献しました。
おそらく最も重要な貢献は、レガシーのShibboleth AuthnRequestプロトコルでしょう。SAML 1.1プロトコルは本質的にIdPファーストのプロトコルであったため、ShibbolethはシンプルなHTTPベースの認証リクエストプロトコルを発明し、SAML 1.1をSPファーストのプロトコルへと転換しました。このプロトコルはShibboleth IdP 1.0で初めて実装され、後にShibboleth IdP 1.3で改良されました。
この初期の取り組みを基に、Liberty AllianceはLiberty Identity Federation Frameworkに完全に拡張されたAuthnRequestプロトコルを導入しました。最終的に、Liberty ID-FF 1.2がOASISに寄贈され、OASIS SAML 2.0標準の基盤となりました。
Shibbolethは、 SAMLのHTTP/POSTアーティファクトおよび属性プッシュプロファイルを実装するWebベースの技術であり、アイデンティティプロバイダ(IdP)とサービスプロバイダ(SP)の両方のコンポーネントを含みます。Shibboleth 1.3には、SAML 1.1仕様に基づいて構築された 独自の技術概要[ 4 ]、アーキテクチャドキュメント[ 5 ]、および適合性ドキュメント[ 6 ]があります。
標準的な使用例:
Shibboleth は、この基本ケースのさまざまなバリエーションをサポートしています。これには、IdP が SP への初期アクセスで配信される非請求アサーションを作成するポータル スタイルのフローや、アプリケーションが必要に応じて任意の方法でコンテンツ保護をトリガーできるようにする遅延セッション開始が含まれます。
Shibboleth 1.3 以前では組み込みの認証メカニズムは提供されていませんが、任意の Web ベースの認証メカニズムを使用して、Shibboleth が使用するユーザーデータを提供できます。この目的でよく使用されるシステムとしては、CASやPubcookieなどがあります。IdP が実行される Java コンテナ(Tomcat など)の認証およびシングルサインオン機能も使用できます。
Shibboleth 2.0はSAML 2.0標準を基盤としています。Shibboleth 2.0のIdPは、SAML 2.0のパッシブ認証および強制認証リクエストをサポートするために追加の処理を実行する必要があります。SPはIdPに特定の認証方法を要求できます。Shibboleth 2.0は追加の暗号化機能をサポートしています。
Shibboleth のアクセス制御は、IdP から提供される属性と SP が定義したルールを照合することで実行されます。属性とは、「このコミュニティのメンバー」、「Alice Smith」、「契約 A に基づいてライセンスを取得」といった、ユーザーに関するあらゆる情報を指します。ユーザー ID も属性とみなされ、明示的に要求された場合にのみ渡されるため、ユーザーのプライバシーが保護されます。属性は Java で記述することも、ディレクトリやデータベースから取得することもできます。最も一般的に使用されるのは標準 X.520 属性ですが、トランザクションにおいて IdP と SP が同様に理解および解釈できる限り、新しい属性を任意に定義できます。
ドメイン間の信頼は、公開鍵暗号(多くの場合、 TLSサーバー証明書)とプロバイダを記述するメタデータを用いて実現されます。やり取りされる情報の使用は、契約によって制御されます。フェデレーションは、共通のルールと契約を使用することに同意した多数のプロバイダを集約することで、これらの関係を簡素化するためによく使用されます。
Shibbolethはオープンソースであり、Apache 2ライセンスの下で提供されています。[ 7 ]多くの拡張機能は他のグループによって提供されています。[ 8 ] [ 9 ] [ 10 ]
{{cite web}}: CS1 maint: bot: 元のURLステータス不明(リンク)