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

[o haya]

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>
<#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_-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/e48249ff/attachment.htm>