Shibd process dying whenever a required attributeService endpoint for a SP is not available
Description
Environment
Attachments
- 26 Feb 2009, 11:27 AM
Activity
Scott Cantor June 23, 2009 at 12:47 PM
Closing after releases.
Scott Cantor February 27, 2009 at 1:47 PM
No, you would never have an AA element if the IdP isn't acting as one. The extensions and keys are per-role, not per-entity. The real problem is that we accidentally defined the original Scope extension at the role level, and that referencing keys across documents doesn't work well in XML Signature.
And no, you cannot have an AA role without an AttributeService, by definition.
Olivier Sal February 27, 2009 at 3:40 AMEdited
You're right I will fix our metadata right now.
If the IdP did not configure the AA endpoint should we keep an AttributeAuthorityDescriptor element for this IdP in the federation metadata? I guess the answer is yes because the Extensions and KeyDescriptor are still needed.
The other option is to only remove the AttributeService for this IdP but if I do so I get errors while signing the metadata with metadatatool (distributed with Shibboleth IdP 1.3). The error I get : "Exception in thread "main" org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was found starting with element 'NameIDFormat'. One of '{"urn:oasis:names:tc:SAML:2.0:metadata":KeyDescriptor, "urn:oasis:names:tc:SAML:2.0:metadata":Organization, "urn:oasis:names:tc:SAML:2.0:metadata":ContactPerson, "urn:oasis:names:tc:SAML:2.0:metadata":AttributeService}' is expected"
Is this problem with metadatatool or a SAML conpliance problem?
Or am I forced to define an AA for each and every IdP even if it's a dummy one?
Thanks.
Scott Cantor February 26, 2009 at 12:24 PM
Also appears as though I neglected to perform non-schema-based validation of metadata after parsing it, which I think would have caught this. But note when I change that, the metadata will start failing to load. Probably a good thing, but may catch a lot of mistakes. 
Scott Cantor February 26, 2009 at 12:20 PM
Initial fix:
http://svn.middleware.georgetown.edu/view/cpp-sp?view=rev&revision=2941
Will add more fixes to SOAP client classes to detect NULL input for location to make sure the other code paths aren't affected in the future.
We have a situation where the shibd process would die silently. It happens while receiving a SAML 1.0 authentication assertion from an IdP that does not have a know attributeService endpoint.
Attached are the SP log entries, the last log being "DEBUG Shibboleth.AttributeResolver.Query [7]: attempting SAML 1.x attribute query"
The problem happens because our federation metadata does not necessarily include an AttributeAuthorityDescriptor/AttributeService element because most IdPs are configured to do attribute push.