SSO voor studenten en medewerkers

[JosVanderArend]

Vanuit de pilot 1 is de ervaring dat er bij het systeem met TA (Remindo) bij ontvangst van flow 2 (Zittingsplan) vaker dan verwacht dubbele accounts bij gebruikers worden gegenereerd. Remindo handelt hier veilig, is niet zeker dat het om dezelfde persoon (personId) gaat wordt een account aangemaakt. Mijn interpretatie is dat dit inherent aan testen is (acceptatie-/testomgevingen die worden teruggezet), maar dat er ook behoefte is aan eenduidigheid over welk attribuut van de persoon wordt nu eigenlijk gebruikt om te kijken of de persoon al bekend is.

Naar mijn idee, moet daarvoor in eerste instantie naar de personId worden gekeken en ik ga ervan uit dat dit ook wordt toegepast.

We zouden ook een extra kenmerk kunnen afspreken om dit kenmerk te gebruiken voor de matching als de personId verschilt. In de evaluatie van de pilot wordt het saml-attribuut genoemd. Ik denk dan aan het gebruik van de primaryCode van de persoon. In de specs staat bij primaryCode binnen het object Person: "Aanbevolen wordt hier voor studenten het studentnummer (studentNumber) en voor medewerkers het personeelsnummer (organizationId) of eventueel e-mailadres (emailAdress!) te gebruiken.".

Is dit probleem ook bij de andere pilots gesignaleerd? Zijn er aanvullende afspraken nodig om dubbele accounts zo veel mogelijk te voorkomen?

[rrutte]

Wij hebben dit issue ook gehad (en getackled) maar dan met de native Remindo api's.

In het kader van ooapi stel ik voor om personId leidend te laten zijn. Bij studenten leveren we ook al studentNumber en accountId aan. Aanlevering van een nieuw personId voor het TA is een nieuwe person, aanlevering van een bestaand personId is een update, waarbij reeds bestaande studentnummer/gebruikersnaam bij andere persons in het TA niet tot foutmeldingen zou mogen leiden.

Als een TA zo intelligent is om aanlevering vanuit meerdere bronnen te kunnen bundelen is dat aan het TA.

Ten aanzien van invilgators, assessors etc. zou ik als codeType van de primaryCode overigens niet organizationId of emailAdress verwachten, maar eerder accountId

[boerrookhuiszen]

Remindo gaat er nu vanuit dat verschillende personIds ook verschillende accounts moeten krijgen. Ik denk dat dat wel klopt, dat het logisch is dat er meerdere accounts "ontstaan" als de "personId" aangepast wordt: dat zal normaliter niet gebeuren, alleen in test situaties.

Overigens gaat de vraag hier niet enkel om welke code primair is, maar eerder om welke waarde gebruikt moet worden als SSO-attribuut. Dat is nu een mapping en over het algemeen studentNumber voor studenten en accountId voor medewerkers.

[hamrt]

We zouden SSO kunnen blijven bewerkstelligen door accountId expliciet als het attribuut op te nemen om aan te geven wat de gebruikersnaam is waarmee de gebruiker via surfconext en entree inlogt. @JosVanderArend kun jij dit nog valideren in de documentatie?

zo dus: otherCodes:[ 0:{ codeType:"accountId" code:"999999@aventus.nl" } ]

[JosVanderArend]

In de specs staat hierover bij otherCodes nu: "Gebruik in veld codeType de waarden "studentNumber", "username", "accountId", of "eckid" om aan te geven dat dit de identifier van deze persoon typeert."

Nog expliciet toevoegen dat accountId de gebruikersnaam is om te matchen of persoon al bekend is of niet?

[rrutte]

accountId uitleggen als: SurfConext (uid@schacHomeOrganization). Voor niet bekostigde instellingen username@domain

[hamrt]

toegevoegd in specs