eduGAIN SAML Profile - Consultation
The GN4 project has been undertaking a review of the current SAML documentation used in the eduGAIN policy set and is proposing a revision of a single SAML profile to replace the existing eduGAIN Metadata Profile. It is further proposed that the eduGAIN WebSSO Profile and Attribute Profile will be removed from the eduGAIN policy set and form part of a set of best current practice documentation, which will form stage three of the policy review process
This is part of a wider review of the full eduGAIN policy set as described on the GÉANT wiki.
A consultation is now open until 1 September 2017 and will be issued to both the eduGAIN SG and the wider community. The eduGAIN SG will have final approval rights for the document. The following documents are available for this review:
- Proposed eduGAIN SAML profile
- Supporting paper on the process (also copied below). Please note this also contains a set of QUESTIONS you might wish to reflect on.
...
Reference | Comment | Commenter | Actions | |||||
e.g. line number | your comments here | your name here | please leave blank | |||||
Metadata Signing |
| Tomasz W | ||||||
Metadata Signing | Include the following:
| Tomasz W | ||||||
Terms (Entity) | Replace exchanged by published in the following sentence: "In this document, an Entity refers to an entity’s metadata that a Participant Federation has exchanged through eduGAIN." | Thomas L | ||||||
Terms (Home Organisation) | Replace: "The organisation with which the end users are affiliated." | Thomas L | ||||||
Terms (eduGAIN Policy Framework) | Typo: SAML Profil -> SAML Profile | Thomas L | ||||||
Terms (SAML V2.0) | Replace: "Security Markup Language" with "Security Assertion Markup Language" | Thomas L | ||||||
Terms (SAML Metadata) | Sort this term before SAML Metadata Producer. | Thomas L | ||||||
Terms (SAML Metadata) | This requirement should not be hidden in the Terms, but move to '3 Metadata Production": "Valid SAML Metadata MUST meet the requirements defined in the SAML Metadata Specification [SAMLMeta] including [SAMLMetaErrata]." | Thomas L | ||||||
Terms (Metadata Registration Practice Statement (MRPS)) | Drop the second sentence "Every eduGAIN Member Federation must publish an MRPS.". This requirement is alreaedy included in 2 Metadata Registration on line 60. | Thomas L | ||||||
line 65 | The reference for [REFEDS-MDRPS] is missing. | Thomas L | ||||||
line 84 | The referene for [SAMLCore] is missing. | Thomas L | ||||||
line 88 | The reference for [MDRPI] is missing. | Thomas L | ||||||
line 90 | The reference for [MDUI] is missing. | Thomas L | ||||||
line 103-104 | Drop "other values in the service's native languages for the elements where appropriate." since it is already mentioned on lines 127-128. | Thomas L | ||||||
A general remark | The current eduGAIN policy is supposed to be technology agnostic, from which it follows that the requirement for the presentation of the federation policy at the moment of joining may be fairly lax. At the moment of enabling a given profile, we should probably require additional documents like a profile-specific part of the federation policy, this should perhaps be mentioned as a required document in the SAML profile? | Tomasz W | ||||||
Metadata registration | I find this somewhat misleading. Other sections of the document refer mostly to how the federation aggregate is produced, signed etc. This section mentions the internal document of a federation which describes how the entities make their way to the federation itself. While I fully support the need to have the registration statement requirement, I would see this particular as an element of something bigger. I would suggest that this section speaks about elements that need to be registered with the OT and which are now mentioned in several places, like the signing key, the registartionAuthority value, the metadata location. This section should state that this information needs to be passed to the OT in a trust preserving way, I would not however specify what this means, this might be specified in the Operations document. | Tomasz W | ||||||
General questions | 1. The aim of this profile seems to be to improve interop among entities in different federations by means of definng common practices by fed ops and edugain ops. Interop issues can sometimes result from different filtering policies implemented by different federations when they consume edugain metadata. Examples include federation-specific standards for end point scheme (HTTP vs HTTPS) and minimum key length (1024 vs 2048+). Is this profile the right place at which to define eduGain-wide standards for such things? If so, is this the right time to consider doing so in these two instances? 2. Members of federations are advised by their federations' operators to check the signature of their federation metadata to verify its authenticity and integrity. Does eduGain do likewise in the process of aggregating member federations' metadata for redistribution? If not, should it, and if it does not but should, is this profile the right place in which to address that requirement? | Tom Barton | ||||||
Line 111 | line 111 change SHOULD to MUST | Chris Phillips | ||||||
Key rollover | Chris/CAF: No additions specific to key rollover but a request for improved operational state information on the technical.edugain.org website
This will go a long way in managing expectations of when to expect data to circulate beyond '24-48hrs'. I suggest a simple table view of flag and age difference from MDS so we may know how far we all drift from each other republishing data from the eduGAIN MDS 'creation date'. While this could exist in the 'twisty list' for each federation, one visual dashboard page of observed latency would be more helpful in this regard. | Chris Phillips | ||||||
Scopes | regex scopes should be permitted and eduGAIN should ensure scopes do not collide when accepting aggregates from Members (see longer notes) | Chris Phillips | ||||||
ECP and logout | They MAY exist and should be strongly encouraged with 'SHOULD'. 'MUST' would be very hard to do but having 'SHOULD' will keep parity to these features across multiple technologies like OIDC and moonshot. See below for more on this. | Chris Phillips | ||||||
BCP recommendations |
| Chris Phillips | ||||||
Remove requirement for md:Organization etc to have values in English. | Peter Schober | |||||||
Remove requirement for MDUI description for IdPs - there is nothing useful to add here. | Peter Schober |
...
eduGAIN SAML Profile Review - the Long Read
...
With this focus, it is important that the eduGAIN SAML profile is closely associated with the eduGAIN Operational Practice Statement and for this document to be published at the same time as the new SAML profile.
Aim One
To support aim one, the following changes have been introduced to the documentation:
...
- SAML V2.0 Enhanced Client or Proxy Profile Version 2.0: http://docs.oasis-open.org/security/saml/Post2.0/saml-ecp/v2.0/cs01/saml-ecp-v2.0-cs01.pdf.
- SAML V2.0 Asynchronous Single Logout Profile Extension Version 1.0: http://docs.oasis-open.org/security/saml/Post2.0/saml-async-slo/v1.0/cs01/saml-async-slo-v1.0-cs01.pdf.
At this stage it is not seen as necessary to include or expand on any of the requirements In the ECP and Logout profiles in the eduGAIN Poicy Framework.
Aim Three:
To support aim three, a specific Current Best Practice area will be created on the eduGAIN website. This will set out a series of best practice approaches to be agreed with the eduGAIN SG. This is likely to include:
...