Denna sida beskriver best-practices kring värdet för subject-id för IdP:er inom SWAMID.

Bakgrund

Sedan SWAMID bildades 2010 2007 har eduPersonPrincipalName (eppn) rekommenderats som attribut för att förmedla användarnamn från identitetsutfärdare (IdP) till tjänster (SP). En majoritet av tjänsterna i SWAMID använder eppn som identifierare av användare. SWAMID kräver i sina tillitsprofiler och i teknologiprofilen för SAML att eppn är globalt unik och aldrig återanvänds till en annan individ:

SWAMID Identity Assurance profiles:

5.2.3 Each Subject MUST be represented by one or more globally unique identifiers.

Subject identifiers MUST NOT be re-assigned.

SWAMID SAML WebSSO Technology Profile:

5.5.3 An Identity Provider MUST support release of the attribute eduPersonPrincipalName. The value of the attribute for a Subject MUST NOT be reassigned to another Subject.

Guidance: The e-mail address of a Subject is not suitable as value for the attribute eduPersonPrincipalName due to name changes and later reassignments to other Subjects.

Ett problem med eppn är att andra vissa federationer inom eduGAIN tillåter att attributet återanvänds till andra individer. Det gör att attributet fungerar sämre som identifierare utanför SWAMIDinternationellt.

För att hantera detta har en ny identifierare arbetats fram, subject-id.

subject-id har samma egenskaper som eppn har i SWAMID:

• Den har Har ett scope (ex. @org.se)
• Den får Får aldrig kopplas till en annan individ (någonsin)
• Den liknar Liknar en e-postadress (men bör ska inte vara en e-postadress)
• Ska behandlas case-insensitive, dvs AnvandarNamn@ORG.SE ska räknas som samma värde som anvandarnamn@org.se

Kravet för subject-id finns definierat i Från SWAMID SAML WebSSO Technology Profile::

5.5.4 An Identity Provider MUST support the release of the attribute subject-id. The value of the attribute for a Subject MUST NOT be reassigned to another Subject.

Guidance: The subject-id is a globally unique identifier identical for all Relying Parties for a given Subject. SWAMID recommends that the value of eduPersonPrincipalName is used for subject-id since it is already defined for all Subjects, widely used as identifier in Relying Parties in SWAMID, unique and non-reassigned for all Identity Providers in SWAMID. The subject-id should not be changed as a result of a change to any other data associated with the Subject (e.g., name, email address, organisational role).

Det finns dock ytterligare en skillnad mellan eppn och subject-id, dess tillåtna tecken:

• eppn: A-Z, a-z, 0-9, punkt bindestreck (.-), bindestreck understreck (-_), underscore punkt (_.)
• subject-id: A-Z, a-z, 0-9, bindestreck (-), likhetstecken (=)

Diskussion

Det finns främst två uppenbara lösningar på detta:

• Alternativ 1: Översätt eppn till subject-id på ett deterministiskt bestämt sätt
• Alternativ 2: Hitta på ett nytt värde till subject-id

Båda alternativen har för- och nackdelar.

Alternativ 1.1 - översätt eppn till subject-id med asciikoder

• Använd eppn som bas för värde på subject-id
  • Ersätt understreck punkt (_.) med =5F2E
  • Ersätt punkt understreck (._) med =2E5F
  • Exempel:
    • anna_b@org.se → ranna%5Fb@organna=5Fb@org.se
    • fornamn.efternamn1-_efternamn2@org.se → fornamn=2Eefternamn1=5Fefternamn2@org.se
• Säkerställ att eppn (och subject-id) aldrig återanvänds
  • Detta följer av tillitsprofilen, teknologiprofilen samt GDPR med direkt säkerhetsskäl för och säkerhetsskäl då det föreligger risk av obehörig tillgång till annans data
  • Om e-postadress används idag, se till att de aldrig återanvänds och skapa en annan identifierare än e-postadress för nya användare (utan punkt och understreck)
  • Det förekommer idag att e-postadress återanvänds, ibland efter direkt explicit rektorsbeslut

Fördelar:

• Tjänster kan ersätta eppn med subject-id utan förändring, förutom för just de användare där understreck eller punkt förekommer i eppn, och då antingen göra en översättning med =5F/=2E eller kräva nya användaridentiteter i tjänsten för endast dessa användare
• Användarnamnen är väl inarbetade och känns i de flesta fall igen av användarna

Nackdelar

• De eppn som innehåller understreck eller punkt får förvirrande nytt värde som subject-id med likhetstecken i sig
• Vissa väl Väl inarbetade användarnamn känns inte längre igen i systemet och skiljer sig från vad som används vid inloggning i IdP:erna
• Det kan uppstå viss förvirring om vilket användarnamn det är som gäller, och det skiljer sig mellan tjänster som användar eppn som identifierare och de som använder subject-id

Implementering i Shibboleth

Implementering i ADFS

Alternativ 1.2 - översätt eppn till subject-id med rensning

• Använd eppn som bas för värde på subject-id
  • Ta bort punkt (.) och understreck (_)
  • Exempel:
    • anna_b@org.se → annab@org.se
    • fornamn.efternamn1-efternamn2@org.se → fornamnefternamn1efternamn2@org.se
• Säkerställ att eppn (och subject-id) aldrig återanvänds
  • Detta följer av tillitsprofilen, teknologiprofilen samt GDPR och säkerhetsskäl då det föreligger risk av obehörig tillgång till annans data
  • Om e-postadress används idag, se till att de aldrig återanvänds och skapa en annan identifierare än e-postadress för nya användare (utan punkt och understreck)
  • Det förekommer idag att e-postadress återanvänds, ibland efter explicit rektorsbeslut

Fördelar:

• Tjänster kan ersätta eppn med subject-id utan förändring, förutom för just de användare där understreck eller punkt förekommer i eppn, och då antingen göra en översättning med borttagning av understreck och punkt eller kräva nya användaridentiteter i tjänsten för endast dessa användare
• Användarnamnen är väl inarbetade och känns i de flesta fall igen av användarna
• Användarnamnen innehåller inga oväntade teckenkombinationer

Nackdelar

• Det kan uppstå viss förvirring om vilket användarnamn det är som gäller, och det skiljer sig mellan tjänster som användar eppn som identifierare och de som använder subject-id
• Risk finns för konflikt mellan användarnamn. I Ladok finns drygt 100.000 SWAMID-eppn varav 1.500 eppn innehåller punkt eller understreck. Av dessa uppstår sju konflikter, varav fyra sannolikt är resultat av felstavning vid skapande av användaridentiteten.

Implementering i Shibboleth

Implementering i ADFS

Alternativ 2 - Hitta på nya värden för subject-id

• Välj ett nytt värde på subject-id som saknar direkt koppling till subject-ideppn
• Använd inte punkt (.) eller understreck (_) i nya subject-id-värden
• Välj något som är förhållandesvis enkelt att hantera av människor
  • Dåligt exempel: 488d2f98-b670-4c13-aedf-c5b4d0783efb@org.se
  • Bra exempel: andber01@org.se (för Anders Bertilsson, notera dock problematik kring namnbyte)
  • Bra exempel: lusab-babad@org.se (Proquints, används av eduID och Antagning.se)

Fördelar:

• Chans att börja om med unika identifierare som inte riskerar att återanvändas (till skillnad från e-postadresser som används för som eppn av många organisationer inom SWAMID idag)

Nackdelar

• Användare behöver hantera nya användarnamn (vid inloggning eller som visas i gränssnitt)
• Tjänster behöver hantera användarnamnbyte via exempelvis någon av dessa metoder:
  • Använda eppn men spara undan subject-id under en övergångsperiod för att sedan gå över till bara subject-id-värden
  • Byta alla användarnamn i systemet samtidigt
  • Skapa upp nya
användare och tappa information
• • användaridentiteter utan koppling till de gamla