1

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?

Improve this question

1 Answer 1

Reset to default
2

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
2
  • 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, 2019 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, 2019 at 14:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .