...

IdP起動時のエラー(The entity name must immediately follow the '&' in the entity reference)

IdPを起動時に下記のエラーが idp-process.log に出力されます。

14:51:13.419 - INFO [edu.internet2.middleware.shibboleth.common.config.BaseService:158] - Loading new configuration for service shibboleth.RelyingPartyConfigurationManager
14:51:13.506 - ERROR [edu.internet2.middleware.shibboleth.common.config.BaseService:188] - Configuration was not loaded for shibboleth.RelyingPartyConfigurationManager service, error creating components.  The root cause of this error was: org.xml.sax.SAXParseException: The entity name must immediately follow the '&' in the entity reference.

→上記のエラーは relying-party.xml にXML文法としての間違いがある場合に出力されます。
→例えば relying-party.xml にパスフレーズ付きの証明書を設定するとき、パスフレーズに '&' や '<' を含む場合はこれらの文字列をそのまま設定することはできません。これらの文字を含む場合は文字参照で & や < のように記述してください。

• 誤ったパスフレーズ設定例

  パネル
  <security:Credential id="IdPCredential" xsi:type="security:X509Filesystem">         <security:PrivateKey Password="myKeyPa$$word&">                 /opt/shibboleth-idp/credentials/server-enc.key         </security:PrivateKey>

• 正しいパスフレーズ設定例

  パネル
  <security:Credential id="IdPCredential" xsi:type="security:X509Filesystem">         <security:PrivateKey Password="myKeyPa$$word&amp;">                 /opt/shibboleth-idp/credentials/server-enc.key         </security:PrivateKey>

IdP起動時のエラー (javax.net.ssl.SSLPeerUnverifiedException: SSL peer failed hostname validation for name: null)

IdP起動時のメタデータ取得に際し、下記のエラーが idp-process.log に出力されます。

...

...

...

...

...

...

...

...

...

...

→ SSLv3のみをサポートしたWebサーバ（TLSv1.0, TLSv1.1, TLSv1.2等をサポートしていない）からメタデータを取得するときに出力されるエラーメッセージです。

→ relying-party.xmlのメタデータ取得の設定で、MetadataProviderのオプション disregardSslCertificate="true" を設定した場合、もしくはIdP 2.3.xの場合には下記の通りエラーログが変化します。 disregardSslCertificate の詳細は https://wiki.shibboleth.net/confluence/display/SHIB2/IdPMetadataProvider#IdPMetadataProvider-FileBackedHTTPMetadataProvider をご参照ください。

...

...

→ 上記「

→ IdP 2.4.3においてはMetadataProviderのオプション disregardSslCertificate の設定の有無に関係なく、JDKのオプション -Dcom.sun.net.ssl.rsaPreMasterSecretFix=true を設定することで、SSLv3のみをサポートしたWebサーバからメタデータの取得ができることを確認しています。
※SSLv3のみサポートしたWebサーバとして CentOS 6 (httpd-2.2.15-39.el6.centos.x86_64) で確認していますが、他のWebサーバ実装ではJDKのオプションを設定せずにメタデータが取得できるかもしれません。この場合上記オプションを設定することで逆にエラーになる可能性がありますのでご注意ください。

IdPで認証前にブラウザにエラー(SAML 2 SSO profile is not configured for relying party)

Error Message: SAML 2 SSO profile is not configured for relying party https://sp.example.ac.jp/shibboleth-sp

IdPで認証時にブラウザにエラー(Message was signed, but signature could not be verified)

...

IdPで認証時にブラウザにエラー(Message expired, was issued too long ago)

Shibboleth認証時にブラウザに下記のエラーが出力されます。

