Shibboleth Developers

[Brent Putman <>]

Hi Lukas,

Well, the explanation of the problem that you had a week or so ago 
(client cert failure on attribute query from 1.3 SP), and that Chad and 
I talked about off-list, was what you describe below:  the default "out 
of the box" 2.0 IdP config currently only supports keys embedded in 
metadata.  It does not by default support validation of TLS certs and 
signatures using the PKIX trust engine(s).  It can be configured, it's 
just not (currently) in there by default. 

However, the message you posted to the list last night is a different 
problem:

09:20:57.065 ERROR 
[edu.internet2.middleware.shibboleth.idp.profile.saml1.AttributeQueryProfileHandler:174] 
- Message did not meet security requirements
org.opensaml.xml.security.SecurityException: Unable to select security 
policy, no communication profile criteria available.

That's not the client cert auth failure you were having previously.  I 
don't know exactly what's causing that.  I saw some recent check-ins 
around that message decoder code, don't know if that fixed this bug or 
perhaps is causing it.   Maybe Chad knows.  But in any event, it seems 
to be a different issue altogether, so I just wanted to point out.

--Brent


Lukas Haemmerle wrote:
> Thanks to Chad's explanations we probably know the reason for this 
> problem.
>
> Apparently this request fails because the SP doesn't have certificates 
> embedded in the metadata but only has the CN of the certificate 
> subject included. Although the certificate was signed by one of the 
> embedded root CA certificates, the request apparently fails because 
> the current configuration expects the certificate to be embedded and 
> cannot fall back to the validation using the certificate subject.
>
> Lukas