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

Thu Apr 10 18:02:18 UTC 2025

Peter,

Actually, I decided to try what you suggested with the small metadata,
etc., and, when I tested it, the aacli command line didn't work because of
the port problem, but I tried to use a curl command with the URL that that
command prints out instead, and I *THINK* that does the same thing?

So, for example, I run the "aacli" command (FYI, the "test1" should be an
existing user in my LDAP):

/opt/shibboleth-idp/bin/aacli.sh --saml2 -n test1 -r
https://saml.example.org
(*http://localhost/idp/profile/admin/resolvertest?requester=https%3A%2F%2Fsaml.example.org&principal=test1&saml2
<http://localhost/idp/profile/admin/resolvertest?requester=https%3A%2F%2Fsaml.example.org&principal=test1&saml2>*)
Connection refused

Then I use a "curl -I" command with the URL with port "8080" (I forgot that
I did not block 8080/non-ssl on the Tomcat), and it output:

 curl -I "*http://localhost:8080/idp/profile/admin/resolvertest?requester=https%3A%2F%2Fsaml.example.org&principal=test1&saml2
> <http://localhost:8080/idp/profile/admin/resolvertest?requester=https%3A%2F%2Fsaml.example.org&principal=test1&saml2>*
> "
> HTTP/1.1 200
> Cache-Control: no-store
> Set-Cookie: __Host-JSESSIONID=5868ACB73F18CDA8D6E9012E6D57C40C; Path=/;
> Secure; HttpOnly
> X-Frame-Options: DENY
> Strict-Transport-Security: max-age=31536000
> Content-Security-Policy: frame-ancestors 'none'; base-uri 'none';
> Content-Type: text/xml;charset=utf-8
> Content-Length: 1237
> Date: Thu, 10 Apr 2025 17:29:03 GMT

>

Here's a similar test using user "test10" who doesn't exist in the LDAP:

/opt/shibboleth-idp/bin/aacli.sh --saml2 -n test10 -r
https://saml.example.org
(
http://localhost/idp/profile/admin/resolvertest?requester=https%3A%2F%2Fsaml.example.org&principal=test10&saml2)
Connection refused

curl -I "
> http://localhost:8080/idp/profile/admin/resolvertest?requester=https%3A%2F%2Fsaml.example.org&principal=test10&saml2
> "
> HTTP/1.1 200
> Cache-Control: no-store
> Set-Cookie: __Host-JSESSIONID=ABB72D99369BE72E9931E25954CE6146; Path=/;
> Secure; HttpOnly
> X-Frame-Options: DENY
> Strict-Transport-Security: max-age=31536000
> Content-Security-Policy: frame-ancestors 'none'; base-uri 'none';
> Content-Type: text/xml;charset=utf-8
> Content-Length: 600
> Date: Thu, 10 Apr 2025 17:41:19 GMT

=======================================================================================
FYI, the first test, for 'test1', didn't show any errors in the IdP log
files, but the SECOND test for 'test10' (the non-existent user), produced
errors in both idp-process.log and in idp-warn.log:

warn.log: Attribute Resolver 'ShibbolethAttributeResolver': Data connector
'myLDAP' failed
net.shibboleth.idp.attribute.resolver.NoResultAnErrorResolutionException:
No entries returned from search

process.log: 2025-04-10 13:53:54,176 - 127.0.0.1 - ERROR
[net.shibboleth.idp.profile.impl.ResolveAttributes:284] - Profile Action
ResolveAttributes: Error resolving attributes
net.shibboleth.idp.attribute.resolver.NoResultAnErrorResolutionException:
No entries returned from search

Do the results (and the difference in the logging) help identify what the
problem(s) may be?

Thanks again!!

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 12:57 PM o haya <ohaya1001 at gmail.com> wrote:

> Peter,
>
> I know that this message is out-of-order, but do you think it'd be better
> (make it easier to figure out what is going on) to try to do what you
> suggested below, rather than use the "in front IdP" that we have now?
>
> If so I can remove the current in front Idp metadata from the metadata
> directory, and add the small metadata you provided below (and add it to the
> conf/metadata.conf file).
>
> Please let me know?
>
> Thanks,
> 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>
> <#m_-4863719520253268995_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Thu, Apr 10, 2025 at 10:01 AM o haya <ohaya1001 at gmail.com> wrote:
>
>> 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>
>> <#m_-4863719520253268995_m_-5122517881634916184_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/c2544a19/attachment.htm>