<div dir="ltr"><div>Peter,</div><div><br></div><div>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?</div><div><br></div><div>So, for example, I run the "aacli" command (FYI, the "test1" should be an existing user in my LDAP):</div><div><br></div><div>/opt/shibboleth-idp/bin/aacli.sh --saml2 -n test1 -r <a href="https://saml.example.org">https://saml.example.org</a><br>(<b><i><a href="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</a></i></b>) Connection refused</div><div><br></div><div>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:</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> curl -I "<b><i><a href="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</a></i></b>"<br>HTTP/1.1 200<br>Cache-Control: no-store<br>Set-Cookie: __Host-JSESSIONID=5868ACB73F18CDA8D6E9012E6D57C40C; Path=/; Secure; HttpOnly<br>X-Frame-Options: DENY<br>Strict-Transport-Security: max-age=31536000<br>Content-Security-Policy: frame-ancestors 'none'; base-uri 'none';<br>Content-Type: text/xml;charset=utf-8<br>Content-Length: 1237<br>Date: Thu, 10 Apr 2025 17:29:03 GMT</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br></blockquote></div><div><br></div><br><div>Here's a similar test using user "test10" who doesn't exist in the LDAP:</div><div><br></div><div>/opt/shibboleth-idp/bin/aacli.sh --saml2 -n test10 -r <a href="https://saml.example.org">https://saml.example.org</a><br>(<a href="http://localhost/idp/profile/admin/resolvertest?requester=https%3A%2F%2Fsaml.example.org&principal=test10&saml2">http://localhost/idp/profile/admin/resolvertest?requester=https%3A%2F%2Fsaml.example.org&principal=test10&saml2</a>) Connection refused<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">curl -I "<a href="http://localhost:8080/idp/profile/admin/resolvertest?requester=https%3A%2F%2Fsaml.example.org&principal=test10&saml2">http://localhost:8080/idp/profile/admin/resolvertest?requester=https%3A%2F%2Fsaml.example.org&principal=test10&saml2</a>"<br>HTTP/1.1 200<br>Cache-Control: no-store<br>Set-Cookie: __Host-JSESSIONID=ABB72D99369BE72E9931E25954CE6146; Path=/; Secure; HttpOnly<br>X-Frame-Options: DENY<br>Strict-Transport-Security: max-age=31536000<br>Content-Security-Policy: frame-ancestors 'none'; base-uri 'none';<br>Content-Type: text/xml;charset=utf-8<br>Content-Length: 600<br>Date: Thu, 10 Apr 2025 17:41:19 GMT</blockquote></div><div><br></div><div>=======================================================================================</div><div>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:</div><div><br></div><div>warn.log: Attribute Resolver 'ShibbolethAttributeResolver': Data connector 'myLDAP' failed<br>net.shibboleth.idp.attribute.resolver.NoResultAnErrorResolutionException: No entries returned from search<br></div><div><br></div><div>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<br>net.shibboleth.idp.attribute.resolver.NoResultAnErrorResolutionException: No entries returned from search<br></div><div><br></div><div><br></div><div>Do the results (and the difference in the logging) help identify what the problem(s) may be?</div><div><br></div><div>Thanks again!!</div><div><br></div><div>Jim</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></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 12:57 PM 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,</div><div><br></div><div>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?</div><div><br></div><div>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).</div><div><br></div><div>Please let me know?</div><div><br></div><div>Thanks,</div><div>Jim</div></div><div id="m_-4863719520253268995DAB4FAD8-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_-4863719520253268995_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 10:01 AM o haya <<a href="mailto:ohaya1001@gmail.com" target="_blank">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_-4863719520253268995m_-5122517881634916184DAB4FAD8-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_-4863719520253268995_m_-5122517881634916184_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>
</blockquote></div>