Configuring Shibboleth SP 2.6 to send attribute queries

[Misagh Moayyed]

Thanks. This is all immensely helpful. 

One final question on the topic: I see the SP issuing a warn statement in the logs saying "Ignoring the assertion without strongly matching NameID in Subject". I am guessing that the SP is comparing the NameID elements of the attribute query response with that of the original response? Logs don't exactly confirm this, nor do they fully explain which bit is failing to pass comparisons. (Looked up C++ code to see how the comparison is done).  

--Misagh

----- Original Message -----
From: "Cantor, Scott" <cantor.2 at osu.edu>
To: "Shib Users" <users at shibboleth.net>
Sent: Wednesday, August 23, 2017 8:55:00 AM
Subject: Re: Configuring Shibboleth SP 2.6 to send attribute queries

On 8/23/17, 11:30 AM, "users on behalf of Misagh Moayyed" <users-bounces at shibboleth.net on behalf of mmoayyed at unicon.net> wrote:

> It seems like in order for the attribute query to be sent by the SP, the SOAP client/curl must first authenticate itself to the
> The SP grabs the certificate presented by the attribute-service endpoint and compares that with what is found inside
> AttributeAuthorityDescriptor, processed, munched and all. If a match is found, it can proceed to actually send the query. Fine.
> Then, as you note on the return trip it compares the signature in the payload with essentially the same key found in
> AttributeAuthorityDescriptor, etc. 

May be a different key if there's more than one, but otherwise yes.

> Would you confirm that sequence is accurate? And if so, it goes without saying that my faulty assumption was to not equate the
> certificate presented by the endpoint with that of what's found in the metadata for the attribute query.

It doesn't *have* to be, but to avoid that you have to change settings or use port 443. By default it requires transport authentication because that's historically what's done, but it can be turned off, and there's also now more automation around that depending on the port using new settings that I made the default.

We're trying to allow a transition to port 443 and message signing, and so what 2.6 does now and what the IdP does is treat port 443 endpoints as implying that transport authentication isn't required. If you're using 8443 or something else, it's going to default to requiring TLS be authenticated and it will short-circuit the whole call if that fails.

That itself is only true because I hacked in an OpenSSL dependency very low in the stack that can intercept and block the call. Most libraries can't do it that safely, so you get into difficult problems like how to know you're ok sending PII in a query to a server that you might find out isn't trusted until you've already sent the data. So that leads to requiring encryption in the message, and that makes everything harder for everyone. There aren't a lot of good answers. "Just blindly use commercial roots" is the rest of the world's answer, but it will never be ours.

Anyway, you should probably read this:

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSigningEncryption

I think that's what you're missing. The "conditional" setting is the new one that tries to automate all this.

> Is that always the prerequisite, the two must always match and I just have it wrong in my set up? or is there a possibility where
> the cert sitting on the endpoint might be different than the signing cert? (Still fuzzy, but I am not sure the latter makes much
> sense). 

The certificate can be different, and depending on many settings, the SP (and IdP) will either care or not that it's trusted. The only absolute requirement is that by the end *one* of the layers authenticated itself. It doesn't have to be TLS but it usually is and always has been to date.

-- Scott


-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

----------

This email has been scanned for spam and viruses by Proofpoint Essentials. Visit the following link to report this email as spam:
https://us2.proofpointessentials.com/index01.php?mod_id=11&mod_option=logitem&mail_id=1503503728-k%2BFYEKchpir9&r_address=mmoayyed%40unicon.net&report=1