Federated Identity Management Service  (FIMS) Setup

Any software that supports SAML2 is welcome to be used in the CAF federation but the prevalent install base is the Shibboleth software.
Additional Documentation Links:
1.   https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
2.   http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
3.   http://shibboleth.net

I am a Service Provider(SP), what should I do?

As a Service Provider, you are likely already configured to leverage FIMS which uses SAML2 as our standard protocol.  Please review the Metadata reference material below, specifically the Metadata File Handling section.

If you are a NEW Service Provider and are at the beginning of integrating your tools with our FedSSO SAML2 federation we recommend checking out link #3 above as well as collaboration.canarie.ca for the CAF integration topics.  If you would like to leverage our expertise on how to federation enable your application, please email tickets@canarie.ca to request a time to meet with our technical resources.

I am an Identity Provider(IdP), what should I do?

As an Identity Provider you may already have an IdP installed.  If so, please see the Metadata reference material below, Specifically the Metadata File Handling Section to configure the trust for our metadata aggregate.

If you are a NEW Identity Provider and need to install an IdP from scratch, we have an IdP-Installer tool that can be used to do an installation.  This tool can be found at:


This tool is designed to provide the easiest and most reliable experience installing an Identity Provider for use with CAF.  This is not the only option as you can do the installation of any SAML2 Identity Provider on your own, but this may be the easiest way.

About Communications and Support

 CAF, like other research and education federations leverages the community
support environment for non specific questions about the software and has a
formal communication path for operational aspects.

 Operational Communications

 The support team can be reached by email at: tickets@canarie.ca and is read and
responded to during normal business hours in the eastern time zone. 
Requests that are not of an operational nature may be guided to the community environment.

 Community Support Environment

 There are a variety of community forums that have broad and deep technical
knowledge about configuration and past experiences with the federated
software. If you have an application or configuration question and wish to
discuss topics more broadly we encourage searching the archives and then
posting your question if the archives do not adequately answer your question.

 The CAF Canadian participant listserv is at:
 The technical contact on the Trust Assertion Document will be added to the
list. This list is geared toward CAF participants and their topics.  Email
traffic is low compared to other lists.
 Other community support lists are the Shibboleth users and dev lists (moderate
to high daily traffic) can be found at:

Metadata Handling


CAF Shibboleth metadata is the primary 'trust anchor' for all Shibboleth
transactions. The file contains all of the essential components for
participants to conduct secure authentication and authorization transactions
in a federated access environment. There is a reliance on other forms of
trust management such as X.509 certificate path validation. Given this
critical role, there are a number of procedures that must be implemented by
participants to ensure the proper and secure usage of the metadata file. These
procedures apply to Shibboleth 2.x sites only.

Using the CAF Metadata

Metadata File Location

The CAF SAML2 metadata aggregates are located at the CAF
Core Services website:

Files are available via http or https at the above URL.  
Entities are expected to load both the CAF domestic aggregate:
and the inter-federation aggregate:

To ensure the effective utilization of security measures built into the
metadata, the following procedures must be implemented at CAF participant

Verifying Metadata File Veracity 

Verifying the metadata is a critical step in federation trust. This provides assurance to participants that the metadata file has not been altered
in an unauthorized manner. 

If you are using the IdP-Installer, this is automatically configured for you and you can skip this section.

