Versions Compared

Old Version 41

changes.mady.by.user Fredrik Domeij

Saved on

compared with

New Version Current

changes.mady.by.user Fredrik Domeij

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

English (US)

SWAMID and all other academic identity federations within eduGAIN introduce a new long-term unique identifier, subject-id, which is planned to eventually replace eduPersonPrincipalName (ePPN). This wiki page describes both why a new long-term unique identifier is needed and how we transition in an orderly manner.

Table of Contents

Background

Since SWAMID was formed in 2007, the eduPersonPrincipalName (ePPN) has been recommended as the user name  of users released from identity providers (IdPs) to services (SPs). A majority of the services in SWAMID use ePPN as the identifier of users. To ensure that the organisation complies with Swedish legislation regarding access and handling of personal data and sensitive data, e.g. The Data Protection Regulation, SWAMID requires in its Identity Assurance Profiles and in the SAML WebSSO Technology Profile that the ePPN is globally unique and never reused to another individual:

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.

One problem with ePPN is that some identity federations within eduGAIN allow the attribute to be reused for other individuals. This makes the attribute inappropriate as an identifier internationally. When an individual leaves an organisation, it is highly likely that the individual's authorisations remain in federated services, linked to the individual's user name (ePPN). If a new individual at the same organisation receives the same username, the new individual will automatically have the same permissions and access to the same data as the previous holder of the username. For this reason, it is an absolute requirement that usernames are not reused for other individuals.

To handle this, a new identifier, subject-id, has been developed, defined as the General Purpose Subject Identifier (section 3.3) in the SAML V2.0 Subject Identifier Attributes Profile Version 1.0.

From the 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).

Differences between ePPN and subject-id

subject-id has the same properties as ePPN has in SWAMID:

  • Includes a scope (ex. @ org.se )
  • May never be assigned to another individual (ever)
  • Similar to an email address (but should not be an email address)
  • Should be treated case-insensitively, i.e AnvandarNamn@ORG.SE shall be counted as the same value as anvandarnamn@org.se

However, there is an important difference between ePPN and subject-id; its allowed characters:

  • ePPN: A-Z, a-z, 0-9, hyphen ( -), undescore ( _), period ( .)
  • subject-id: A-Z, a-z, 0-9, hyphen ( -), equal sign ( =)

Other things to consider

  • It is advisable that the same case is used for ePPN and subject-id to minimise the risk of mismatch in services.

Plan and implement the switch in an identity issuer (IdP)

There are a couple of obvious solutions to this:

  • Option 1 - Use ePPN as subject-id (if all requirements are met)
  • Option 2 - Change the value of the ePPN (if reuse requirements are not met)
  • Option 3 - Translate ePPN to subject-id in a specific way (if ePPN is never reused and period or underscore appears in ePPN)
  • Option 4 - Keep value of ePPN, choose a new value for subject-id

The alternatives have both advantages and disadvantages.

Option 1 - Use ePPN as subject-id if all requirements are met

If ePPNs are chosen in a way that ensures they are never reused for another individual and underscore ( _) or point period ( .) does not occur, it is fine valid to use the same value for subject-id.

Advantages:

  • Services can replace ePPN with subject-id without change
  • Usernames are well established and recognized recognised by users

Disadvantages

  • NoNone
Alternativ

Option 2 -

Byt värde på ePPN (om krav på återanvändning ej uppfylls)

Change the value of the ePPN (if reuse requirements are not met)

For organisations that currently use the user's e-mail address, or something based on the e-mail address, for ePPN, it may be appropriate to take the opportunity to choose a new value for ePPN which is then also used for subject-id.

  • Choose a new subject-id value that does not risk being reused (and has not been used as an ePPN by another individual before)
  • Do not use period ( .) or underscore ( _) in new ePPN values

