Versions Compared

Version Old Version 4 New Version 5
Changes made by

Former user

Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: explained signature, verification, and usage of keytool

...

  • If the requesting provider is unauthenticated – due to a lack of SSL client authentication because the AA is not protected by an https:// URL – the default relying party is always used.
  • If the requesting provider is Shibboleth 1.1 or less, the default relying party is used.
  • If a RelyingParty element's providerId attribute matches the name sent by the SP, then that element is used.
  • A metadata lookup is performed using the metadata.xml files supplied by MetadataProvider elements to determine whether the SP is a member of a common federation. If there is a RelyingParty element that has the same providerId as the URI of the the federation, it is used. If not, the default relying party handles the request.

    <RelyingParty name="URI"
    providerId="URI"
    signingCredential="string"
    AAUrl="URL"
    defaultAuthMethod="URN"
    passThruErrors="true/false"
    providerId="string"
    signAssertions="true/false">

    In addition to its attributes, this element may contain a NameID element to specify a naming mechanism for assertions sent to this relying party.

  • name: Each RelyingParty element is differentiated by a URI specified in the name attribute. An SP will send its providerId with its requests; if the URI it provides here matches the name attribute, this element will be used in the transaction. If there is no direct match, the !IdP uses metadata to try to find a federation that the service provider is a member of.
  • providerId: If the IdP should perform transactions with this relying party using a different providerId than the default for the IdP as a whole, it may be specified individually using a providerId attribute on this element.
  • signingCredential: This attribute specifies the signing credential that will be used by the SSO handler for requests from this relying party and must match the identifier of the appropriate FileResolver ID. A separate set of credentials may be specified for the IdP's signing of assertions and SSL session identification with this relying party. An incorrect signing key will lead to trust failures.
  • AAUrl: Different AAs may be specified for different relying parties using this attribute. It over-rides, is populated, and operates in the same manner as the AAUrl attribute of the IdPConfig element.
  • defaultAuthMethod: The value of this attribute represents the mechanism by which the user's authentication was performed. It is used to populate authenticationMethod in SAML assertions passed to this relying party if no other authentication method is passed to the HS. For a brief list of authentication methods, consult the same attribute as part of the IdPConfig element.
  • passThruErrors: This boolean attribute determines whether the IdP will relay errors in flows to this SP for use in displaying these errors to the browser in the case of an unsuccessful transaction.
  • providerId: If the !IdP must assert under a different name to this relying party, specify a providerId attribute which will over-ride the one specified in IdPConfig.
  • signAssertions: If this boolean attribute has a value of true, all assertions generated for transport to this relying party will be signed. This is mostly useful for using the attribute assertion in contexts outside of the Shibboleth flows and defaults to false.

...

The Shibboleth IdP leverages metadata distributed by relying parties and federations to validate the identity of requesters and the resource providers on whose behalf the request is being made. This metadata is cached locally in the form of metadata.xml. Shibboleth includes a simple utility called metadatatool which can be used to refresh a metadata.xml file. These files are then pointed to by MetadataProvider elements in idp.xml and shibboleth.xml.

The metadatatool can verify the the metadata's signature if the signing certificate is in a Java keystore. Download the signing certificate (e.g., into inq.pem), then import it into a keystore using the Java keytool.

keytool -import -file inq.pem -keystore internet2.jks -alias sitesigner

The following command is appropriate for most deployments and is run from the $SHIB_HOME directory. This should be frequently run by adding it to a crontab to ensure that the data is fresh.

bin/metadatatool -i https://wayf.internet2.edu/InQueue/IQ-metadata.xml -k conf/internet2.jks -a sitesigner -p shib123 -a sitesigner -o /your_path_here/IQ-metadata.xml

...