You can register your GEANT project or related service with the GEANT SAML proxy, so that it can use the existing authentication options such as eduGAIN, social media, guest IdPs, etc.
The SAML proxy has the Research and Scholarship entity category, and as a result downstream services should not conflict with this, and use similarly compatible protocols:
For instance:
Service Providers that are operated for the purpose of supporting research and scholarship interaction, collaboration or management, at least in part.
Example Service Providers may include (but are not limited to) collaborative tools and services such as wikis, blogs, project and grant management tools that require some personal information about users to work effectively. This Entity Category should not be used for access to licensed content such as e-journals.
And:
The Service Provider is a production SAML deployment that supports SAML V2.0 HTTP-POST binding.
Please note that a list of all connected services will be made publicly available. This mean that your service can not be "hidden" or anything.
As a result, services are required to have a valid TLS configuration (including their SAML endpoints) using certificates from a trusted CA:
- For production services that are operated by GEANT this must be a TCS certificate (Digicert at the moment).
- For non-production services and services operated by 3rd parties, this can be any trusted CA, including LetsEncrypt.
Required information
Please send the following information to help@geant.org:
| Information | Description |
|---|---|
| entityID | The SAML entityID must be an HTTPS schema based. See https://github.com/REFEDS/MRPS/blob/v1/mrps.md#52-entityid-format and https://spaces.at.internet2.edu/display/InCFederation/Entity+IDs (which has recently moved to https://spaces.at.internet2.edu/display/federation/Entity+ID) |
| SAML Metadata | A URL to the XML metadata (preferred), or an XML metadata file. This file/URL should be valid SAML metadata containing at least the following elements:
|
| Service description | Longer descriptive text with at least:
|
| Service URL | The actual URL to the main service, for instance https://intranet.geant.org. |
Supplied information
The SAML proxy will always provide the following attributes to its downstream services:
FIXME: Do we send OID only? Or OID+name?
| SAML attribute | example value | remarks |
|---|---|---|
| uid | federated-user-1234 | Unique user ID, always available. |
| user@domain | Defaults to the string 'invalid_email_needs_updating' if none was provided by the upstream IdP | |
| displayName | Robert Wagner | Defaults to the string 'first_name last_name' or similar if bit aren't provided by the upstream IdP |
| isMemberOf |
| Multivalued attribute listing the CAMS group memberships. |
Our endpoint
EntityID | https://login.terena.org/wayf/saml2/idp/metadata.php |
Metadata URL | https://login.terena.org/wayf/saml2/idp/metadata.php |
| Metadata webpage, if your SP runs SimpleSAMLphp | https://login.terena.org/wayf/saml2/idp/metadata.php?output=xhtml |
Service monitoring
At some stage there will be some monitoring set-up, to help ensure the service is conforming to basic requirements. The monitored items are expected to include:
- Reachability of the Service URL
- Configuration of the web server's TLS stack, using the SSLlabs test.
- Clock skew, using HTTP Date header
Any alarms that are generated by these checks will be sent to the technical contact(s) that you configured.
2 Comments
Emma Apted
Do you know if this uses cleartext or encrypted assertions?
Dick Visser
Cleartext (but signed)