opensaml::SecurityPolicyException
The system encountered an error at Tue Apr 30 12:13:14 2013
To report this problem, please contact the site administrator at root@localhost.
Please include the following message in any email:
opensaml::SecurityPolicyException at (https://sp.example.ac.jp/Shibboleth.sso/SAML2/POST)
Message expired, was issued too long ago.

→IdPが動作しているホストの時刻がずれている場合に出力されます。NTPなどでホストの時刻を修正してください。
→参考情報 : https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTroubleshootingCommonErrors#NativeSPTroubleshootingCommonErrors-opensamlSecurityPolicyExceptionMessageexpiredwasissuedtoolongago

IdPで認証時にエラー

→ IdPが運用フェデレーションとテストフェデレーションの双方に同一のentityIDで参加している場合に、認証エラーとなることがあります。これはテストフェデレーション側のメタデータに掲載されている証明書情報が誤って取り込まれることが原因と推定されています。テストフェデレーション側のIdPについて実運用のIdPと異なるentityIDを利用するなどし、テストフェデレーション側のIdPは廃止申請すると問題の切り分けが行いやすくなります。

→ 関連して、運用フェデレーションで実運用中のIdPにおいて、テストフェデレーションのメタデータを読み込んでいる場合には、テストフェデレーションのメタデータ読み込み設定を削除してください。運用フェデレーションのメタデータのみを読み込む設定としたほうがより原因を追究しやすい状態となります。

→ transientIdが必須となっているSPにおいて、IdP側でtransientIdの送出が制限されている場合にエラーとなる場合があります。要求されている属性が正しく送出されているにも関わらず認証エラーとなる場合にはtransientIdの送出の有無を確認しておくと問題の切り分けに役立ちます。

→ SPが要求している属性と異なる属性を送出している場合にもエラーとなります。学認のIdP・SP一覧（https://www.gakunin.jp/participants/）で指定されている属性とattribute-filter.xmlの設定が一致しているか見直してください。attribute-filter.xmlを設定後、 設定・運用・カスタマイズ#SPに対してどのような属性が送出されるか確認する方法 の手順で実際に送出される属性を確認することができます。特に「eduPersonAffiliation （スコープなし）」と「eduPersonScopedAffiliation （スコープあり）」は似ていることもあり、間違えやすいことから注意が必要です。

IdPで認証時にTomcatのエラー

Shibboleth認証時にブラウザに503エラーが出力され、Tomcatに下記のログが出力されます。

[Thu Jun 19 17:00:00 2014] [error] (70007)The timeout specified has expired: ajp_ilink_receive() can't receive header
[Thu Jun 19 17:00:00 2014] [error] ajp_read_header: ajp_ilink_receive failed
[Thu Jun 19 17:00:00 2014] [error] (120006)APR does not understand this error code: proxy: read response failed from [::1]:8009 (localhost)

→ IdPが正しく動作していない可能性があります。Tomcatを再起動することで解消するとの報告があります。

→ [upki-fed:00493] でも同様の問題が発生していたとの報告があります。

Tomcat 6.0.43およびそれ以降でのBack-Channel接続のエラー

IdPで使用しているTomcatについて、Tomcat 6.0.43およびそれ以降にアップデートしたあとにSPのログ（/var/log/shibboleth/shibd.log）に以下のエラーが出力され、Back-Channelの接続に失敗します。　（[upki-fed:00925] Tomcat 6.0.43でのBack-Channel接続の不具合について）

ERROR Shibboleth.AttributeResolver.Query [3]: exception during SAML query to https://IdPのホスト名:8443/idp/profile/SAML1/SOAP/AttributeQuery: CURLSOAPTransport failed while contacting SOAP endpoint (https://IdPのホスト名:8443/idp/profile/SAML1/SOAP/AttributeQuery): error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown
ERROR Shibboleth.AttributeResolver.Query [3]: unable to obtain a SAML response from attribute authority

→ この問題に対応した tomcat6-dta-ssl-2.0.0.jar が公開されました （Updated Tomcat 6 Connector, JCONN-2）。

→ Tomcat 6.0.43およびそれ以降のバージョンをご利用の場合は学認技術ガイドの手順（IdP > IdPセッティング > サーバ証明書の設定(IdP) > ２．ライブラリのコピー）に従い tomcat6-dta-ssl-2.0.0.jar を導入し、旧jarファイル tomcat6-dta-ssl-1.0.0.jar（もしあれば tomcat6-dta-ssl-1.1.0.jar も）を削除してください。

Caused by: java.lang.UnsupportedClassVersionError: edu/internet2/middleware/security/tomcat6/DelegateToApplicationJSSEImplementation : Unsupported major.minor version 51.0

JDK 8u60 , 8u51 , 7u85 , 6u101でのメタデータ取得エラー

IdPで利用しているJDKを JDK 8 update 51もしくは60, 7 update 85, 6 update 101 へアップデートした場合に、メタデータ取得にてエラーとなる問題が報告されています。  （Shib Users ML: Shib IdP - Metadata Download and Java 1.7.0_85）
該当するJDKにアップデートした場合、新規に参加したSPとの連携ができない、また保持しているメタデータの有効期限が切れたあとにはすべてのSPと連携できない状態となりますのでご注意ください。

ERROR [org.opensaml.saml2.metadata.provider.HTTPMetadataProvider:273] - [Timer-0:] - Error retrieving metadata 
from https://metadata.gakunin.nii.ac.jp/gakunin-metadata.xml javax.net.ssl.SSLPeerUnverifiedException: SSL peer
 failed hostname validation for name: (メタデータリポジトリのIPアドレス)

※適宜改行を入れていますが実際には一行で出力されます。
→ Tomcatを起動するときのオプションに「-Djdk.tls.trustNameService=true」をつけて起動することで問題が回避できます。

JAVA_OPTS="${JAVA_OPTS} -Djdk.tls.trustNameService=true"

attribute-filter.xmlに属性を送信するように設定しているはずなのに送信されない。

→attribute-filter.xml中のAttributeFilterPolicy要素のidが重複していると、最後のものしか有効にならないようです。idが重複しないように修正してください。

2.3.8もしくはそれ以前のIdPで認証前にログにエラー

1:19:57.770 - ERROR [org.opensaml.xml.security.SigningUtil:250] - Error during signature verification java.security.SignatureException: Signature length not correct: got 256 but was expecting 128

ブラウザには以下のエラーが表示されます。

Error Message: Message did not meet security requirements

以下の条件を全て満たす場合、認証要求(AuthnRequest)の署名検証時に確率的に問題が発生することが確認されています。IdPのバグで、2.4.0で修正されました。SPメタデータに記載されている不要な証明書を削除することにより回避可能です。
詳細: https://issues.shibboleth.net/jira/browse/JXT-99

1. IdPがJava 7を使用している。
2. 接続しようとしているSPのメタデータに1024bitの証明書と2048bitの証明書が混在している。
3. SPが認証要求(AuthnRequest)に署名している。

aacli.shが実行できない問題の対処（その1）

Shibboleth IdPにはaacli.shというコマンドがあり、任意のSP(entityID)と任意のユーザ名を引数に与えることでSPに送出される属性がXMLで取得できます。IdP 2.3.5 ～ IdP 2.3.8ではIdPに含まれるファイルが変更となった影響でそのまま実行すると NoClassDefFoundError となります。

$ sudo -u tomcat /opt/shibboleth-idp/bin/aacli.sh --configDir /opt/shibboleth-idp/conf/ --principal=test001 --requester=https://sp.example.ac.jp/shibboleth-sp
Exception in thread "main" org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'shibboleth.HandlerManager': Initialization of bean failed; nested exception is java.lang.NoClassDefFoundError: javax/servlet/ServletRequest
       at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:480)
                    :