För organisationer som idag använder användarens e-postadress, eller något som baseras på e-postadressen, för ePPN kan det vara lämpligt att passa på att välja ett nytt värde för ePPN som sedan används även för subject-id.

  • Välj ett nytt värde på subject-id som inte riskerar att återanvändas (och inte använts som ePPN av någon annan individ tidigare)
  • Använd inte punkt (.) eller understreck (_) i nya ePPN-värden
  • Choose something that is relatively easy for people to handle
    • Dåligt exempelBad example: 488d2f98-b670-4c13-aedf-c5b4d0783efb@org.se - svårt att hantera vid difficult to handle in administration
    • Good examples: andber01@org.se - för for Anders Bertilsson, enkelt att hantera och komma ihåg för användare, notera dock problematik kring namnbyte, easy to handle and remember for users, note, however, problems around name changes
    • Good examples: lusab-babad@org.se - translation of unique 32-bit integer via Proquints (interesting reasoning about identifiers on the link!), used by eduID and Antagning.se
  • Use the same value for subject-id as for new ePPN value

Advantages:

  • Chance to start over with unique identifiers that are not at risk of reuse (unlike email addresses used as ePPNs by some organizations organisations within SWAMID today)

Disadvantages

  • Users need to manage new usernames (at login or as displayed used in user interface)
  • Services need to handle user name changes via, for example, one of these methods:
    • Using ePPN but saving received subject-id for a transition period and then switching to only subject-id values
    • Change all usernames in the service at the same time
    • Create new user identities without connection to the old ones

Option 3.1 - Translate ePPN to subject-id by removing unwanted characters

If ePPNs are chosen in a way that ensures they are never reused for another individual but the underscore ( _) or point period ( .) occurs, it is possible to remove unwanted characters from the ePPN to form subject-id.

  • Use the ePPN as the basis for the value of subject-id
    • Delete point period ( .) and underscores ( _)
    • Example:
      • anna_b@org.se → annab@org.se
      • fornamn.efternamn1-efternamn2@org.se → fornamnefternamn1efternamn2@org.se
  • Ensure that the ePPN (and subject-id) is never reused
    • This follows from the trust profileidentity assurance profiles, the technology profile as well as GDPR and security reasons as there is a risk of unauthorized unauthorised access to someone else's data
    • If email address is used today, make sure they are never reused and create an identifier other than email address for new users (without period and underscore), see Option 4 below
    • It occurs today that e-mail addresses are reused, sometimes after an explicit decision by the rectorboard

Advantages:

  • Services can replace the ePPN with subject-id without change, except for those users where an underscore or period appears in the ePPN, and then either do a translation with the removal of the underscore and period or require new user identities in the service only for these users
  • The usernames are well established and in most cases are recognized recognised by the users
  • The usernames do not contain any unexpected character combinations

Disadvantages

  • There can be some confusion as to which username applies, and it differs between services that use ePPN as an identifier and those that use subject-id
  • There is a risk of conflict between usernames. In Ladok, there are roughly 100,000 SWAMID ePPNs, of which just under 1,000 ePPNs contain periods or underscores. Of these, seven conflicts arise, of which four are likely the result of misspellings when creating user identities in Ladok that are therefore not used.

Implementation in Shibboleth

Replacement of period and underscore in Shibboleth Identity Provider is described in Example of a standard attribute resolver for Shibboleth IdP v5 and above . With minor adjustments, signs characters can be removed instead. Before that, it needs to be ensured that two individuals cannot get the same subject-id.

Implementering i ADFS

Implementation in ADFS

Support for changing value from ePPN to subject-id is available in Stöd för ändring av värde från ePPN till subject-id finns i version 2.3 av of ADFSToolkit.

Alternativ

Option 3.2 -

Översätt

Translate ePPN

till

to subject-id

med ersättningstecken

with replacement characters

If ePPNs are chosen in a way that ensures they are never reused for another individual but the underscore ( _) or periods ( .) occurs, it is possible to replace unwanted characters in the ePPN to form Om ePPN är valt på ett sätt som säkerställer att de aldrig återanvänds för annan individ men understreck (_) eller punkt (.) förekommer går det att ersätta oönskade tecken i ePPN för att bilda subject-id.

  • Använd ePPN som bas för värde på Use the ePPN as the basis for the value of subject-id
    • Ersätt punkt Replace period ( .) med with =2E
    • Ersätt understreck Replace underscores ( _) med with =5FAlternativt
    • byta punkter och understreck med bindestreck Alternatively, replace periods and underscores with hyphens ( -) om det ej föreligger risk för konflikterif there is no risk of conflicts
    • ExampleExempel:
      • anna_b@org.se → anna=5Fb@org5Fb@org.se
      • Alternativt Alternatively anna_b@org.se → anna-b@org.se
      • fornamn.efternamn1_efternamn2@org.se → fornamn=2Eefternamn1=5Fefternamn2@org5Fefternamn2@org.se
      • Alternativt Alternatively fornamn.efternamn1_efternamn2@org.se → fornamn-efternamn1-efternamn2@org.se
  • Ensure that the ePPN (and subject-id) is never reused
    • This follows from the trust profileidentity assurance profiles, the technology profile as well as GDPR and security reasons as there is a risk of unauthorized unauthorised access to someone else's data
    • If email address is used today, make sure they are never reused and create an identifier other than email address for new users (without period and underscore), see Option 4 below
    • It occurs today that e-mail addresses are reused, sometimes after an explicit decision by the rectorboard

