ページ履歴

IdP, SP, DS に関する設定・運用・カスタマイズの各種情報についてまとめるページです。

目次

別ページの情報：

IdP関連情報

...

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

...

IdPから複数台のLDAPサーバの情報を参照するために使用するLDAPプロキシサーバ設定方法を資料にまとめました。各LDAPサーバとLDAPプロキシ間はLDAPS接続またはStartTLS接続をするものとします。詳細はPDF資料をご参照ください。

複数台LDAPサーバ向けの別の方法

内容の異なる複数のLDAPツリーを横断的に検索するlogin.configの例はShibboleth Wiki:IdPAuthUserPassの"Stacking Login Modules"の項にあります。この場合、attribute-resolver.xmlでは2つのLDAP DataConnectorを定義し両方をDependencyに記述してください。

LDAPサーバにStartTLSを利用する方法(LDAPサーバがCentOS 5の場合)

CentOS 5標準のopenldap-serversパッケージでLDAPサーバを構築した環境のおいて、IdPからLDAPサーバにStartTLSで接続する設定について記載します。serversパッケージでLDAPサーバを構築した環境において、IdPからLDAPサーバにStartTLSで接続する設定について記載します。

LDAPサーバはホスト名 ldaptest1.gakunin.nii.ac.jp として説明します。 LDAPプロキシサーバ : 複数台LDAPサーバ向けのLDAPプロキシサーバ設定方法 の「LDAPサーバ設定(ldaptest1)」を参考に /etc/openldap/slapd.conf の設定を行ってください。この説明で利用する証明書の情報は「LDAPサーバ設定(ldaptest1)」の設定に準じます。

...

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

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

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

  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>

...

<!-- (省略) -->
                 </ds:X509Certificate>
               </ds:X509Data>
             </ds:KeyInfo>
           </KeyDescriptor>
           <!-- ↓↓↓ ここから追加 ↓↓↓ -->
           <SingleLogoutService Bindingxmlns:aslo="urn:oasis:names:tc:SAML:2.0:bindingsprotocol:ext:HTTPasync-Redirectslo" Locationaslo:supportsAsynchronous="https://idp.example.ac.jp/idp/profile/SAML2/Redirect/SLO" />
"true"
                               <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Redirect"
                                Location="https://idp.example.ac.jp/idp/profile/SAML2/POSTRedirect/SLO" />
           <!-- ↑↑↑ ここまで追加 ↑↑↑ -->
 <SingleLogoutService xmlns:aslo="urn:oasis:names:tc:SAML:2.0:protocol:ext:async-slo" aslo:supportsAsynchronous="true"
          <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
                      <NameIDFormat>urnBinding="urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
bindings:HTTP-POST"
                 <SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" Location="https://idp.               Location="https://idp.example.ac.jp/idp/profile/SAML2/ShibbolethPOST/SSOSLO" />
           <!-- ↑↑↑ ここまで追加 <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://idp.example.ac.jp/idp/profile/SAML2/POST/SSO"/↑↑↑ -->
           <SingleSignOnService Binding="urn:oasis:names:<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
           <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
           <SingleSignOnService Binding="urn:mace:shibboleth:1.0:bindingsprofiles:HTTP-RedirectAuthnRequest" Location="https://idp.example.ac.jp/idp/profile/SAML2/RedirectShibboleth/SSO"/>
         </IDPSSODescriptor>
         <AttributeAuthorityDescriptor protocolSupportEnumeration<SingleSignOnService Binding="urn:oasis:names:tc:SAML:12.10:protocol urn:oasis:bindings:HTTP-POST" Location="https://idp.example.ac.jp/idp/profile/SAML2/POST/SSO"/>
           <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:protocol">
<!-- (省略) -->:bindings:HTTP-Redirect" Location="https://idp.example.ac.jp/idp/profile/SAML2/Redirect/SSO"/>
         </IDPSSODescriptor>
         <AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol">
<!-- (省略) -->

