Changes to the Requirements for SAML2 Identity Providers that are purely technical must reach rough consensus/no opposition among SAFIRE’s service advisory group. Changes to the administrative requirements are synchronised with the Metadata Registration Practice Statement. This version reached rough consensus on 30 November 2023.

The following describes the technical and administrative checks made before an identity provider is admitted into the SAFIRE federation within the SAML2 Technology Profile. It also serves as a checklist for identity provider operators for assessing their readiness to participate.

Changes to the Requirements for SAML2 Service Providers that are purely technical must reach rough consensus/no opposition at the SAFIRE Participants’ Forum. Changes to the administrative requirements are synchronised with the Metadata Registration Practice Statement. This version reached rough consensus on 31 March 2021.

The following describes the technical and administrative checks made before a service provider is admitted into the SAFIRE federation within the SAML2 Technology Profile. It also serves as a checklist for service provider operators for assessing their readiness to participate.

Changes to the Requirements for SAML2 Identity Providers that are purely technical must reach rough consensus/no opposition at the SAFIRE Participants’ Forum. Changes to the administrative requirements are synchronised with the Metadata Registration Practice Statement. This version reached rough consensus on 31 March 2021.

The following describes the technical and administrative checks made before an identity provider is admitted into the SAFIRE federation within the SAML2 Technology Profile. It also serves as a checklist for identity provider operators for assessing their readiness to participate.

Changes to the Requirements for SAML2 Identity Providers that are purely technical in nature must reach rough consenus/no opposition at the SAFIRE Participants’ Forum. Changes to the administrative requirements are synchronised with the Metadata Registration Practice Statement. This version reached rough consensus on 1 January 2019, and was subsequently amended to incorporate updates from the MRPS.

The following describes the technical and administrative checks that will be made before an identity provider is admitted into the SAFIRE federation within the SAML2 Technology Profile. It also serves as a checklist for identity provider operators for assessing their readiness to participate.

Changes to the Requirements for SAML2 Service Providers that are purely technical in nature must reach rough consenus/no opposition at the SAFIRE Participants’ Forum. Changes to the administrative requirements are synchronised with the Metadata Registration Practice Statement. This version reached rough consensus on 18 Sept 2018, and was subsequently amended to incorporate updates from the MRPS.

The following describes the technical and administrative checks that will be made before a service provider is admitted into the SAFIRE federation within the SAML2 Technology Profile. It also serves as a checklist for service provider operators for assessing their readiness to participate.

Changes to the Metadata Aggregation Practice Statement are announced to the SAFIRE Participants’ Forum.

SAFIRE generates a number of metadata aggregates for various purposes, including inter-federation and its own internal operations. This document gives a broad overview of how the aggregation process works. It is currently non-normative and will be refined over time.

Metadata aggregator

SAFIRE makes use of WAYF’s PHPH (PHederation PHeeder) metadata aggregation software. An overview of the configuration of this aggregator and the aggregates it generates is publically available at https://phph.safire.ac.za/.

Changes to the Key Management Practice Statement must reach rough consenus/no opposition at the SAFIRE Participants’ Forum. This version reached rough consensus on ….

Definitions and terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14¹.

Changes to the Metadata Registration Practice Statement that are purely technical in nature must reach rough consenus/no opposition at the SAFIRE Participants’ Forum. All other changes are approved by the SAFIRE Steering Committee. This version reached rough consensus on 1 January 2019 and was ratified by the Steering Committee on ….

Definitions and terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14¹.

Changes to the Requirements for SAML2 Identity Providers that are purely technical in nature must reach rough consenus/no opposition at the SAFIRE Participants’ Forum. Changes to the administrative requirements are synchronised with the Metadata Registration Practice Statement. This version reached rough consensus on 1 January 2019.

The following describes the technical and administrative checks that will be made before an identity provider is admitted into the SAFIRE federation within the SAML2 Technology Profile. It also serves as a checklist for identity provider operators for assessing their readiness to participate.

Changes to the Privacy Statement are approved by the SAFIRE Steering Committee. This version was ratified on 7 December 2018. It is a complete rewrite of v20161221.

The South African Identity Federation (SAFIRE) exists to simplify access to content, services and resources for the global research and education community.

The basic principle underpinning the security of SAFIRE is that the authentication of a user is carried out at his/her home institution (Identity Provider, IdP) using the institution’s specific authentication method. The authorisation required to allow access to the requested service is carried out by the service provider (SP). Thus whilst SAFIRE is operated by TENET, the service as it appears to end-users consists of many legal entities.