→ 上記エラーが出力された場合はTomcatのjarファイルを参照するようにしてください。

$ sudo ln -s $CATALINA_HOME/lib/servlet-api.jar /opt/shibboleth-idp/lib/

→ aacli.shコマンドの詳細は 設定・運用・カスタマイズ > SPに対してどのような属性が送出されるか確認する方法 と https://wiki.shibboleth.net/confluence/display/SHIB2/AACLI をご参照ください。
→ 参考情報 : 情報交換メーリングリストupki-fed:00419

aacli.shが実行できない問題の対処（その2）

StoredIDを用いている場合、mysql-connector-java-5.1.xx-bin.jar等のJDBCドライバーが適切に配置されていないと、下記のエラーになります。
Shibboleth IdPでStoredIDを利用するための設定方法(MySQL)を参照して /opt/shibboleth-idp/lib/ および /usr/java/tomcat/webapps/idp/WEB-INF/lib/ に配置されていることを確認してください。

# ./bin/aacli.sh --configDir=conf/ --principal="test001" --requester="https://test-sp1.gakunin.nii.ac.jp/shibboleth-sp"
Exception in thread "main" org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'shibboleth.AttributeResolver': Invocation of init method failed; nested exception is edu.internet2.middleware.shibboleth.common.service.ServiceException: Configuration was not loaded for shibboleth.AttributeResolver service, error creating components.
...
Caused by: edu.internet2.middleware.shibboleth.common.service.ServiceException: Configuration was not loaded for shibboleth.AttributeResolver service, error creating components.
...
Caused by: org.springframework.beans.factory.BeanCreationException: Unable to create relational database connector, JDBC driver can not be found on the classpath
        at edu.internet2.middleware.shibboleth.common.config.attribute.resolver.dataConnector.StoredIDDataConnectorBeanDefinitionParser.buildApplicationManagedConnection(StoredIDDataConnectorBeanDefinitionParser.java:169)
...

ローカルに配置したSPメタデータの証明書更新時のエラー

フェデレーションに参加していないローカルのSPなどにおいて、SP管理者からの指示に従って「https://sp.example.ac.jp/Shibboleth.sso/Metadata」といったURLから取得したメタデータをIdPのローカルに配置して運用している場合、SP側の証明書更新時にエラーが発生する場合があります。（「.../Shibboleth.sso/Metadata」からダウンロードできるファイルはShibboleth SPが自動生成するメタデータです）

例え学認の「メタデータ記載の証明書更新手順（SP）」に倣ってSPが慎重に証明書更新を行っている場合でも、SPメタデータとして /Shibboleth.sso/Metadata を参照している限り発生する可能性があります。以下でその理由をステップバイステップで見ていきます。

メタデータ記載の証明書更新手順（SP） の「1日目　 SPに対して設定変更1（新証明書を暗号化用として追加）」をSPで実施すると、「.../Shibboleth.sso/Metadata」からダウンロードできるSPメタデータにも新しい証明書が追加されます。新しいメタデータはShibboleth SPの設定に従ってKeyDescriptorに use="encryption" という暗号化用途のみで利用するための設定が追加されます。

...

SP管理者からの通知に従い、IdP管理者はSPが自動生成するファイルを取得してIdPのローカルにあるメタデータを更新します。

学認に参加しているSPでは メタデータ記載の証明書更新手順（SP） の「X日目　 承認、学認メタデータに反映」に該当する部分です。

...

旧証明書 : 署名&暗号化用途
新証明書 : 暗号化用途

...

メタデータ記載の証明書更新手順（SP） の「X+15日目　SPに対して設定変更2（新証明書をメインにし旧証明書を暗号化用に変更）」をSPで実施します。この瞬間、SPに設定された証明書の用途とIdPが想定する証明書の用途に不一致が発生してしまいます。つまりSPは設定通り署名用途として新証明書を使いますが、IdPは新証明書は暗号化用途のみに使えるものと考えているためにこれを受け付けません。IdPでローカルに配置したメタデータが更新されるまでの間この状態が続き、エラーとなることが考えられます。

...

旧証明書 : 暗号化用途
新証明書 : 署名&暗号化用途

...

IdPにエラー(net.shibboleth.idp.attribute.resolver.NoResultAnErrorResolutionException: No entries returned from search)

IdPで認証時にエラー

IdPで認証時のエラーにより再ログインが要求される (Exception unwrapping data: Tag mismatch!)

IdPで認証時にTomcatのエラー

Tomcat 6.0.43およびそれ以降でのBack-Channel接続のエラー

JDK 8u60 , 8u51 , 7u85 , 6u101でのメタデータ取得エラー

attribute-filter.xmlに属性を送信するように設定しているはずなのに送信されない。

2.3.8もしくはそれ以前のIdPで認証前にログにエラー

aacli.shが実行できない問題の対処（その1）

aacli.shが実行できない問題の対処（その2）

ローカルに配置したSPメタデータの証明書更新時のエラー

