You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »


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 aai-is@lists.geant.org:


InformationDescription
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:

  • "contacts"
    • one technical contact (for dealing with authentication/security/privacy issues)
    • one support contact (for generic application support questions)
  • "name" <= a very short name to be shown in user interfaces, for instance "GÉANT Intranet"
Service description

Longer descriptive text, for instance with details like:

  • intended audience
  • its status (production, testing)
  • when it was set up
  • the software type/version it runs

Can contain URLs. Example:


GN8-5 Project management site, production instance. Set-up in 2017, and run by the X, the Elbonian NREN.

Service URLThe 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 attributeexample valueremarks
uidfederated-user-1234Unique user ID, always available.
mailuser@domainDefaults to the string 'invalid_email_needs_updating' if none was provided by the upstream IdP
displayNameRobert WagnerDefaults to the string 'first_name last_name' or similar if bit aren't provided by the upstream IdP
isMemberOf
  • GN_Services:GN Project Participants

  • GN4Phase3:WPs:WP9

  • GN4Phase1:SAs:GN4-1_SA3-T4

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.

  • No labels