...

• ログアウト処理
• IdPEnableSLO
• IdPSAML2LogoutRequestProfileConfig
• NativeSPServiceLogout
• NativeSPLogoutInitiator

SP関連情報

Embedded DS

特定の言語で表示する方法

Embedded DSは、ブラウザの表示言語設定を反映して表示する言語を選びますが、特定の言語で表示したい場合の方法が下記に記載されてます。

...

SPに対してどのような属性が送出されるか確認する方法

attribute-resolver.xmlやattribute-filter.xml等の設定を行ったあと、SPに対してどのような属性が送出されるか確認するためにはShibboleth IdP付属のaacli.shコマンドを利用することができます。IdPをユーザtomcat権限で動作させている場合の利用方法は下記の通りです。

$ sudo -u tomcat env JAVA_HOME=$JAVA_HOME /opt/shibboleth-idp/bin/aacli.sh --configDir /opt/shibboleth-idp/conf --principal="ユーザ名" --requester="属性送出を確認したいSPのentityID"

aacli.shコマンドの詳細は https://wiki.shibboleth.net/confluence/display/SHIB2/AACLI をご参照ください。実行で問題があるようでしたら トラブルシューティング の情報もご参照ください。

IdPの証明書更新の方法

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

IdPのトラストアンカーに必要なCA証明書を導入する方法

技術ガイド（GakuNinShibInstall > Home > 技術ガイド > IdP > IdPセッティング > IdPのトラストアンカーの確認と必要なCA証明書の導入）に手順が記載されています。 IdPのトラストアンカーの確認と必要なCA証明書の導入 を参照してください。

SP関連情報

Embedded DS

特定の言語で表示する方法

Embedded DSは、ブラウザの表示言語設定を反映して表示する言語を選びますが、特定の言語で表示したい場合の方法が下記に記載されてます。

学認外のIdPを選択できるようにする方法

学認参加のSPで、特例として学認外のIdPを通常のDSの代わりにEmbedded DSのIdPリストに表示させるための方法を記載します。例えば https://meatwiki.nii.ac.jp ではこの方法を使って、ログインするときに表示されるIdPのリストにOpenIdPなどの学認外IdPを追加しています。

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:"AdditionalIdP", entityID:"https://idp.example.ac.jp/idp/shibboleth", SAML1SSOurl:"https://idp.example.ac.jp/idp/profile/Shibboleth/SSO"}, ];

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

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

      書式設定済み
      <SessionInitiator type="Chaining" Location="/DS" isDefault="true"

...

学認外のIdPを選択できるようにする方法

学認参加のSPで、特例として学認外のIdPを通常のDSの代わりにEmbedded DSのIdPリストに表示させるための方法を記載します。例えば https://meatwiki.nii.ac.jp ではこの方法を使って、ログインするときに表示されるIdPのリストにOpenIdPなどの学認外IdPを追加しています。

1. discoveryTemplate.html を /etc/shibboleth に配置します。文言を適当に修正してください。
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:"OpenIdP", entityID:"https://openidp.nii.ac.jp/idp/shibboleth", SAML1SSOurl:"https://openidp.nii.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_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/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およびそれ以降ではチェックが強化され、デフォルトのままの場合起動時にログに警告が記録されるようになりました。以下のようなログが記録されている場合はこれに該当しますので、上記のように設定を見直してください。

WebアプリケーションのログアウトフローへのShibbolethログアウト処理の挿入

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からの新機能

WebアプリケーションのログアウトフローへのShibbolethログアウト処理の挿入

Shibboleth SP 2.5より requireLogoutWith Shibboleth SP 2.5より requireLogoutWith が実装されました。 requireLogoutWith では指定されたURL(通常はShibbolethのログアウトURLを指定)に遷移したのちに、元のページの戻るといった処理が自動的に行なわれます。
Shibboleth認証になっているパス(例えば /secure )の中にWebアプリケーションのログアウト処理のページを用意します。ログアウト処理ページは仮に /secure/logout とします。

