Sommige applicaties kunnen niet overweg met meerdere bronnen (en daardoor verschillende formaten identifiers) voor gebruikersaccounts. Hierdoor kan bijvoorbeeld niet én het instellingsaccount én eduID gebruikt worden om in te loggen bij de applicatie.
Om toch voor deze applicaties eduID als (extra) inlogmethode te gebruiken, is er een speciale functionaliteit om een Instellings-Informatie -API aan te spreken tijdens het inlogproces. Met deze API wordt aanvullende gebruikersinformatie vanuit de instelling opgehaald, waarmee de eduID login informatie wordt aangepast.

Hieronder lees je meer over de werking, de vereisten en de aanvraagprocedure.


Uitgangspunten

  1. Technische aansluiting

    • De applicatie is via SAML of OIDC aangesloten op SURFconext.

  2. Eigendom en gebruik

    • De applicatie wordt uitsluitend door de instelling zelf aangeboden (niet aan andere instellingen).

  3. Bekendheid van gebruikers

    • Externe gebruikers zijn in de IdM-omgeving van de instelling geregistreerd met hun eduID-identifier.

  4. Provisioning

    • De applicatie ontvangt gebruikersgegevens vanuit de IdP-omgeving van de instelling

    • of maakt gebruik van Just-in-Time provisioning en gebruikt attributen om toegangsrechten toe te kennen.

  5. Identifier-beperkingen

    • De applicatie kan een gebruiker slechts herkennen aan één identifier.
      Daardoor is directe login met meerdere identifiers niet mogelijk.

Werking

  1. De gebruiker wordt voor authenticatie doorgestuurd naar SURFconext.

  2. In SURFconext kiest de gebruiker:

    • de IdP van de instelling (als er een instellingsaccount is), of

    • de eduID IdP.

  3. Bij keuze voor eduID logt de gebruiker in met zijn persoonlijke eduID.

  4. Na succesvolle login vraagt SURFconext via een API bij de instelling op welke gegevens bij dit eduID-account horen.

  5. Deze instellingsgegevens worden teruggestuurd naar de applicatie, waarbij de eduID-identifier wordt vervangen door de instellingsidentifier.

  6. De applicatie herkent de gebruiker nu alsof deze met het instellingsaccount heeft ingelogd.

Scenario’s

Authenticatie en provisioning met meerdere identifiers

Via verschillende routes wordt de eduID-identifier toegevoegd aan de studentenadministratie, als extra attribuut in de reguliere informatiestroom over studenten.
Voorbeelden:

  • bij inschrijving via Studielink, of

  • voor gaststudenten via eduxchange.

Als deze extra identifier vervolgens ook naar achterliggende applicaties wordt geprovisioned (op dezelfde manier als nu de instellingsidentifier wordt geprovisioned), kan de applicatie gekoppeld worden aan zowel de eduID- als de instellings-IdP.

De applicatie moet dan bij inloggen:

  1. eerst zoeken op de instellingsidentifier (bijv. uid of eppn),

  2. en als die niet gevonden wordt, zoeken op de eduID-identifier.

Zo kan één gebruiker in de database via meerdere identifiers worden herkend. Voor de student maakt het dan niet uit of hij met eduID of een instellingsaccount inlogt; voor de applicatie blijft hij dezelfde gebruiker.

Voor applicaties die niet op deze manier met meerdere identifiers kunnen omgaan, biedt deze Instellings Informatie API een oplossing.
Bij inloggen met eduID wordt de gebruikte identifier dan automatisch vervangen door een interne instellingsidentifier die al in de applicatie bekend is.

Just-in-time provisioning met rollen en rechten

Een ander scenario is dat de rollen en rechten van een eduID-gebruiker via de Instellings Informatie API worden geleverd. Deze worden toegevoegd aan de login met eduID,  bijvoorbeeld als eduPersonScopedAffiliation, eduPersonEntitlement of isMemberOf.

Daarbij gebruik je:

  • de persoonsgegevens zoals bekend in eduID voor de just-in-time provisioning, en

  • de rollen/rechten vanuit de instelling om autorisatie toe te voegen.

Vereisten aan de kant van de instelling

  • De instelling stelt een API beschikbaar waar SURFconext de gebruikersinformatie kan opvragen.

  • De API:

    • is beveiligd met Basic Authentication en een geldig TLS-certificaat;

    • volgt de afgesproken OpenAPI-specificatie.

Aanvraagprocedure

  • Aanvragen gebeurt per applicatie door, of met expliciete toestemming van, de SURFconext-verantwoordelijke van de instelling.
  • Aanvragen verlopen via een supportticket door een e-mail te sturen naar:
    support@surfconext.nl
  • No labels