I was reading about Shibboleth's metadata -- https://wiki.shibboleth.net/confluence/display/CONCEPT/Metadata#Metadata-Use(andnon-use)ofMetadata , and how it's used to identify IDPs and service providers involved in the SAML flow. If a service provider uses Shibboleth, what information does it need to see in its metadata before it will communicate with an IDP?

Further, if the IDP uses the same version of SAML (e.g. v2.0) but doesn't implement Shibboleth, does that mean that the entities can't communicate with each other?


At a minimum. the IdP and SP need to agree on the following metadata in order to successfully communicate over SAML:

  • entityID's
  • public keys for message signing/encryption .
  • protocol endpoints

Typically there are many other elements in metadata, see for example https://en.wikipedia.org/wiki/SAML_Metadata#SAML_Metadata_Examples

  • User interface elements
  • Contact information
  • Registration information
  • Organization information
  • Entity attributes for policy configuration, IdP discovery, etc.
  • Error handling
  • Requested attributes
  • etc.

In regard to the second part of your question, the IdP and SP do not need to run the same software (Shibboleth or anything) as long as they agree on the protocol.

| improve this answer | |
  • Ah, I thought SAML only described the assertions and requests going back and forth -- I didn't realize it also described metadata stored on the local machines of the SP and IDP. Is this what the Wikipedia article refers to as the "Post V2.0" specification? – Dave May 23 '19 at 16:23
  • 1
    @Dave no, it's just a different section of the 2.0 specs listed here: saml.xml.org/saml-specifications – explunit Jun 6 '19 at 14:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.