Advantages:

  • Services can replace the ePPN with subject-id without change, except for those users where underscores or periods appear in the ePPN, and then either make a translation with =5F/ =2E/ - or require new user identities in the Service for only those users
  • The usernames are well established and in most cases are recognized recognised by the users

Disadvantages

  • The ePPNs that contain underscores or periods are given a confusing new value as subject-id with an equal sign in it
  • Some well-established usernames are no longer recognized recognised in the system and differ from what is used at login
  • There can be some confusion as to which username applies, and it differs between services that use ePPN as an identifier and those that use subject-id

Implementation in Shibboleth

Replacement of period and underscore in Shibboleth Identity Provider is described in Example of a standard attribute resolver for Shibboleth IdP v5 and above .

Implementation in ADFS

Support for changing value from ePPN to subject-id is available in version 2.3 of ADFSToolkit.

Option 4 - Choose new values

​​for

for subject-id

If ePPNs are chosen in a way that ensures they are never reused for another individual but the underscore ( _) or point period ( .) occurs, there is a chance to choose new values ​​for for these or all users to form the subject-id.

  • Choose a new subject-id value that has no direct connection to the ePPN (and has not been used as an ePPN by any other individual before)
  • Do not use dot period ( .) or underscore ( _) in new subject-id values
  • Choose something that is relatively easy for people to handle
    • Bad example: 488d2f98-b670-4c13-aedf-c5b4d0783efb@org.se - difficult to handle in administration
    • Good examples: andber01@org.se - for Anders Bertilsson, easy to handle and remember for users, note, however, problems around name changes
    • Good examples: lusab-babad@org.se - translation of unique 32-bit integer via Proquints (interesting reasoning about identifiers on the link!), used by eduID and Antagning.se

FördelarAdvantages:

  • Chance to start over with unique identifiers that are not at risk of reuse (unlike email addresses used as ePPNs by many organizations organisations within SWAMID today)

Disadvantages

  • Users need to manage new usernames (at login or as displayed used in user interface)
  • Services need to handle user name changes via, for example, one of these methods:
    • Using ePPN but saving received subject-id for a transition period and then switching to only subject-id values
    • Change all usernames in the service at the same time
    • Create new user identities without connection to the old ones

Plan and implement the change in a service (SP)

Remember to always compare the user identifiers ePPN and subject-id case-insensitive, i.e AnvandarNamn@ORG.SE shall be counted as the same value as anvandarnamn@org.se.

Proposed process for switching from ePPN as user identifier to subject-id

Services with few users or without the possibility of automating the change of user name

  1. Collect new usernames for users (subject-id)
    1. Change manually in the system
    2. Change to subject-id as identifier

Services with many users and the possibility to automate changing usernames

  1. Inventory Determine which users use the service as well as values ​​for for ePPN and subject-id for these.
    1. Mark the service with the entity category REFEDS Personalized Access to receive subject-id from IdPs
  2. Compare ePPN with subject-id
    1. If they are the same for all users
      1. Change to subject-id as identifier
    2. If they differ in a deterministic way (if, for example, all periods and underscores are removed)
      1. Develop rules in the translation service
      2. Update the user database to the subject-id values
      3. Change to subject-id as identifier
    3. If they differ in a non-deterministic way (for example, if many users have completely different values ​​of of subject-id than ePPN)
      1. Save subject-id for users during a transition period (for example via using an extra column in the user table in the database or logging)
      2. Inform users via a secure channel that they need to log in by a certain date to maintain access to the system
      3. Change to subject-id as identifier

