ページ履歴

...

「技術ガイド > IdPセッティング > サーバ証明書の設定 > Back-Channelの設定」の「２．SOAP設定」でserver.xmlに clientAuth="want" と設定している部分があります。学認推奨値は一環して と設定している部分があります。学認推奨値は一貫して want ですが、Shibboleth開発元（Shibboleth Wiki）では clientAuth="true" と指示されていた期間がありました（正確な時期は不明ですが2012年6月より前）。もしShibboleth Wikiの情報でIdPを構築された方は、Tomcatの設定ファイルserver.xmlの設定値を今一度確認することをおすすめします。

...

...

特定のSPへのアサーションを暗号化しない設定

学認では技術運用基準として、アサーション(IdPで生成した利用者の属性等の情報)をSPに送る際には暗号化すべき(SHOULD)であると定めています(*1)が、Google AppsやOffice 365などのように暗号化したアサーションを受け付けないSPも存在します。Shibboleth IdPのデフォルトの挙動は、全てのSPに対して送信するアサーションを暗号化するようになっていますので、そのような特定のSPに対して送信するアサーションを暗号化しないように設定する方法を以下に記載します。

• (*1) 学認技術運用基準 (2015年3月12日現在バージョン22017年3月13日現在バージョン2.12)

  2.2) 認証応答
  (...略...)さらに、認証アサーションに対して、暗号化をすべきである。

...

<RelyingParty id="SPのentityID"
    provider="IdPのentityID"
    defaultSigningCredentialRef="IdPCredential">
    ...
    <ProfileConfiguration xsi:type="saml:SAML2SSOProfile"
        includeAttributeStatement="true"
        assertionLifetime="300000"
        assertionProxyCount="0"
        signResponses="conditional"
        signAssertions="never"
        encryptAssertions="never"
        encryptNameIds="never" />
    ...
</RelyingParty>

...

• 参考情報
  • 情報元: https://www.gakunin.jp/ml-archives/upki-fed/msg00615.html
  • 特定のSPへのアサーションを暗号化しないことに関するポリシーの議論:
    http://marc.info/?t=136497370800001&r=1&w=2

...

idやvalueはSP毎に変わりますので、下表を参考に各SPに合わせて設定してください。

...

idやvalueはSP毎に変わりますので、下表を参考に各SPに合わせて設定してください。

...

同じ値が再割り当てされないeduPersonTargetedIDの生成方法

eduPersonTargetedID(ePTID)を生成するときにLDAP上の属性としてuidを代表とした属性値が利用されますが、これらの属性値では再割り当ての問題があります。例えばuidとして test001 を使っていた人が異動になり、さらに年月が経って同じuidを使いたいという人が現われた場合にはそのまま割り当ててしまうことはできません。これはSP 側で を使っていた人が異動になり、さらに年月が経って同じuidを使いたいという人が現われた場合にはそのまま割り当ててしまうことはできません。これはSP側で uid=test001 という属性値を基に生成されたePTIDで個人を識別していた場合に、再割り当て前の人物と、再割り当て後の人物を区別できず同一人物とみなして再割り当 て前のアカウントの情報を利用してしまうことが起こるためです。という属性値を基に生成されたePTIDで個人を識別していた場合に、再割り当て前の人物と、再割り当て後の人物を区別できず同一人物とみなして再割り当て前のアカウントの情報を利用してしまうこと（当人が意図しないなりすまし）が起こるためです。

ePTIDでStoredIDを利用している場合には失効処理を行うことで新しいePTIDを生成することができることから、ソースとなる属性値の再割り当てをすることは可能です。今回は別の方法として、uidの付加情報としてLDAPエントリの作成時間ePTIDでStoredIDを利用している場合には失効処理を行うことで新しいePTIDを生成することができることから、再割り当てされる属性値をソースとした上で再割り当て時に失効することでも対処可能です。今回は別の方法として、uidの付加情報としてLDAPエントリの作成時間(createTimestamp)を加えた値をソースとしてePTIDを生成する方法を調査しました。例えば uid<uid>-createTimestamp <createTimestamp> のように2つの属性値をハイフンでつなげて test001-20130314110740Z といった値をソースとしてePTIDを生成すれば、uid再割り当てごとの失効処理が不要となります。ただし、再割り当ての際に必ず「作成時間」が変更さ れるように処理することが前提となります。といった値をソースとしてePTIDを生成すれば、uid再割り当てごとの失効処理が不要となります。ただし、再割り当ての際に必ず「作成時間」が変更されるようにアカウント作成処理をすることが前提となります。（LDAPエントリを再利用するような運用ではcreateTimestampが変更されない可能性があります）

