Differences

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

--- en:shibidp:troubleshooting [2023/03/02 10:23] – Engl. version of how to find the SAML assertion 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 63: / Line 63: @@
 </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.
@@ Line 76: / 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 106: / 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 115: / 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