...

Swedish

SWAMID och alla andra akademiska identitetsfederationer inom eduGAIN inför en ny långsiktigt unik identifierare, subject-id, som på sikt ersätter eduPersonPrincipalName (ePPN). Denna wikisida beskriver både varför en ny långsiktigt unik identifierare behövs och hur vi under ordnade former byter.

Table of Contents

Bakgrund

Sedan SWAMID bildades 2007 har eduPersonPrincipalName (ePPN) rekommenderats som identifierande 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. För att säkerställa att organisationen följer svensk lagstiftning avseende åtkomst och hantering av personuppgifter samt känsliga uppgifter, t.ex. Dataskyddsförordningen, kräver SWAMID 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 vissa identitetsfederationer inom eduGAIN tillåter att attributet återanvänds till andra individer. Det gör att attributet fungerar sämre som identifierare internationellt. När en individ slutar vid en organisation så är det högst sannolikt att individens behörigheter finns kvar i federerade tjänster, kopplade till individens användarnamn (ePPN). Om då en ny individ vid samma organisation får samma användarnamn kommer den nya individen med automatik ha samma behörigheter och tillgång till samma data som den föregående innehavaren av användarnamnet. Av denna anledning är det ett absolut krav att användarnamn ej återanvänds till andra individer.

För att hantera detta har en ny identifierare,subject-id, arbetats fram, definerad som General Purpose Subject Identifier (avsnitt 3.3) i SAML V2.0 Subject Identifier Attributes Profile Version 1.0.

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).

Skillnader mellan ePPN och subject-id

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

  • Har ett scope (ex. @org.se)
  • Får aldrig kopplas till en annan individ (någonsin)
  • Liknar en e-postadress (men 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

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

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

Övrigt att ta hänsyn till

  • Det är lämpligt att samma case används för ePPN och subject-id för att minimera risken för mismatch i tjänster.

Planera och genomföra bytet i en identitetsutfärdare (IdP)

Det finns ett par uppenbara lösningar på detta:

  • Alternativ 1 - Använd ePPN som subject-id (om alla krav uppfylls)
  • Alternativ 2 - Byt värde på ePPN (om krav på återanvändning ej uppfylls)
  • Alternativ 3 - Översätt ePPN till subject-id på ett bestämt sätt (om ePPN aldrig återanvänds och punkt eller understreck förekommer i ePPN)
  • Alternativ 4 - Behåll värde på ePPN, välj ett nytt värde till subject-id

Alternativen har både för- och nackdelar.

Alternativ 1 - Använd ePPN som subject-id om alla krav uppfylls

Om ePPN är valt på ett sätt som säkerställer att de aldrig återanvänds för annan individ och understreck (_) eller punkt (.) inte förekommer går det bra att använda samma värde för subject-id.

Fördelar:

  • Tjänster kan ersätta ePPN med subject-id utan förändring
  • Användarnamnen är väl inarbetade och känns igen av användarna

Nackdelar

  • Inga

Alternativ 2 - Byt värde på ePPN (om krav på återanvändning ej uppfylls)

För organisationer som idag använder användarens e-postadress, eller något som baseras på e-postadressen, för ePPN kan det vara lämpligt att passa på att välja ett nytt värde för ePPN som sedan används även för subject-id.

  • Välj ett nytt värde på subject-id som inte riskerar att återanvändas (och inte använts som ePPN av någon annan individ tidigare)
  • Använd inte punkt (.) eller understreck (_) i nya ePPN-värden
  • Välj något som är förhållandevis enkelt att hantera för människor
  • Använd samma värde för subject-id som för nytt ePPN-värde

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 som ePPN av några 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 mottaget subject-id under en övergångsperiod för att sedan gå över till bara subject-id-värden
    • Byta alla användarnamn i tjänsten samtidigt
    • Skapa upp nya användaridentiteter utan koppling till de gamla

Alternativ 3.1 - Översätt ePPN till subject-id genom att ta bort oönskade tecken

Om ePPN är valt på ett sätt som säkerställer att de aldrig återanvänds för annan individ men understreck (_) eller punkt (.) förekommer går det att ta bort oönskade tecken från ePPN för att bilda subject-id.

  • Använd ePPN som bas för värde på subject-id
  • 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), se Alternativ 4 nedan
    • 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 endast för 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änder 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 knappt 1 000 ePPN innehåller punkt eller understreck. Av dessa uppstår sju konflikter, varav fyra sannolikt är resultat av felstavning vid skapande av användaridentiteter i Ladok som därför inte används.