• 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アプリケーションのログアウト処理が一連の動作として行なわれます。

...

• Sessionsの末尾にAttribute Checker Handlerを追加(利用用途に合わせて選択)

  • eduPersonPrincipalNameとdisplayNameの属性を必須とする(AND条件)

    書式設定済み
    <Sessions> (...略...) <!-- Checks for required attribute(s) before login completes. --> <Handler type="AttributeChecker" Location="/AttrChecker" template="attrChecker.html" attributes="eppn displayName" flushSession="true"/> </Sessions>

    もしくは以下の書き方でも可

    書式設定済み
    <Sessions><SessionInitiator ... (...略...) </Sessions>

    もしくは以下の書き方でも可

    書式設定済み
    <Sessions> (...略...) < <!-- Checks for required attribute(s) before login completes. --> <Handler type="AttributeChecker" Location="/AttrChecker" template="attrChecker.html" flushSession="true"> <AND> <Rule require="eppn"/> <Rule require="displayName"/> </AND> </Handler> <SessionInitiator ... (...略...) </Sessions>

  • eduPersonPrincipalNameとdisplayNameのどちらか一方の属性を必須とする場合(OR条件)

    書式設定済み
    <Sessions> (...略...) <Handler type="AttributeChecker" Location="/AttrChecker" template="attrChecker.html" flushSession="true"> <OR> <Rule require="eppn"/> <Rule require="displayName"/> </OR> </Handler> </Sessions>

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

SSLアクセラレータを挟む構成に関する参考情報

Shibboleth SPの前段にSSLアクセラレータを挟む場合、Shibboleth SPが動作しているサーバのホスト名と外から見えるホスト名が異なっていたり、接続を受けるポート・スキーム(HTTP/HTTPS)が異なっていたりすることで問題になる場合があります。
学認情報交換MLの以下から始まるスレッドを参考にApacheおよびShibboleth SPの設定をご確認ください。

• [upki-fed:00386] IdPとのSP接続確認のエラーについて
  • https://www.gakunin.jp/ml-archives/upki-fed/thrd8.html
• [upki-fed:276] SSLアクセラレータ環境
  • https://www.gakunin.jp/ml-archives/upki-fed/thrd6.html

さらなる情報は、Shibboleth開発元が提供している下記ページ（英語）をご参照ください。

• Deploy the Service Provider behind a Reverse Web Proxy
  https://wiki.shibboleth.net/confluence/display/SHIB2/SPReverseProxy
  ※SSLアクセラレータは"SSL offloading"と表現されています。SSLアクセラレータ自身に対する設定も記述されていますが、読み飛ばしてください。

未確認ながら、ソースIPアドレスがSSLアクセラレータのものに固定されることによって、shibboleth2.xmlの設定で checkAddress="true" としていると問題が発生すると思われますのでご注意ください。また、consistentAddress="true" は期待する動作をしない（常にconsistentであると判定され、セッションが切断されない）と思われます。

ShibRequestSetting REMOTE_ADDR X-Forwarded-For

/Shibboleth.sso/の扱い

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

既存のWebアプリケーションでサイト全体を特定のモジュールもしくはハンドラもしくはスクリプトでハンドリングするようになっている場合は、以下のどちらかの方法で対処してください。

1) /Shibboleth.sso/以下を除外
除外設定の方法はWebアプリケーションの構成により異なります。例えば、サイト全体をTomcat等にプロキシしている場合は、プロキシ設定の前に以下のような行を追加して除外してください。

ProxyPass /Shibboleth.sso !　　　　←この行を追加
ProxyPass / ajp://localhost:8009/

2) /Shibboleth.sso/に対してハンドラ上書き指定
/Shibboleth.sso/以下をmod_shibモジュールでハンドリングするように以下の通り明示的に設定してください。

<Location /Shibboleth.sso>
  SetHandler shib
</Location>

参考:

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

...