下記ではLDAP上のuidとcreateTimestampをソースとしたePTIDの生成例をご紹介いたします。ComputedIDをベースに設定方法を紹介していますが、StoredIDの場合も同様です。

• eduPersonTargetedIDのAttributeDefinitionはデフォルトのままで利用可能です。

  コード ブロック

  <!-- Attribute Definition for eduPersonTargetedID --> <resolver:AttributeDefinition id="eduPersonTargetedID" xsi:type="SAML2NameID" xmlns="urn:mace:shibboleth:2.0:resolver:ad" nameIdFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" sourceAttributeID="computedID"> <resolver:Dependency ref="computedID" /> <resolver:AttributeEncoder xsi:type="SAML1XMLObject" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" /> <resolver:AttributeEncoder xsi:type="SAML2XMLObject" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" friendlyName="eduPersonTargetedID" /> </resolver:AttributeDefinition>

• Template Attribute Definitionで uid-createTimestamp の文字列を返すAttributeDefinitionを定義して、ComputedID用DataConnectorの sourceAttributeID, Dependencyを変更します。ここでは「templateePTID」という名前を用います。

  コード ブロック

  <!-- Computed targeted ID connector --> <resolver:DataConnector xsi:type="ComputedId" xmlns="urn:mace:shibboleth:2.0:resolver:dc" id="computedID" generatedAttributeID="computedID" - sourceAttributeID="uid" + sourceAttributeID="templateePTID" salt="*****YOUR_SALT*****"> - <resolver:Dependency ref="myLDAP" /> + <resolver:Dependency ref="templateePTID" /> </resolver:DataConnector> + <resolver:AttributeDefinition id="templateePTID" xsi:type="Template" xmlns="urn:mace:shibboleth:2.0:resolver:ad"> + <resolver:Dependency ref="myLDAP" /> + + <Template> + <![CDATA[ + ${uid}-${createTimestamp} + ]]> + </Template> + + <SourceAttribute>uid</SourceAttribute> + <SourceAttribute>createTimestamp</SourceAttribute> + </resolver:AttributeDefinition>

• LDAPからcreateTimestampを取得するためにReturnAttributesを定義します。LDAPから追加でcreateTimestampを取得するためにLDAP DataConnectorにReturnAttributesを定義します。

  コード ブロック

  <resolver:DataConnector id="myLDAP" xsi:type="dc:LDAPDirectory" ldapURL="ldap://localhost" baseDN="o=Test Organization,dc=ac,c=JP" principal="cn=olmgr,o=Test Organization,dc=ac,c=JP" principalCredential="**** YOUR LDAP Password ****"> <dc:FilterTemplate> <![CDATA[ (uid=$requestContext.principalName) ]]> </dc:FilterTemplate> + <dc:ReturnAttributes>* createTimestamp</dc:ReturnAttributes> </resolver:DataConnector>

...

1. discoveryTemplate.html を /etc/shibboleth に配置します。文言を適当に修正してください。

   注意
   特に"meatwiki"の部分はご自身のサービス名に修正してください。（2か所）

2. Javascriptテンプレートのダウンロード からJavaScript部分だけを抜き出したファイルをドキュメントルート配下(例えば/var/www/html)に js/embedded-wayf_config.js として配置します。
   1. 環境に合わせて wayf_URL, wayf_sp_entityID, wayf_sp_handlerURL, wayf_return_url を修正してください。

   2. DSのリストに追加したいIdPを wayf_additional_idps に設定してください。例:

      コード ブロック
      language javascript
      var wayf_additional_idps = [ {name:"OpenIdPAdditionalIdP", entityID:"https://openidpidp.niiexample.ac.jp/idp/shibboleth", SAML1SSOurl:"https://openidpidp.niiexample.ac.jp/idp/profile/Shibboleth/SSO"}, ];