Implementering i Shibboleth

Ersättning av punkt och understreck i Shibboleth Identity Provider finns beskrivet i Example of a standard attribute resolver for Shibboleth IdP v5 and above. Med mindre justeringar kan i stället tecken plockas bort. Innan dess behöver det säkerställas att två individer inte kan få samma subject-id.

Implementering i ADFS

Stöd för ändring av värde från ePPN till subject-id finns i version 2.3 av ADFSToolkit.

Alternativ 3.2 - Översätt ePPN till subject-id med ersättningstecken

Om ePPN är valt på ett sätt som säkerställer att de aldrig återanvänds för annan individ men understreck (_) eller punkt (.) förekommer går det att ersätta oönskade tecken i ePPN för att bilda subject-id.

  • Använd ePPN som bas för värde på subject-id
  • 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), se Alternativ 4 nedan
    • 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 =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 inarbetade användarnamn känns inte längre igen i systemet och skiljer sig från vad som används vid inloggning
  • Det kan uppstå viss förvirring om vilket användarnamn det är som gäller, och det skiljer sig mellan tjänster som använder ePPN som identifierare och de som använder subject-id

Implementering i Shibboleth

Ersättning av punkt och understreck i Shibboleth Identity Provider finns beskrivet i Example of a standard attribute resolver for Shibboleth IdP v5 and above.

Implementering i ADFS

Stöd för ändring av värde från ePPN till subject-id finns i version 2.3 av ADFSToolkit.

Alternativ 4 - Välj nya värden för subject-id

Om ePPN är valt på ett sätt som säkerställer att de aldrig återanvänds för annan individ men understreck (_) eller punkt (.) förekommer finns chans att välja nya värden för dessa eller alla användare för att bilda subject-id.

  • Välj ett nytt värde på subject-id som saknar direkt koppling till ePPN (och inte använts som ePPN av någon annan individ tidigare)
  • Använd inte punkt (.) eller understreck (_) i nya subject-id-värden
  • Välj något som är förhållandevis enkelt att hantera för människor

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 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 mottaget subject-id under en övergångsperiod för att sedan gå över till bara subject-id-värden
    • Byta alla användarnamn i tjänsten samtidigt
    • Skapa upp nya användaridentiteter utan koppling till de gamla

Planera och genomföra bytet i en tjänst (SP)

Tänk på att alltid jämföra användaridentifierarna ePPN och subject-id case-insensitive, dvs AnvandarNamn@ORG.SE ska räknas som samma värde som anvandarnamn@org.se.

Förslag på process för att byta från ePPN som användaridentifierare till subject-id

Tjänster med få användare eller utan möjlighet att automatisera byte av användarnamn

  1. Samla in nya användarnamn för användare (subject-id)
    1. Ändra manuellt i systemet
    2. Byt till subject-id som identifierare

Tjänster med många användare och möjlighet att automatisera byte användarnamn

  1. Inventera vilka användare som använder tjänsten samt värden för ePPN och subject-id för dessa.
    1. Markera tjänsten med entitetskategorin REFEDS Personalized Access för att ta emot subject-id från IdP:er
  2. Jämför ePPN med subject-id
    1. Om de är lika för alla användare
      1. Byt till subject-id som identifierare
    2. Om de skiljer sig på ett deterministiskt sätt (om exempelvis alla punkter och understreck är bortplockade)
      1. Utarbeta regler i tjänsten för översättning
      2. Uppdatera användardatabasen till subject-id-värdena
      3. Byt till subject-id som identifierare
    3. Om de skiljer sig på ett icke deterministiskt sätt (om exempelvis många användare har helt andra värden på subject-id än ePPN)
      1. Spara undan subject-id för användare under en övergångsperiod (exempelvis via en extra kolumn i användartabellen i databasen eller loggning)
      2. Upplys användare via en säker kanal om att de behöver logga in senast ett visst datum för att behålla tillgång till systemet
      3. Byt till subject-id som identifierare

...