At 11:00AM on Wednesday, November 28th, we will be switching our
CAF-registered Identity Provider (IdP) to
This page is entended to help you understand the issues should you experience trouble when we switch to IdPz. This page is targetted toward technical support for your service and presumes some experience with SAML/Shibboleth, federated authentication, and SAML metadata. Please note the topics list on the right side of this page.
We have been using the Shibboleth V2 IdP (https://idp.utorauth.utoronto.ca/shibboleth) as UToronto's CAF-registered IdP. Internally, UToronto switched to Shibboleth V3 with IdPz a year ago. And we are now deprecating our V2 IdP server and switching completely to Shibboleth V3.
The IdP and the SP collaborate via: (1) SAML metadata; (2) discovery service, static or ad hoc SSO configuration; and (3) naming and attributes. We expect our IdPz change to be transparent if your SP
If you use a static setting for the IdP, then your SP will continue to use idp.utorauth. It should continue function with no changes. But we have deprecated idp.utorauth and we will soon need you to switch to IdPz, ... though not immediately.
Already, our two IdPs (IdP.utorauth... and IdPz.utorauth...)
have <entityDescriptor> elements in CAF's metadata file:
https://caf-shib2ops.ca/CoreServices/caf_metadata_signed_sha256.xmlAs of 2018-10-30, IdPz is hidden from discovery and IdP.utorauth is presented by the CAF discovery service. On 2018-11-28, the hide-from-discover will switch so that IdP.utorauth is hidden and IdPz.utorauth is presented in discovery.
The <mdui:*> elements also reflect the current state. IdPz is currently labelled as a test. As we switch, we will also update these elements.
CAF also shares metadata through an eduGAIN export that feeds to inter-federation metadata files.
We believe the Discovery Service (DS) (formerly call WAYF) to be a transparent change, barring issues with Naming and Attributes (see below). If you use CAF's Discovery Service or a Discovery Service that feeds from CAF's metadata, then your SP will redirect to the DS which will
If you use a static setting for the IdP, then your SP will continue to use idp.utorauth. It should continue function with no changes. But we have deprecated idp.utorauth and we will need you to switch to IdPz.
The attributes produced be IdPz.utorauth should match the assertions produced by IdP.utorauth. Attributes like affiliation, common name, or mail are come from the same sources and are presented with the same XML tags. But the attribute-filter files are separate and it is possible that something does not match, so please report any issues.
We are concerned about NameID and opaque naming attributes. Opaque persistent identifiers are a function:
f(IdP entityID, SP entityID, user's persistent ID)so, when IdP changes, the entityID changes, and the opaque identifiers will also change.
If you use opaque persistent identifiers, please let us know.
Send mail to
Please include your web site's hostname in the subject of your mail.
The IdP entityID="https://idp.utorauth.utoronto.ca/shibboleth" is not being changed. We are only changing which of our two IdPs is presented by a dynamic SAML Discovery Service (DS).
If your SP has a static Single Sign-on configuration that is configured to use "idp.utorauth.utoronto.ca", then this change will not affect you.
There are two important changes that can affect your service: (1) SAML Discovery Service and (2) opaque persistent identifiers.
If you use a Discovery Service, your UToronto users should see much the same interface. The DS is currently presenting "University of Toronto" and, if selected, the user will be directed to idp.utorauth.utoronto.ca to authenticate. After the change, the user will still see "University of Toronto", but when the user selects UToronto, the browser will be redirected to idpz.utorauth.utoronto.ca. But the login should be the same, ... unless your SP relies on opaque persistent identifiers.
SAML Assertions will have persistent identifiers that would be used for keeping a profile or history of the user. An opaque persistent identifier would be used for privacy. The identifier is typically a hash of the user's name, the user's IdP entityID, and the SP's entityID. As long as the user uses that same IdP and username, the identifier will not change from login to login. It is persistent. However, if your user's IdP changes the opaque identifier may change. If your service relies on such opaque identifiers, your users will have start a new history and will need a new profile or preferences.
If your SP relies on these opaque identifiers, please contact us as firstname.lastname@example.org
Example of opaque persistent IDs include:
This opaque identified is a hash that depends on the IdP's entityID. It will change when the IdP changes. If you rely on eduPersonTargetedID, your SP will be affected by this change.
If the SAML NameID is opaque, it also going to change when the IdP changes. Your SP will be affected.
If a SAML Service Provider (SP) wants to serve users at more than one institution, it must recognize multiple Identity Providers (IdPs). The service can (a) use an external Discovery Service or (b) provide its own IdP selection interface. If your SP only serves one institution, it will have static configuration. That static configuration may be get our UToronto IdP info from a metadata file or it may have an ad hoc configuration.
One way to serve multiple institutions is to use a Discovery Service. This was once known as WAYF (Where are you from?).
The Shibboleth Service Provider configures is Single Sign-on with /etc/shibboleth/shibboleth2.xml. It can have a single IdP:
<SSO entityID="https://idp.utorauth.utoronto.ca/shibboleth" ... >or it may use a Discovery Service (DS). For example,
<SSO discoveryProtocol="SAMLDS" discoveryURL="https://caf-shib2ops.ca/DS/CAF.ds">delegates the selection of an IdP to the Canadian Access Federation's Discovery Service (CAF's DS).
But a service provider will likely use a discovery service within its own federation, which is typically determined by geographical or political borders. So, if you use a SAML DS, it may well not be CAF's. But the University of Toronto provides its IdP info to CAF and CAF shares that info internationally. If your DS presents "University of Toronto" as a choice, then the IdP should switch transparently to IdPz.utorauth.utoronto.ca.
Each IdP (and SP) is an Entity which will be found a SAML (XML) Metadata file. Each Entity has an EntityDescriptor each may have one or more <saml:attribute> elements. One possible attribute is hide-from-discovery:
<saml:Attribute Name="http://macedir.org/entity-category-support" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml:AttributeValue>http://refeds.org/category/hide-from-discovery </saml:AttributeValue> </saml:Attribute>if an Entity is tagged with hide-from-discovery it should not be presented by any Discovery Service ... that respects the tag.
UToronto is using this feature in the migration. As of November 2nd, IdPz.utorauth is present in the metadata, but tagged hide-from-discovery, so no one should see it on a Discovery Service. They should only see one "University of Toronto" available for SAML sign-on.
On November 14th, we will expose IdPz.utorauth and hide IdP.utorauth. So, again, only one IdP will be presented by discovery.
But both IdP.utorauth and IdPz.utorauth are present in the metadata and both will be present after November 14th. So both work now and will continue to work after the 14th. But we will be tracking activity and contacting SPs that do not switch to using IdPz.utorauth. We expect these SPs are not using any Discovery Service.