• • <SessionInitiator ... (...略...) </Sessions>

チェック対象の 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 をご参照ください。

SSLアクセラレータを挟む構成に関する参考情報

Shibboleth SPの前段にSSLアクセラレータを挟む場合、Shibboleth SPが動作しているサーバのホスト名と外から見えるホスト名が異なっていたり、接続を受けるポート・スキーム(HTTP/HTTPS)が異なっていたりすることで問題になる場合があります。
学認情報交換MLの以下から始まるスレッドを参考にApacheおよびShibboleth SPの設定をご確認ください。

• [upki-fed:00386] IdPとのSP接続確認のエラーについて
  • https://www.gakunin.jp/ml-archives/upki-fed/thrd8.html
• [upki-fed:276] SSLアクセラレータ環境
  • https://www.gakunin.jp/ml-archives/upki-fed/thrd6.html

さらなる情報は、Shibboleth開発元が提供している下記ページ（英語）をご参照ください。

• Deploy the Service Provider behind a Reverse Web Proxy
  https://wiki.shibboleth.net/confluence/display/SHIB2/SPReverseProxy
  ※SSLアクセラレータは"SSL offloading"と表現されています。SSLアクセラレータ自身に対する設定も記述されていますが、読み飛ばしてください。

未確認ながら、ソースIPアドレスがSSLアクセラレータのものに固定されることによって、shibboleth2.xmlの設定で checkAddress="true" としていると問題が発生すると思われますのでご注意ください。また、consistentAddress="true" は期待する動作をしない（常にconsistentであると判定され、セッションが切断されない）と思われます。

ShibRequestSetting REMOTE_ADDR X-Forwarded-For

/Shibboleth.sso/の扱い

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

既存のWebアプリケーションでサイト全体を特定のモジュールもしくはハンドラもしくはスクリプトでハンドリングするようになっている場合は、以下のどちらかの方法で対処してください。

1) /Shibboleth.sso/以下を除外
除外設定の方法はWebアプリケーションの構成により異なります。例えば、サイト全体をTomcat等にプロキシしている場合は、プロキシ設定の前に以下のような行を追加して除外してください。

ProxyPass /Shibboleth.sso !　　　　←この行を追加
ProxyPass / ajp://localhost:8009/

2) /Shibboleth.sso/に対してハンドラ上書き指定
/Shibboleth.sso/以下をmod_shibモジュールでハンドリングするように以下の通り明示的に設定してください。

<Location /Shibboleth.sso>
  SetHandler shib
</Location>

参考:

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

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

^SP3対応

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

ローカルSPで運用フェデレーションに参加しているIdPと連携する場合の設定例を以下に記載します。

SPの証明書更新の方法

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

SPのトラストアンカーに必要なCA証明書を導入する方法

技術ガイド（GakuNinShibInstall > Home > 技術ガイド > SP > SPセッティング > SPのトラストアンカーの確認と必要なCA証明書の導入）に手順が記載されています。 SPのトラストアンカーの確認と必要なCA証明書の導入 を参照してください。

環境変数から直接属性値を取得する方法

環境変数から直接属性値を取得することができるのはApacheのみとなります。他のWebサーバでは要求ヘッダを介して属性値を取得する必要があります。

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

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

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

そのため、技術ガイド > 属性 のページで公開している 属性確認用PHPプログラム がそのまま利用できない場合があります。これは 属性確認用PHPプログラム が技術ガイドで示す通りCentOS + Apacheの環境変数を利用することを前提として作られているためで、 属性確認用PHPプログラム を利用するためには各環境（OS、Webサーバ、SPのソフトウェア・バージョンなど）に合わせていただく必要があるためです。

IIS等を用いて属性値を取得する場合は、 phpinfo() （参照 : IdPとのSP接続確認） などであらかじめ変数名を確認してください。

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

DS関連情報

PHP

CentOS 5標準のphpパッケージを用いた場合に/WAYF/IDProviders.jsonにアクセスするとエラー

...