Versions Compared

Version Old Version 3 New Version 4
Changes made by

Rod Widdowson

Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: style

...

  • 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 AA's 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.

...

Federations are collections of IdP's and SP's IdPs and SPs that agree to exchange information according to a set of rules with a list of acceptible root certificate authorities, often utilizing a common set of attributes. Membership in a federation does not limit bi-lateral agreements with other sites inside or outside the federation, although the political and mechanical framework of the federation can make these interactions easier.

...

Most federations will distribute a metadata.xml file to facilitate trust interactions which must be pointed to by IdP.xml. This file identifies certificates and root CA's CAs that are considered authoritative for that federation, and identify service locations, contact and error handling information, URN'sURNs, and certificate naming for individual sites in that federation. In addition, there will often be a ca-bundle.crt naming signing authorities for SSL server certificates that must be referenced by a SSLCACertificateFile element in Apache's configuration for the attribute query handler, typically the port 8443 vhost.

...

<MetadataProvider type="edu.internet2.middleware.shibboleth.metadata.provider.XMLMetadataLoadWrapper" uri="pathname"/> =

This element is contained by the main IdPConfig element must appear once for each metadata file that the IdP uses to identify and authenticate relying parties. The URI attribute points to a metadata.xml XML file, generally signed and distributed by federations. This file should be regularly refreshed using metadatatool.

http://

Additionally, it is frequently necessary to define differential use of credentials or other behaviour using RelyingParty elements. The use of different name types is the most critical change, but other changes may be made. These can be used to point to all members the entire federation by using the federation's URI: for example,

...

This is a list of all the command-line parameters that may be specified:

...

when

...

signing:

Code Block
 -i <uri> -s -k <keystore> -a <alias> -p <pass> [-o <outfile>]

when

...

updating:

Code Block
-i <uri> [-k <keystore> -a <alias> OR -N ] [-o <outfile>]

...

Shibboleth 1.2 still utilizes mod_ssl for verification of certificates presented by SHAR's SHARs when processing attribute requests. This requires an updated ca-bundle.crt to ensure that all appropriate certificate authorities used by relying parties are recognized.