3. /etc/shibboleth/shibboleth2.xml の設定を変更します。

   1. 前出の discoveryTemplate.html を使うようにSessionInitiatorを修正します。

      書式設定済み
      <SessionInitiator type="Chaining" Location="/DS" isDefault="true" id="DS"> <SessionInitiator type="SAML2" template="bindingTemplate.html"/> <SessionInitiator type="Shib1"/> - <SessionInitiator type="SAMLDS" URL="https://ds.gakunin.nii.ac.jp/WAYF"/> + <SessionInitiator type="Form" template="discoveryTemplate.html"/> </SessionInitiator>

   2. JavaScript無効時のために/Shibboleth.sso/LoginでCentral DSへ遷移するように設定します。（entityIDの削除とdiscoveryURLの修正）

      書式設定済み
      <SSO discoveryProtocol="SAMLDS" discoveryURL="https://ds.gakunin.nii.ac.jp/WAYF">

   3. embedded-wayf_config.jsのwayf_additional_idpsに追加したIdPのメタデータを読み込むための設定を追加します。事前にIdPのエンティティメタデータを取得して、/etc/shibboleth/metadata/ に配置しておいてください。

      書式設定済み
      <MetadataProvider type="XML" filepath="metadata/additionalexample_idp-metadata.xml"/>

サーバ証明書

...

プロトコル

DSを経由せず強制的に特定のIdPに遷移する方法

^SP3対応

Apacheの設定で require shib-session もしくは require valid-user を設定し、そのコンテンツにアクセスした時点でDSへリダイレクトされる、というのが学認における通常のフローかと思いますが、Apacheの設定に以下を追加すればこれが有効な範囲ではDSを経由せずに指定したIdPに直接リダイレクトします。

...

なお、サイト全体で特定のIdPのみ対象とする場合、例えば学内サービスのようなものについては、下記ページを参考に当該IdPのみを信頼するように設定してください。
⇒ 学内システムとして構築する場合の設定 もしくは メタデータ中の特定のIdPのみ利用を許可する方法

オープンリダイレクタとなりうる問題の対処

^SP3対応

Shibboleth SPをデフォルトの設定で利用した場合にユーザを任意の外部サイトにリダイレクトすることができるオープンリダイレクタとして機能する問題があります。Shibboleth SP 2.4.2からリダイレクトの問題へ対処するオプションが提供されています。

...

...

redirectLimitオプションにはいくつか種類がありますので、各サイトごとに適切なオプションを選択してください。下記に代表的な/etc/shibboleth/shibboleth2.xml の設定例(diff形式)を挙げます。

• "exact"を指定することでリダイレクト先のホスト名やポートなどがリダイレクト元のSPと完全に一致するものだけに制限することが可能です。

  コード ブロック
  @@ -50,7 +50,8 @@ security of your site. Stealing sessions via cookie theft is much easier with this disabled. --> <Sessions lifetime="28800" timeout="3600" relayState="ss:mem" - checkAddress="false" handlerSSL="false" cookieProps="http"> + checkAddress="false" handlerSSL="false" cookieProps="http" + redirectLimit="exact"> <!-- Configures SSO for a default IdP. To allow for >1 IdP, remove

• "exact+whitelistallow"を指定することでホワイトリストを用いたリダイレクト先の制限が可能です。複数のホスト名でVirtual Host設定を行なっている場合に利用することが想定されます。

  コード ブロック

  @@ -50,7 +50,8 @@ security of your site. Stealing sessions via cookie theft is much easier with this disabled. --> <Sessions lifetime="28800" timeout="3600" relayState="ss:mem" - checkAddress="false" handlerSSL="false" cookieProps="http"> + checkAddress="false" handlerSSL="false" cookieProps="http" + redirectLimit="exact+whitelistallow" redirectWhitelistredirectAllow="https://service1.example.ac.jp/ https://service2.example.ac.jp/"> <!-- Configures SSO for a default IdP. To allow for >1 IdP, remove

この設定を行い不正なURLに遷移しようとした場合は以下のエラーとなります。

リダイレクトを制限するためのオプションが追加された経緯については下記のリンクを参照ください。

