Recommended or "Best" Practices for Shibboleth IdP?

Mak, Steve makst at upenn.edu
Fri Oct 2 15:08:35 UTC 2020


Will,


Here's how we structure our SP metadata so we don't generally need to touch metadata-providers.xml, resolver, or filter unless people need custom work:

Sp metadata exists in a directory structure like this:

Spmd (this is a git repo)
  | eg (short for entity group)
    | default
    | internal-sp
    | bigapp1
    | bigapp2
    | none


And we use the LocalDynamic rules to point to each 'eg' subdirectory. Each of the rules has a MetadataFilter to add EntityAttributes to the file on load.

For example we add the attribute value "urn:....:default" to the LocalDynamic rule for the default eg.

Then in filter we set the default eg to receive our basic set of attributes.
Internal-sp gets a couple more.
Bigapp1 and bigapp2 gets some custom identifiers they need.
None gets no attributes, but it registered so it doesn't trigger as anonymous - we use this for apps that need only custom attributes.


We store our sp metadata files with the filename as the sha1 of the entityID, as required for the LocalDynamic rules.

So whenever a new SP is registered, we just add it (after computing the sha1, QCing the metadata file) to the correct subdirectory and that's it if they only need one of our prepackaged sets of attributes.

We don't have a single vendor that that is integrated through a remote URL metadata provider. Even if a vendor did that, I'd still just pull down the file and install it locally.

- Steve




More information about the users mailing list