SAMLレスポンスを取得する方法

学認申請システムが自動生成するattribute-filter取得時のエラー

SP関連

SPで認証後にエラー(A valid authentication statement was not found in the incoming message)

その後「Y+15日目　SPに対して設定変更3（旧証明書削除）」でも問題が生じます。この時点で3.で自動生成されたメタデータがIdPのローカルに配置されていますが、これに暗号化用途の旧証明書が含まれているため、依然としてIdPは旧証明書を暗号化用途に用い、設定変更3が行われたSPではそれを復号できずにエラーとなります。このエラーもIdPでローカルに配置したメタデータが更新されるまで続くことになります。

...

旧証明書 : 不使用
新証明書 : 署名&暗号化用途

...

→ この問題の原因はSPが自動生成したメタデータをそのままIdP側で利用することにあります。 2. において、IdPのローカルに配置するメタデータから新証明書のKeyDescriptorに設定されているuse属性を削除することで、SPの設定変更に影響を受けずにメタデータの更新を行うことができます。（useを指定しない場合は暗号化用途 (encryption) 、署名用途 (signing) のどちらにも利用できるため）
同様に、3.（設定変更2）の後でIdPのローカルに配置するメタデータからは旧証明書を削除しなければなりません。

→ 学認申請システムでは、上記でご紹介した手順と同じで メタデータ記載の証明書更新手順（SP） の「1日目　 学認申請システムにて証明書を追加（予備の欄に）」を行ったときには、新証明書のKeyDescriptorのuse属性は設定していません。もちろんX+15日目の旧証明書を削除する申請が承認された段階でSPメタデータから旧証明書が削除されます。

SAMLレスポンスを取得する方法

トラブルシューティングのときにSPからSAMLレスポンスを確認したいとの要望を受けることがあります。SAMLレスポンスを取得する方法としてブラウザのJavaScriptを無効にすることでPOSTするデータを取得する方法がありますので、以下に手順を示します。

1. 対象のSPへアクセスし、DSを経由してIdPのログイン画面を表示します。
2. 末尾に記載した手順でJavaScriptを無効にします。
3. 続けてIdPで認証すると、SPにリダイレクトされるときに以下のページが表示されます。

   Note: Since your browser does not support JavaScript, you must press the Continue button once to proceed.

4. 右クリックで表示されるメニューから「ページのソースを表示する」を選択してください。「input type="hidden" name="SAMLResponse" ～」行の value の値がSAMLレスポンスとなります。
5. SAMLレスポンスの取得が完了したら、以下の手順の逆の操作を行い設定を元に戻してください。

Firefoxの場合は、以下の手順でJavaScriptを無効にできます。

1. アドレスバーに「about:config」を入力します。検索窓に「javascript.enabled」を入力すると現在の設定値が出てきますので、ダブルクリックしてtrueからfalseに変更します。

Internet Explorerの場合は、以下の手順でJavaScriptを無効にできます。

1. インターネットオプションから「セキュリティ」タブを開きます。
2. レベルのカスタマイズをクリックし、スクリプト > アクティブスクリプト で「無効にする」を選択後、OKをクリックします。

学認申請システムが自動生成するattribute-filter取得時のエラー

attribute-filterの自動生成機能を使う で紹介されている学認申請システムが生成するattribute-filterを自動取得しているIdPで次のエラーが発生します。（upki-fed:00948）

