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.
Required information
Please send the following information to aai-is@lists.geant.org:
| Information | Description | Example | stored in/mapped to (internally) |
|---|---|---|---|
| Technical contact |
Can be a list | support@it.geant.org | contacts['technical'] |
| Support contact | "Generic" support questions for the actual service
Usually the application administrators or the teams that run it. Can be a list. | support@it.geant.org | contacts['support'] |
| Service name | Very short name to be shown in user interfaces. | GÉANT Wiki | name |
| Service description | Longer descriptive text, for instance with details like:
Can contain URLs | Atlassian Confluence wiki, production instance. | description |
| Service URL | The actual URL to the main service | https://wiki.geant.org | url |
| Metadata | Valid SAML2.0 metadata | a URL to the XML metadata (preferred), or an XML metadata file. |
Note that a public list of all connected services will be made publicly available. This mean that services can not be "hidden".
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. |
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.