Shibboleth IdP is partially working with LDAP, but SAMLResponse NameID (and attributes) are missing

[Peter Schober]

o haya via users <users at shibboleth.net> [2025-04-10 09:58 CEST]:
> I made changes to the attribute-resolver.xml (I think) but I also had to
> remove an additional line,
> "useStartTLS="%{idp.attribute.resolver.LDAP.useStartTLS:true}" from that
> file, otherwise the IdP was failing to start.

That shouldn't be necessary, it defaults to another property:
  idp.attribute.resolver.LDAP.useStartTLS = %{idp.authn.LDAP.useStartTLS:true}
which according to what you've sent earlier you already set to false:
  idp.authn.LDAP.useStartTLS = false
Doesn't matter if you've got it working that way, of course.

> However, I am still getting no nameid in the SAMLResponse message when I
> test :( ....

The attribute resolver is necessary to get data into the IDP (into
internal attributes) but it does not make NameIDs available. There's
additional configuration required to create NameIDs from those
internal attributes.
So first test whether your IDP can resolve some attributes based on
your current configuration. That's most realistic by adding SAML 2.0
Metadata about a SAML Service Provider to the IDP. If you dont't have
any SP metadata (N.B.: an IDP without SPs is completely pointless)
here's the simplest possible SP metadata you could add to a local
file, say local-sps.xml in your %{idp.home}/metadata/ directory:

  <EntityDescriptor entityID="https://saml.example.org" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
    <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
      <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://saml.example.org/not/a/real/acs-url" index="1"/>
    </SPSSODescriptor>
  </EntityDescriptor>

(You don't need to change anything here, this is purely to exercise
the IDP's resolver for a test from the command line. Read on.)

Then make sure your /opt/shibboleth-idp/conf/metadata-providers.xml
has a metadata provider configured to load metadata from that file:

  <MetadataProvider id="LocalMetadata" xsi:type="FilesystemMetadataProvider"
   metadataFile="%{idp.home}/metadata/local-sps.xml"/>

Reload your whole metadata configuration (as per the "reloadable
services" documentation,
https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199507931/ReloadableServices )
  /opt/shibboleth-idp/bin/reload-service.sh -id shibboleth.MetadataResolverService
If you later change the contents of your file local-sps.xml (e.g. by
adding more SPs to it) you can reload that metadata file specifically
with this command (which is faster and more efficient):
  /opt/shibboleth-idp/bin/reload-metadata.sh -id LocalMetadata

Finally, to test whether any attributes would be sent out by the IDP
to that fictitious SP (and also see their values) you could add a
simple policy to your attribute-filter.xml that enumerates a few
attributes your attribute-resolver.xml already defines, e.g.

<AttributeFilterPolicy id="unexistingTestSP">
  <PolicyRequirementRule xsi:type="Requester" value="https://saml.example.org" />
  <AttributeRule attributeID="uid" permitAny="true" />
  <AttributeRule attributeID="eduPersonPrincipalName" permitAny="true" />
  <AttributeRule attributeID="schacHomeOrganization" permitAny="true" />
</AttributeFilterPolicy>

Reload your filter config:
  /opt/shibboleth-idp/bin/reload-service.sh -id shibboleth.AttributeFilterService
and then test what the IDP would send out to that non-existing SAML SP
using the aacli tool:
https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199511404/AACLI
  /opt/shibboleth-idp/bin/aacli.sh --saml2 -n USER_ID_FROM_LDAP -r https://saml.example.org

Once that test shows SAML Attributes based on data from your LDAP (or
from the provided userid) you can move on to also configuring NameIDs.
(I'm not sharing that part of the configuration yet so you don't get
ahead of yourself.)

> I was checking a bunch of other things, and was comparing to some
> Shibboleth IdP metadata that I found by googling, e.g., UNC's IdP metadata,
> and I was looking at the metadata from my Shibboleth IdP, and I noticed
> that there are no " NameIDFormat" stanzas in the IdP metadata?  (There is
> also no " ArtifactResolutionService" stanza either).

The software and the topics involved are much too complex to get
anywhere by guessing or trial-and-error. That's a strategy you'll have
to unlearn here.  (And no, you don't have to care about any of this.)

> Was I supposed to manually add the NameIDFormat stanzas to the IdP metadata
> that got produced by the install script?

No.

HTH,
-peter