SAML Service Providers
SAML2 Service Providers
A web-based application can enable authentication via the GRNET eID Proxy by connecting as a SAML Service Provider (SP). Users of the application will be redirected to the GRNET eID Proxy in order to authenticate, and the Proxy can authenticate them using any of the supported backend authentication mechanisms, including the eIDAS-Node Infrastructure. Once the user is authenticated, the GRNET eID Proxy will return a SAML assertion to the application containing information about the authenticated user.
Metadata registration
SAML authentication relies on the use of metadata. Both parties (the web-based application as a SP and the GRNET eID Proxy as an IdP) need to exchange metadata in order to know and trust each other. The metadata include information such as the location of the service endpoints that need to be invoked, as well as the certificates that will be used to sign SAML messages. The format of the exchanged metadata should be based on the XML-based SAML 2.0 specification. Usually, it is not required to manually create such an XML document, as this is automatically generated by all major SAML 2.0 SP software solutions (e.g., Shibboleth, SimpleSAMLphp, and mod_auth_mellon). It is important that the metadata can be retrieved over HTTPS using a browser-friendly SSL certificate, i.e. issued by a trusted certificate authority.
IdP Metadata
The IdP metadata of the GRNET eID Proxy are available on a dedicated URL for each environment listed in Table 3.
Table 3. GRNET eID Proxy IdP metadata endpoints
| Test environment |
|---|
https://eid-proxy-demo.aai-dev.grnet.gr/Saml2IDP/proxy.xml |
| Preproduction environment |
|---|
https://eid-proxy.aai-dev.grnet.gr/Saml2IDP/proxy.xml |
| Production environment |
|---|
https://eid-proxy.aai.grnet.gr/Saml2IDP/proxy.xml |
SP Metadata
Metadata provided by the SP should contain a descriptive name of the service that the SP represents in at least English.
It is recommended to also provide the name in other languages which are commonly used in the geographic scope of the deployment.
The name should be placed in the <md:ServiceName> in the <md:AttributeConsumingService> container.
It is recommended that the <md:IDPSSODescriptor> element included in the SP metadata contains both an AuthnRequestsSigned and an WantAssertionsSigned attribute set to true.
The SP metadata should also contain contact information for support and for a technical contact.
The <md:EntityDescriptor> element should contain both a <md:ContactPerson> element with a contactType of "support" and a <md:ContactPerson> element with a contactType of "technical".
The <md:ContactPerson> elements should contain at least one <md:EmailAddress>.
The support address may be used for generic support questions about the service, while the technical contact may be contacted regarding technical interoperability problems.
The technical contact must be responsible for the technical operation of the service represented by the SP.