In the Shibboleth software this is done in two steps in the relying-party.xml file.
An entry is created to reference the signing key of the federation (retrieved via the web from the CoreServices operational site:

For IdPs

Step 1: Fetch the certificate from the Core Services website

curl https://caf-shib2ops.ca/CoreServices/caf_metadata_verify.crt -o md-signer.crt

Step 2: Create a record for the CAF signing key in relying-party.xml

near the bottom of relying-party.xml is the usual location for this configuration to be added.

<security:TrustEngine id="federation-metadata-signer" xsi:type="security:StaticExplicitKeySignature">
        <security:Credential id="MyFederation1Credentials" xsi:type="security:X509Filesystem">

Step 3: Create the entry for the metadata trust in relying-party.xml

Next, add the Metadata aggregate to the configuration

<metadata:MetadataProvider id="URLMD" xsi:type="FileBackedHTTPMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata"
        <metadata:MetadataFilter xsi:type="ChainingFilter" xmlns="urn:mace:shibboleth:2.0:metadata">
             <metadata:MetadataFilter xsi:type="RequiredValidUntil" xmlns="urn:mace:shibboleth:2.0:metadata"
                maxValidityInterval="P60D" /> 
            <metadata:MetadataFilter xsi:type="SignatureValidation" xmlns="urn:mace:shibboleth:2.0:metadata"
                    requireSignedMetadata="true" />
             <metadata:MetadataFilter xsi:type="EntityRoleWhiteList" xmlns="urn:mace:shibboleth:2.0:metadata">


For SPs

Step 1: Fetch the certificate from the Core Services website

curl https://caf-shib2ops.ca/CoreServices/caf_metadata_verify.crt -o md-signer.crt

Step 2: Update the shibboleth2.xml to add a new MetadataProvider entry with this key validator

<MetadataProvider type="XML" uri="https://caf-shib2ops.ca/CoreServices/caf_metadata_signed_sha256.xml"
                backingFilePath="caf_metadata_signed.xml" reloadInterval="1800" >
        <MetadataFilter type="Signature" certificate="caf_metadata_verify.crt"/>
More Service Provider configuration details can be found here:
Guidance for configuring a CAF Service Provider

About SHA256 and SHA1 and why SHA256 is now our recommended signature format

Please see our service bulletin about this here:


which will describe all the details about why we now use SHA256.

About SSL Certificates

 X.509 certificates and RSA keys are used extensively in Shibboleth 2.x to
provide the following security functions:
  - machine authentication via TLS client authentication.
- assertion veracity.
- assertion encryption.

It is recommended that self-signed certificates be used for these functions.
The path validation employed in X.509 certificates by commercial CAs provides
a trust anchor that end users can employ to verify the authenticity of the
certificate. But this is not necessary or useful in the Shibboleth metadata
trust model that focuses on metadata. It is desirable to manage all of the
certificate and key creation internally by creating self-signed certificates.

The certificates should be bound to RSA keys that are a minimum 2048 length.
The following openssl command can be used to generate an X.509 self-signed
certificate and 2048-bit keypair with a 10 year validity.
openssl req -x509 -nodes -days 3650 -newkey rsa:2048
Reference:  https://spaces.internet2.edu/display/SHIB2/TrustManagement

About Microsoft ADFS configuration with FIMS

Microsoft ADFS version 2.0 or higher has the ability to be both an Identity Provider and a Service Provider in CAF. ADFS IdP deployments are strongly encouraged to take advantage of SILA or pysFEMMA, both of which are mentioned below to refresh and verify CAF metadata for versions of ADFS prior to version 4. Please see below for more details.

For ADFS v4 (Server 2016)

ADFS version 4 (Microsoft Server 2016) may be able to load CAF aggregate but has not been fully verified. References to aggregate loading can be found here, specifically ADFSClaimsProviderTrustGroups.

For ADFS prior to ADFS v4 (Server 2016)

CAF recommends that your infrastructure be kept current but recognizes this may take time. If you have not upgraded to ADFSv4, there are numerous third-party tools that can help.

Perhaps the most popular tool is Shibboleth IdP Loader for ADFS (SILA). The SILA tool fetches metadata and individually loads records into ADFS.  
SILA requires a local webserver to host the metadata files for ADFS, but since ADFSv3 now has a built-in webserver, you’ll need to install IIS and configure it to listen on a different port.

An additional tool that is available as opensource is FEderation Metadata Manager for ADFS (FEMMA) by Cristian Mezzetti <cristian.messetti@unibo.it>. The FEMMA tool parses a SAML <md:EntitiesDescriptor> element and creates a directory of files, each one containing a single <md:EntityDescriptor> element that AD FS can consume. A dynamically generated powershell script is used to load the individual entity descriptors into AD FS.

An extension of FEMMA called pysFEMMA is based on PySAML2, an implementation of SAML V2.0 by Roland Hedberg <roland.hedberg@umu.se>. Since pysFEMMA is SAML-aware, it has features that FEMMA does not. In particular, pysFEMMA will verify the XML signature and check the validUntil XML attribute on the metadata aggregate. It will also configure attribute release policy in an AD FS IdP based on entity attributes(link to inCommon reference) in SP metadata.

Known Limitations of ADFS and related components

ADFS has a number of limitations or differences that the Shibboleth software users take for granted:

ADFS Limitations:

(pys)FEMMA Old versions of OpenSSL are incompatible with SHA-2
If your deployment of pysFEMMA depends on an old version of the OpenSSL crypto library, it may be unable to verify the signature on CAF metadata. For instance, versions of OpenSSL prior to 0.9.8 are known to be incompatible with SHA-2 and therefore a pysFEMMA installation that depends on OpenSSL 0.9.7 (or earlier) will not be able to verify an XML signature that uses a SHA-2 digest algorithm.

Other Resources:

The ADFS Toolkit

About Cryptography and Best Practices around secure operation of your service

In 2014 a number of cryptographic vulnerabilities have come to light. Heartbleed, shell_shock, and the SSLv3 Poodle attack all had an impact of some nature to the integrity of the internet at large.

In response to these CAF provides guidance and security recommendations from time to time to the federation community and expects participants to keep their systems up to date with the latest current patches and mitigations to threats of this nature.

Please ensure that your contact information is up to date and accurate so that we may properly communicate with you regarding these risks.