opensaml::SecurityPolicyException at (https://

...

sp.example.

...

ac.

...

jp/

...

Shibboleth.sso/

...

SAML2/POST)

Blocked unacceptable redirect location.

Shibboleth SP 3.4.1およびそれ以降ではチェックが強化され、デフォルトのままの場合起動時にログに警告が記録されるようになりました。以下のようなログが記録されている場合はこれに該当しますので、上記のように設定を見直してください。

2023-01-19 14:07:39 WARN Shibboleth.Application : redirectLimit not set, system will operate as an open redirector if not corrected

Shibboleth SP 2.5.0からの新機能

...

• Apacheの設定

  書式設定済み
  $ cat /etc/httpd/conf.d/shib.conf (...略...) <Location /secure> AuthType shibboleth ShibCompatWith24 On ShibRequestSetting requireSession 1 require validshib-usersession </Location>

Webアプリケーションのログアウト処理ページ /secure/logout に対して次のApacheの設定を追加すると requireLogoutWith に指定されている /Shibboleth.sso/Logout にてShibbolethセッションの破棄と /secure/logout によるWebアプリケーションのログアウト処理が一連の動作として行なわれます。

...

チェック対象の eppn や displayName といった属性名は /etc/shibboleth/attribute-map.xml で定義されている内容に従って記述する必要があります。
この他に template="attrChecker.html" の部分に template="/var/www/html/Error.html" のようにローカルのファイルを指定することで、Attribute Checkerによって表示されるエラーページを変更することも可能です。

デフォルトのエラー画面は以下のように"We're sorry, but you cannot access this service at this time."で始まる英語の文面となっております。末尾のリンクは<Errors>要素のhelpLocation属性が反映されますのでIdP管理者向けの送信すべき属性等を説明したページを設定しておくとよいでしょう。
Image Added

Attribute Checker Handlerに関する詳細は https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPHandler#NativeSPHandler-AttributeCheckerHandlerVersion25andAbove をご参照ください。

...

ShibRequestSetting REMOTE_ADDR X-Forwarded-For

...

/Shibboleth.sso/の扱い

Shibboleth SPをインストールしたサイト（virtual hostで複数のサイトを持っている場合は少なくともそのうちの1つ）では、/Shibboleth.sso/以下をmod_shibモジュールがハンドリングする必要があります。例えば、IdPから送信されたアサーションはこのパス内にあるURL（具体的には /Shibboleth.sso/SAML2/POST 等）で受けます。

...

• Making URLs Used by mod_shib Get Properly Routed
• SetHandler ディレクティブ
• ProxyPass ディレクティブ

メタデータ中の特定のIdPのみ利用を許可する方法

^SP3対応

フェデレーションメタデータのように複数のIdPが格納されているメタデータから、特定のIdPのみと連携し、他のIdPからの利用を拒否する必要がある場合には、Whitelist Include MetadataFilter が利用できます。例えば、運用フェデレーションに参加しているIdPと学内に構築したローカルSPで連携（技術ガイド > SP > SPセッティング > 学内システムとして構築する場合の設定）するときに以下のように記述できます。こうすることで、ローカルSP上にIdPメタデータを配置する必要がなく、IdPメタデータ更新時にローカルSP側の更新作業を省略できるという利点があります。

...

...

SPの証明書更新の方法

技術ガイド（GakuNinShibInstall > Home > 技術ガイド > SP > SPセッティング > SP Key Rollover）に手順が記載されています。メタデータ記載の証明書更新手順（SP）　を参照してください。

...

属性値は、phpinfo() （参照 : IdPとのSP接続確認） や技術ガイド > 属性 のページで公開している 属性確認用PHPプログラム を用いて確認することができます。

Apache以外の環境で属性値を取得する方法

前述の通り、Apache以外のWebサーバでは要求ヘッダを介して属性値を取得することになります。

...

学認で提供している attribute-map.xml (参照 : テンプレート) を用いて、Apacheで取得できる環境変数名とIIS上PHPで取得できる変数名の対応表を以下に示します（2013年12月当時の情報であるため利用するIISのバージョンやASP.NET, PHPのバージョンで異なることがあります）。

...