<div dir="ltr"><div>FYI, I think that I was able to figure out how to run the command while specifying the IdP URL hostname and port:</div><div><br></div><div><br>./reload-service.sh -u "<a href="https://idp01.xxxx.com:34487">https://idp01.xxxx.com:34487</a>" -id=shibboleth.MetadataResolverService -tt JKS -tp xxxxx -ts /apps/apache-tomcat-10.1.39/conf/CERTS/JLCA.jks<br></div><div><br></div><div>JLCA.jks is a JKS keystore file that contains the CA cert for the CA that issued the Shibboleth IdP's server certificate.</div><div><br></div><div>Still have the same problem with no NameID in SAMLResponse after that though.</div><div><br></div><div>Jim</div></div><div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br><table style="border-top:1px solid #d3d4de"><tr><td style="width:55px;padding-top:13px"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail" target="_blank"><img src="https://s-install.avcdn.net/ipm/preview/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" alt="" width="46" height="29" style="width: 46px; height: 29px;"></a></td><td style="width:470px;padding-top:12px;color:#41424e;font-size:13px;font-family:Arial,Helvetica,sans-serif;line-height:18px">Virus-free.<a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail" target="_blank" style="color:#4453ea">www.avast.com</a></td></tr></table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"></a></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Apr 10, 2025 at 10:01 AM o haya <<a href="mailto:ohaya1001@gmail.com">ohaya1001@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Peter, <br></div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Jim</div></div><div id="m_-8781544860204140656DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br><table style="border-top:1px solid rgb(211,212,222)"><tbody><tr><td style="width:55px;padding-top:13px"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail" target="_blank"><img src="https://s-install.avcdn.net/ipm/preview/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" alt="" width="46" height="29" style="width: 46px; height: 29px;"></a></td><td style="width:470px;padding-top:12px;color:rgb(65,66,78);font-size:13px;font-family:Arial,Helvetica,sans-serif;line-height:18px">Virus-free.<a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail" style="color:rgb(68,83,234)" target="_blank">www.avast.com</a></td></tr></tbody></table><a href="#m_-8781544860204140656_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"></a></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 10, 2025 at 4:40 AM Peter Schober via users <<a href="mailto:users@shibboleth.net" target="_blank">users@shibboleth.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">o haya via users <<a href="mailto:users@shibboleth.net" target="_blank">users@shibboleth.net</a>> [2025-04-10 09:58 CEST]:<br>
> I made changes to the attribute-resolver.xml (I think) but I also had to<br>
> remove an additional line,<br>
> "useStartTLS="%{idp.attribute.resolver.LDAP.useStartTLS:true}" from that<br>
> file, otherwise the IdP was failing to start.<br>
<br>
That shouldn't be necessary, it defaults to another property:<br>
idp.attribute.resolver.LDAP.useStartTLS = %{idp.authn.LDAP.useStartTLS:true}<br>
which according to what you've sent earlier you already set to false:<br>
idp.authn.LDAP.useStartTLS = false<br>
Doesn't matter if you've got it working that way, of course.<br>
<br>
> However, I am still getting no nameid in the SAMLResponse message when I<br>
> test :( ....<br>
<br>
The attribute resolver is necessary to get data into the IDP (into<br>
internal attributes) but it does not make NameIDs available. There's<br>
additional configuration required to create NameIDs from those<br>
internal attributes.<br>
So first test whether your IDP can resolve some attributes based on<br>
your current configuration. That's most realistic by adding SAML 2.0<br>
Metadata about a SAML Service Provider to the IDP. If you dont't have<br>
any SP metadata (N.B.: an IDP without SPs is completely pointless)<br>
here's the simplest possible SP metadata you could add to a local<br>
file, say local-sps.xml in your %{idp.home}/metadata/ directory:<br>
<br>
<EntityDescriptor entityID="<a href="https://saml.example.org" rel="noreferrer" target="_blank">https://saml.example.org</a>" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"><br>
<SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br>
<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="<a href="https://saml.example.org/not/a/real/acs-url" rel="noreferrer" target="_blank">https://saml.example.org/not/a/real/acs-url</a>" index="1"/><br>
</SPSSODescriptor><br>
</EntityDescriptor><br>
<br>
(You don't need to change anything here, this is purely to exercise<br>
the IDP's resolver for a test from the command line. Read on.)<br>
<br>
Then make sure your /opt/shibboleth-idp/conf/metadata-providers.xml<br>
has a metadata provider configured to load metadata from that file:<br>
<br>
<MetadataProvider id="LocalMetadata" xsi:type="FilesystemMetadataProvider"<br>
metadataFile="%{idp.home}/metadata/local-sps.xml"/><br>
<br>
Reload your whole metadata configuration (as per the "reloadable<br>
services" documentation,<br>
<a href="https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199507931/ReloadableServices" rel="noreferrer" target="_blank">https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199507931/ReloadableServices</a> )<br>
/opt/shibboleth-idp/bin/reload-service.sh -id shibboleth.MetadataResolverService<br>
If you later change the contents of your file local-sps.xml (e.g. by<br>
adding more SPs to it) you can reload that metadata file specifically<br>
with this command (which is faster and more efficient):<br>
/opt/shibboleth-idp/bin/reload-metadata.sh -id LocalMetadata<br>
<br>
Finally, to test whether any attributes would be sent out by the IDP<br>
to that fictitious SP (and also see their values) you could add a<br>
simple policy to your attribute-filter.xml that enumerates a few<br>
attributes your attribute-resolver.xml already defines, e.g.<br>
<br>
<AttributeFilterPolicy id="unexistingTestSP"><br>
<PolicyRequirementRule xsi:type="Requester" value="<a href="https://saml.example.org" rel="noreferrer" target="_blank">https://saml.example.org</a>" /><br>
<AttributeRule attributeID="uid" permitAny="true" /><br>
<AttributeRule attributeID="eduPersonPrincipalName" permitAny="true" /><br>
<AttributeRule attributeID="schacHomeOrganization" permitAny="true" /><br>
</AttributeFilterPolicy><br>
<br>
Reload your filter config:<br>
/opt/shibboleth-idp/bin/reload-service.sh -id shibboleth.AttributeFilterService<br>
and then test what the IDP would send out to that non-existing SAML SP<br>
using the aacli tool:<br>
<a href="https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199511404/AACLI" rel="noreferrer" target="_blank">https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199511404/AACLI</a><br>
/opt/shibboleth-idp/bin/aacli.sh --saml2 -n USER_ID_FROM_LDAP -r <a href="https://saml.example.org" rel="noreferrer" target="_blank">https://saml.example.org</a><br>
<br>
Once that test shows SAML Attributes based on data from your LDAP (or<br>
from the provided userid) you can move on to also configuring NameIDs.<br>
(I'm not sharing that part of the configuration yet so you don't get<br>
ahead of yourself.)<br>
<br>
> I was checking a bunch of other things, and was comparing to some<br>
> Shibboleth IdP metadata that I found by googling, e.g., UNC's IdP metadata,<br>
> and I was looking at the metadata from my Shibboleth IdP, and I noticed<br>
> that there are no " NameIDFormat" stanzas in the IdP metadata? (There is<br>
> also no " ArtifactResolutionService" stanza either).<br>
<br>
The software and the topics involved are much too complex to get<br>
anywhere by guessing or trial-and-error. That's a strategy you'll have<br>
to unlearn here. (And no, you don't have to care about any of this.)<br>
<br>
> Was I supposed to manually add the NameIDFormat stanzas to the IdP metadata<br>
> that got produced by the install script?<br>
<br>
No.<br>
<br>
HTH,<br>
-peter<br>
-- <br>
For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw" rel="noreferrer" target="_blank">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>
</blockquote></div>