• 「a) 学認申請システムが生成したattribute-filterを直接読み込む方法」を採用している場合

  書式設定済み

  12:55:10.810 - WARN [org.opensaml.util.resource.ResourceChangeWatcher:168] - Resource https://office.gakunin.nii.ac.jp/ProdFed/export/attribute_filter/PIxxxxJP?target=uapprovejp221 could not be accessed org.opensaml.util.resource.ResourceException: Unable to contact resource URL: https://office.gakunin.nii.ac.jp/ProdFed/export/attribute_filter/PIxxxx?target=uapprovejp221 at org.opensaml.util.resource.HttpResource.exists(HttpResource.java:94) ~[openws-1.4.4.jar:na] at org.opensaml.util.resource.FileBackedHttpResource.exists(FileBackedHttpResource.java:120) ~[openws-1.4.4.jar:na] at org.opensaml.util.resource.ResourceChangeWatcher.run(ResourceChangeWatcher.java:149) ~[openws-1.4.4.jar:na] at java.util.TimerThread.mainLoop(Timer.java:534) [na:1.6.0_22] at java.util.TimerThread.run(Timer.java:484) [na:1.6.0_22] Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) ~[na:1.6.0_22] at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1697) ~[na:1.6.0_22] (...省略...) Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:324) ~[na:1.6.0_22] at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:224) ~[na:1.6.0_22] at sun.security.validator.Validator.validate(Validator.java:235) ~[na:1.6.0_22] at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:147) ~[na:1.6.0_22] at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:230) ~[na:1.6.0_22] at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:270) ~[na:1.6.0_22] at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1144) ~[na:1.6.0_22] ... 21 common frames omitted Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:197) ~[na:1.6.0_22] at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:255) ~[na:1.6.0_22] at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:319) ~[na:1.6.0_22] ... 27 common frames omitted

  → JDKのトラストアンカーに必要なCA証明書が入っていないことが原因です。「IdPのトラストアンカーの確認と必要なCA証明書の導入」にしたがって， パッケージのアップデート，またはCA証明書の導入を行ってください。

• 「b) 学認申請システムが生成したattribute-filterをローカルにダウンロードした上で読み込む方法」を採用している場合

  書式設定済み

  $ wget https://office.gakunin.nii.ac.jp/ProdFed/export/attribute_filter/PIxxxxJP?target=uapprovejp221 --2015-06-29 19:12:37-- https://office.gakunin.nii.ac.jp/ProdFed/export/attribute_filter/PIxxxxJP?target=uapprovejp221 office.gakunin.nii.ac.jp をDNSに問いあわせています... 157.1.67.71 office.gakunin.nii.ac.jp|157.1.67.71|:443 に接続しています... 接続しました。 エラー: office.gakunin.nii.ac.jp の証明書(発行者: /C=JP/O=SECOM Trust Systems CO.,LTD./CN=SECOM Passport for Web EV 2.0 CA)の検証に失敗しました: 発行者の権限を検証できませんでした。 office.gakunin.nii.ac.jp に安全の確認をしないで接続するには、`--no-check-certificate' を使ってください。 SSL による接続が確立できません。

  → wget等のコマンドが参照するトラストアンカーに必要なCA証明書が入っていないことが原因です。「SPのトラストアンカーの確認と必要なCA証明書の導入」にしたがって， パッケージのアップデート，またはCA証明書の導入を行ってください。SP向けの手順としてご紹介していますが，今回のようなIdPにおけるwgetコマンド等の対処でも手順は同じです。

SP関連

