VI-SEEM Login integration guide for Service Providers

From VI-SEEM Wiki
Jump to: navigation, search


This wiki page contains information about enabling federated access to VI-SEEM services through VI-SEEM Login.

SAML Service Provider

To enable federated access to a web-based application, you need to connect to the VI-SEEM Login IdP Proxy as a SAML Service Provider (SP). Users of the application will be redirected to VI-SEEM Login where they can authenticate using any of the supported backend authentication mechanisms, such as institutional IdPs registered with eduGAIN or Social Providers. Once the user is authenticated, VI-SEEM Login will return a SAML assertion to the application containing information about the authenticated user.

Metadata exchange

SAML authentication relies on the use of metadata. Both parties (you as a SP and the VI-SEEM Login 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.

To exchange metadata, please send an e-mail to including the following information:

  1. entityID
  2. Metadata URL

The format of the exchanged metadata should be based on the XML-based SAML 2.0 specification. Usually, you will not need 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 you serve your metadata over HTTPS using a browser-friendly SSL certificate, i.e. issued by a trusted certificate authority. Depending on the software you are using, the authoritative XML metadata URL for your SP might be in the following form:

If your SP is part of a federation, then it would make sense to send us the URL to a signed federation metadata aggregate. We can then cherry pick the appropriate entityID from that.

Here is the SAML metadata of the VI-SEEM Login IdP proxy that you need to register with your SP:

  1. entityID:
  2. Metadata URL:

Attribute release

The VI-SEEM Login IdP Proxy is guaranteed to release the REFEDS R&S attribute bundle to connected Service Providers without administrative involvement, subject to user consent. The following attributes are included in the R&S attribute bundle:

  • Persistent, non-reassignable, non-targeted, opaque, globally unique VI-SEEM user ID (eduPersonUniqueId); this is always scoped
  • Email address (mail)
  • Display name (displayName) OR (givenName AND sn)
  • Affiliation at home organisation (eduPersonScopedAffiliation)

A more extensive list of all the attributes that may be made available to Service Providers is included in the following table:

Attribute friendly name Attribute OID Example value
eduPersonUniqueId urn:oid:
mail urn:oid:0.9.2342.19200300.100.1.3
displayName urn:oid:2.16.840.1.113730.3.1.241 John Doe
givenName urn:oid: John
sn urn:oid: Doe
eduPersonScopedAffiliation urn:oid:
eduPersonEntitlement urn:oid: TBD
eduPersonAssurance urn:oid: TBD


The VI-SEEM Login IdP Proxy provides information about the authenticated user that may be used by Service Providers in order to control user access to resources. Such information includes:

  1. VO membership/roles of the authenticated user (eduPersonEntitlement SAML attribute)
  2. Level of Assurance (LoA)

VO membership and role information


The eduPerson object specification defines the eduPersonEntitlement attribute In order to control access to resources. This is a multi-valued attribute, with each value formatted as a URI (either URN or URL) to indicate a set of rights to specific resources based on an agreement across the relevant communities. eduPersonEntitlement attributes are typically used to assert privileges maintained centrally or remotely rather than within local application-specific user databases.





Level of Assurance