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

[o haya]

Peter,

I already have metadata for an SP in the /opt/shibboleth/metadata directory
and in the metadata.conf file.  Recall that I had the SP data from that
other IdP (and I checked and it has SPSSO...), but would that SP be active
automatically?  Or do I have to run that script that you mentioned?

I just tried the script and it fails because my IdP is not on localhost
port 443, so I think I figured out how to still run it specifying a URL,
but then it having a cert chain error.

I've tried using the parameter for pointing to the script to a trustore
containing the CA that issued my IdPs server cert, but that isn't working
either.

Jim

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, Apr 10, 2025 at 4:40 AM Peter Schober via users <
users at shibboleth.net> wrote:

> 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
> --
> For Consortium Member technical support, see
> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20250410/2ff8d6c5/attachment.htm>