opensaml::FatalProfileException
...
opensaml::FatalProfileExceptionat (https://sp.example.ac.jp/Shibboleth.sso/SAML2/POST)
A valid authentication statement was not found in the incoming message.

→SPメタデータに記載されている証明書がSPにインストールされていない。
加えて、SPメタデータに複数証明書が記載されており、その一部がインストールされていない場合、タイミングによってエラーになったりならなかったりするので特に注意が必要。

SPからDSに遷移したときにDSでエラー （その1）

SPからDSに遷移したときにDSにて以下のようにブラウザにエラーが表示される。

    エラー: 無効なクエリです
    The return URL 'https://sp.example.ac.jp/Shibboleth.sso/DS' could not be verified for Service Provider 'https://sp.example.ac.jp/shibboleth-sp'.

→学認技術ガイドに従ってSPを設定した場合、DSからのリターンURLは 'https://HOSTNAME/Shibboleth.sso/DS' となります。学認申請システムでSPの登録を行なうときに「DSからのリターンURL 」項目がこの値になっていない場合には上記のエラーが表示されます。

→なお、学認技術ガイドの「２．DSサーバの参照設定を行います。」において、SessionInitiatorのLocationを変更した場合にはDSからのリターンURLも変わります。例えば <SessionInitiator type="Chaining" Location="/ABC"...> としたときのDSからのリターンURLは 'https://HOSTNAME/Shibboleth.sso/ABC' となります。また、shibboleth2.xmlにSessionInitiatorが1つも存在しない場合にはデフォルト値の 'https://HOSTNAME/Shibboleth.sso/Login' を使用してください。

SPからDSに遷移したときにDSでエラー （その2）

エラー: 無効なクエリです
リターンURL 'https://sp.example.ac.jp/Shibboleth.sso/DS' はSP 'https://SP.example.ac.jp/shibboleth-sp' のものとみなされません

→ 例えば、学認申請システムにentityIDを「https://SP.example.ac.jp/shibboleth-sp」（ホスト部の SP だけが大文字）のように登録したときにDSでこのようなエラーが発生します。DSでは大文字・小文字を区別して動作しますが、DNSにおいてホスト名は大文字・小文字を区別しないことが一般的です。利用する環境によっては大文字のホスト名が自動的に小文字で処理されることがあり、エラーとなります。エラー画面が表示されているときのアドレスバーに注目しますと、 return= から始まる部分が自動的に小文字となってしまっていることが確認できると思います。

https://test-ds.gakunin.nii.ac.jp/WAYF?entityID=https%3A%2F%2FSP.example.ac.jp%2Fshibboleth-sp&return=https%3A%2F%2Fsp.example.ac.jp%2FShibboleth.sso%2F...

SAML2でバックチャネル接続エラー

SAML2でIdPに接続したときに下記のようなバックチャネルの接続エラーが発生することがあります。

2012-11-16 17:45:00 ERROR Shibboleth.AttributeResolver.Query [6]: exception during SAML query to https://idp.example.ac.jp:8443/idp/profile/SAML2/SOAP/AttributeQuery: CURLSOAPTransport failed while contacting SOAP endpoint (https://idp.example.ac.jp:8443/idp/profile/SAML2/SOAP/AttributeQuery): connect() timed out!
2012-11-16 17:45:00 ERROR Shibboleth.AttributeResolver.Query [6]: unable to obtain a SAML response from attribute authority

→上記のエラーはIdP(idp.example.ac.jp)のattribute-filter.xmlに接続元SPへの属性送出設定がない(属性が受け渡されない)とき、SAML2でBack-Channelポートにfallbackするため発生します。IdP側のファイアウォールなどでBack-Channel(ポート8443)への接続が許可されていない場合にタイムアウトとなることがあります。いずれにしろ設定により属性は渡されませんので、このエラーによる実害は（ブラウザ表示の遅延以外は）特にありません。
→SAML2対応IdPのみ接続するときに「SPでBack-Channelを使用しないようにする設定」を以下に記載します。学認外のIdPと連携する場合など、SAML1で属性受け渡しをする可能性があるときは属性取得できなくなりますので、SAML2でかつBack-Channelを利用しないときだけに用いてください。

• /etc/shibboleth/shibboleth2.xml で次の部分をコメントアウト

  パネル
  <!-- Use a SAML query if no attributes are supplied during SSO. -->         <!--         <AttributeResolver type="Query" subjectMatch="true"/>         -->

SPからDSに遷移したときにDSでエラー （その1）

SPからDSに遷移したときにDSでエラー （その2）

SAML2でバックチャネル接続エラー

SP起動時のエラー(error while loading resource (/etc/shibboleth/shibboleth2.xml): XML error(s) during parsing, check log for specifics)

SPを起動時に下記のエラーが出力されます。

$ sudo /etc/init.d/shibd start
Starting shibd: configuration is invalid, check console for specific problems
                                                           [FAILED]

また /var/log/shibboleth/shibd.log には下記のエラーが出力されています。

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

→上記のエラーは shibboleth2.xml にXML文法としての間違いがある場合に出力されます。
→例えばCredentialResolverにパスフレーズ付きの証明書を設定するとき、パスフレーズに '&' や '<' を含む場合はこれらの文字列をそのまま設定することはできません。これらの文字を含む場合は文字参照で & や < のように記述してください。

...

誤ったパスフレーズ設定例

正しいパスフレーズ設定例

...