Shibbolethは、コンピュータネットワークおよびインターネット向けのシングルサインオンログインシステムです。これにより、ユーザーは単一のIDで、異なる組織や機関の連合体が運営する様々なシステムにログインできます。これらの連合体は、多くの場合、大学や公共サービス機関です。
Shibboleth Internet2ミドルウェアイニシアチブは、Security Assertion Markup Language (SAML)に基づいたID管理およびフェデレーションIDベースの認証・認可(またはアクセス制御)インフラストラクチャのためのアーキテクチャとオープンソース実装を作成しました。フェデレーションIDにより、フェデレーション内の1つのセキュリティドメインから他の組織へユーザー情報を共有できます。これにより、ドメインをまたいだシングルサインオンが可能になり、コンテンツプロバイダーがユーザー名とパスワードを管理する必要がなくなります。IDプロバイダー(IdP)はユーザー情報を提供し、サービスプロバイダー(SP)はこの情報を使用してセキュアなコンテンツへのアクセスを提供します。
ShibbolethプロジェクトはInternet2から発展しました。2025年6月現在、このプロジェクトはShibbolethコンソーシアムによって管理されています。[ 1 ] Shibbolethコンソーシアムによって管理されている最も人気のあるソフトウェアコンポーネントの2つは、Shibboleth Identity ProviderとShibboleth Service Providerで、どちらもSAMLの実装です。
このプロジェクトは、聖書(士師記12章4-6節)で使用されている識別用の合言葉にちなんで名付けられました。これは、エフライム族が「sh」を発音できなかったためです。
Shibbolethプロジェクトは、認証と認可のインフラストラクチャが互換性のない組織間でリソースの共有を容易にするために2000年に開始されました。ソフトウェア開発に先立ち、1年以上かけてアーキテクチャ設計が行われました。開発とテストの後、Shibboleth IdP 1.0が2003年7月にリリースされました。 [ 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が独自に改良を加え、SAML 1.1の不足機能を補う機能を実装しました。これらの機能の一部は後にSAML 2.0に組み込まれ、その意味でShibbolethはSAMLプロトコルの進化に貢献しました。
おそらく最も重要な貢献機能は、従来のShibboleth AuthnRequestプロトコルでしょう。SAML 1.1プロトコルは本来IdPファーストのプロトコルであったため、ShibbolethはSAML 1.1をSPファーストのプロトコルに変えるシンプルなHTTPベースの認証リクエストプロトコルを開発しました。このプロトコルはShibboleth IdP 1.0で初めて実装され、その後Shibboleth IdP 1.3で改良されました。
その初期の成果を基に、Liberty Allianceは完全に拡張されたAuthnRequestプロトコルをLiberty Identity Federation Frameworkに導入しました。最終的に、Liberty ID-FF 1.2はOASISに貢献され、OASIS SAML 2.0標準の基礎となりました。
Shibboleth は、 SAMLのHTTP/POSTアーティファクトおよび属性プッシュプロファイルを実装する Web ベースのテクノロジーであり、ID プロバイダ (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のアクセス制御は、IDプロバイダー(IdP)から提供される属性をサービスプロバイダー(SP)が定義するルールと照合することによって行われます。属性とは、ユーザーに関するあらゆる情報であり、「このコミュニティのメンバー」、「アリス・スミス」、「契約Aに基づいてライセンスを取得済み」などが含まれます。ユーザーのIDは属性とみなされ、明示的に要求された場合にのみ渡されるため、ユーザーのプライバシーが保護されます。属性はJavaで記述することも、ディレクトリやデータベースから取得することもできます。標準のX.520属性が最も一般的に使用されますが、トランザクションにおいてIdPとSPが同様に理解し解釈できる限り、新しい属性を任意に定義することも可能です。
ドメイン間の信頼関係は、公開鍵暗号(多くの場合、TLSサーバー証明書)とプロバイダーを記述するメタデータを用いて構築されます。渡される情報の利用は、契約によって管理されます。フェデレーションは、共通のルールと契約を使用することに同意した多数のプロバイダーを集約することで、これらの関係を簡素化するためによく利用されます。
Shibbolethはオープンソースであり、Apache 2ライセンスの下で提供されています。[ 7 ]他のグループによって多くの拡張機能が提供されています。[ 8 ] [ 9 ] [ 10 ]
{{cite mailing list}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク){{cite web}}: CS1 maint: bot: 元の URL の状態が不明です (リンク)