Differences

This shows you the differences between two versions of the page.

--- en:shibidp:troubleshooting [2023/03/02 10:13] – Engl. version of missing logs problem Silke Meyer
+++ en:shibidp:troubleshooting [2023/03/02 12:21] (current) – [Download the metadata of your IdP/SP] Silke Meyer
@@ Line 5: / Line 5: @@
   * [[https://wiki.shibboleth.net/confluence/display/IDP4/Troubleshooting|Troubleshooting]] page in the official Shibboleth documentation
-===== Download the metadata of your IdP/SP =====
+===== Where to download the metadata of your IdP/SP =====
 Here is how you can get the metadata of your IdP or SP as they are currently published to the federation:
@@ Line 25: / Line 25: @@
 ===== The IdP does not write any log files =====
 If your IdP does not log anything at all to the files in ''/opt/shibboleth-idp/logs'' (or any custom directory you configured), please check the Tomcat log files. On a Debian server they are located in ''/var/log/tomcat9''. Watch //all// of them, e.g. with<code bash>root@idp:~# tail -f /var/log/tomcat9/*.log</code> and restart Tomcat in a different terminal window.
+===== Which attributes and attribute values were transmitted to an SP? =====
+To see the full SAML assertion, set the log level to DEBUG for idp, messages and encryption as shown above. The SAML assertion will then be written into ''idp-process.log''. Search for the string **"Assertion before encryption"**. In this example of a SAML assertion you can see that the IdP with the Entity ID https://idp.local/idp/shibboleth transmitted a persistentID (value: "NMTR6SVZOCUWF5MNGDDIYQQBY4QCB76N") as well as the attributes ''eduPersonScopedAffiliation'' (with three values) and ''eduPersonEntitlement'' (with one value) to an SP with the Entity Id https://sp1.local/shibboleth.
+<file xml /opt/shibboleth-idp/logs/idp-process.log>
+-10-27 14:54:07,079 - 127.0.0.2 - DEBUG [org.opensaml.saml.saml2.encryption.Encrypter:339] - Assertion before encryption:
+<?xml version="1.0" encoding="UTF-8"?><saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="_3a89275f3cd179685b22a3cf616c518a" IssueInstant="2020-10-27T13:54:06.179Z" Version="2.0">
+   <saml2:Issuer>https://idp.local/idp/shibboleth</saml2:Issuer>
+   <saml2:Subject>
+      <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier="https://idp.local/idp/shibboleth" SPNameQualifier="https://sp1.local/shibboleth" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">NMTR6SVZOCUWF5MNGDDIYQQBY4QCB76N</saml2:NameID>
+      <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
+         <saml2:SubjectConfirmationData Address="127.0.0.2" InResponseTo="_72e4da8e1fa8dfcea0f85a340ded8b7c" NotOnOrAfter="2020-10-27T13:59:06.581Z" Recipient="https://sp1.local/Shibboleth.sso/SAML2/POST"/>
+      </saml2:SubjectConfirmation>
+   </saml2:Subject>
+   <saml2:Conditions NotBefore="2020-10-27T13:54:06.179Z" NotOnOrAfter="2020-10-27T13:59:06.179Z">
+      <saml2:AudienceRestriction>
+         <saml2:Audience>https://sp1.local/shibboleth</saml2:Audience>
+      </saml2:AudienceRestriction>
+   </saml2:Conditions>
+   <saml2:AuthnStatement AuthnInstant="2020-10-27T13:53:52.456Z" SessionIndex="_d8a534b987abc20fe007a9cc80af7bdb">
+      <saml2:SubjectLocality Address="127.0.0.2"/>
+      <saml2:AuthnContext>
+         <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>
+      </saml2:AuthnContext>
+   </saml2:AuthnStatement>
+   <saml2:AttributeStatement>
+      <saml2:Attribute FriendlyName="eduPersonScopedAffiliation" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
+         <saml2:AttributeValue>staff@local</saml2:AttributeValue>
+         <saml2:AttributeValue>member@local</saml2:AttributeValue>
+         <saml2:AttributeValue>employee@local</saml2:AttributeValue>
+      </saml2:Attribute>
+      <saml2:Attribute FriendlyName="eduPersonEntitlement" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
+         <saml2:AttributeValue>urn:mace:dir:entitlement:common-lib-terms</saml2:AttributeValue>
+      </saml2:Attribute>
+   </saml2:AttributeStatement>
+</saml2:Assertion>
+</file>
+===== Attribute samlPairwiseID does not have any transcoding rules =====
+Shibboleth IdPs 4.x that were **upgraded from a version 3.x** do not automatically use the attribute registry. The configuration file ''attribute-Resolver.xml'' then still contains the transcoding rules for each defined attribute. When adding a new attribute definition you also have to specify a transcoding rule, or else the IdP will not be able to encode the attribute in any SP-readable form. Here is an example:<file xml /opt/shibboleth-idp/conf/attribute-resolver.xml>
+    <AttributeDefinition xsi:type="Scoped" id="samlPairwiseID" scope="%{idp.scope}">
+        <InputDataConnector ref="myStoredId" attributeNames="persistentId"/>
+        <AttributeEncoder xsi:type="SAML2ScopedString" name="urn:oasis:names:tc:SAML:attribute:pairwise-id" friendlyName="pairwise-id" encodeType="false" />
+    </AttributeDefinition>
+</file>
+Alternatively, you can reconfigure the IdP to use the attribute registry [[de:shibidp:upgrade#umstellung_auf_die_nutzung_der_attribute_registry_optional|(documentation in German)]].
+Note that the ''AttributeEncoder'' line must not be included in the attribute definition of a **newly installed IdP 4.x**. It will be fetched from the attribute registry underneath ''conf/attributes'' instead.
 ===== opensaml::SecurityPolicyException =====
@@ Line 37: / Line 87: @@
 "opensaml::FatalProfileException at (https://testsp2.aai.dfn.de/Shibboleth.sso/SAML2/POST)"
-You get this error message when the Service Provider cannot find any metadata for the Identity Provider.
+You get this error message when **the Service Provider cannot find any metadata for the Identity Provider**.
   * Check if you have added the IdP to the metadata administration tool and if it was added to the respective federation correctly (DFN-AAI-Test, DFN-AAI-Basic, or DFN-AAI).
   * Compare the Entity ID in ''conf/idp.properties'' with the one in the metadata entry. They have to be identical.
   * After a change to the federation metadata, keep in mind that you have to wait for 60-90 minutes for the metadata to be aggregated and redistributed to all SPs.
+===== No metadata returned =====
+When you see the following message in your ''idp-process.log'', **the Identity Provider cannot find any metadata for the Service Provider**:<code>INFO [org.opensaml.saml.common.binding.impl.SAMLMetadataLookupHandler:171] (...) Message Handler:  No metadata returned for
+ (...) in role {urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor</code>
+  * Please check where the IdP should know the SP from:
+    * from federation metadata?
+    * from your organisation's [[en:metadata_local|local metadata]]? (Did you add the SP as a local SP in the metadata administration tool?)
+    * from an xml metadata file that you added manually to ''conf/metadata-providers.xml''? Check the content of both files.
+  * Remember that - in the first two cases - you have to wait for 60 to 90 minutes for the changes to propagate.
 ===== The application you have accessed is not registered for use with this service =====
@@ Line 67: / Line 127: @@
   * Check the IdP's DEBUG-Log. Compare the saml:Issuer from the AuthnRequest with the EntityID you are trying to contact. If there is a different issuer string in the Authentication Request the IdP cannot find the issuer in the federation metadata. Contact the SP operator in this case.
+===== DecryptNameIDFailed =====
+If you see the error message "A non-proceed event occurred while processing the request: DecryptNameIDFailed" this might be after a certificate rollover and maybe it only occurs upon Single Logout. The Service Provider has encrypted data with a certificate for which the IdP does not have a private key (any more). Remove the old certificate from the metadata and wait for 60 to 90 minutes. By then, the information to only use the new certificate has propagated.
+===== Reset a configuration file to default =====
+Your IdP keeps copies of all original files in the folder ''dist/conf''. Here you can fetch files, if you want to start over or if you want to see what the original file looks like in the latest installed IdP version.
+===== Duplicate attributes in Shibboleth IdP 4.x =====
+If you notice that your IdP 4.x transmits duplicate attributes, you probably have copied the file ''conf/attribute-resolver.xml'' from an IdP 3.x without adapting it. The IdP has duplicate transcoding rules: once in ''conf/attribute-resolver.xml'' and once in the Attribute Registry. Remove the Attribute Encoder lines from the resolver configuration so that it looks like in [[de:shibidp:config-attributes-minimal|this example]].
+===== Duplicate Transcoding Rule =====
+If you get the error message below, you probably have a duplicate attribute in your Attribute Registry. Maybe you imported attributes from a file like our dfnMisc.xml ([[de:shibidp:config-attributes#edupersontargetedid_und_andere_verbreitete_attribute_hinterlegen|German documentation]]) **and** you have defined one of the attributes in an individual .properties file underneath ''conf/attributes/custom/''? Make sure that each attribute exists in the Attribute Registry exactly once.
+<code bash>java.lang.IllegalArgumentException: {urn:oasis:names:tc:SAML:2.0:assertion}NameID is
+already the child of another XMLObject and may not be inserted into this list</code>
+===== IdP/SP is no longer part of the eduGAIN metadata =====
+Our downstream eduGAIN metadata (the eduGAIN metadata we distribute to DFN-AAI) have never contained entities from DFN-AAI. We filter them out because your systems already know them from DFN-AAI metadata and we do not want to distribute duplicates. To check whether an entity is part of the eduGAIN metadata, please search for it in the [[https://technical.edugain.org/entities|eduGAIN Entities Database]].
 ===== IdP is not displayed in Discovery Services =====
@@ Line 76: / Line 153: @@
   * You have ticked the checkbox "hide from discovery" in the IdP's settings in the metadata administration tool. Remove the tick and wait for 60-90 minutes.
+===== SP Metadata: AuthnRequestsSigned and WantAssertionsSigned =====
+A Service Provider can announce in its metadata that it
+  * signs Authentication Requests it sends to IdPs, and/or
+  * wants to get signed SAML assertions back.
+Our metadata administration tool only displays this information if it is included in the xml files upon initial upload to the metadata administration. Please extend your SP metadata like this:<code xml><md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"></code>
 {{tag>idp4 troubleshooting debugging debug logging}}

idp4 troubleshooting debugging debug logging