Revisionshistorik
Innehållsförteckning
1. Datum i korthet
Miljö | Beräknade releasedatum |
---|---|
Systemtest CGI |
|
Acceptanstest Orange |
|
Acceptanstest Nogui |
|
QA Orange + Nogui | till |
Prod Nogui |
|
Prod Orange |
|
2. Förändringar
2.1. Viktiga ändringar
Denna funktion aktiveras först under Q3-2023
I väntan på att den aktiveras får användaren bara ett försök att välja sitt klientcertifikat per webbläsarsession. Om SITHS-kortet inte sitter i läsaren, är för fel miljö eller om importen av certifikaten till operativsystemet inte fungerar måste användaren starta om webbläsaren för att kunna göra ett nytt försök att välja klientcertifikat. Detta beror på att det är den logiken som gäller för marknadens olika webbläsare.
Sammanfattning | Beskrivning | För lokal IdP |
---|---|---|
Förändringar för autentiseringsmetoden SITHS-kort på denna enhet (Mutual TLS)
| Denna ändring påverkar endast autentiseringsmetoden SITHS-kort på denna enhet. OM webbläsaren har ett giltigt identitetsintyg uppnås som vanligt IdP SSO. Denna ändring påverkar endast beteendet när en användare måste göra en ny inloggning via IdP. OM webbläsaren inte har IdP SSO kommer hen att vid upprepade inloggningar kommer att behöva välja ett certifikat på nytt Ändringen fungerar så att IdP använder sig av flera subdomäner/endpoints som webbläsaren skickas mellan. Anledningen till att webbläsaren behöver slussas till nya domännamn är för att webbläsare "sparar" valt certifikat per domännamn. Genom att skicka webbläsaren vidare till olika domännamn kan IdP få upp användardialogen om att välja klientcertifikat för varje nytt domännamn. I praktiken innebär detta att användaren/webbläsaren, för metoden SITHS-kort på denna enhet, istället för att endast hamna på secure.idp.inera<miljö>.org/se kommer att hamna på någon av subdomänerna secure0-secure24.idp.inera<miljö>.org/se. Vilken subdomän webbläsaren hamnar på styrs av en lokalt lagrad sessions-cookie för webbläsaren. Totalt får webbläsaren 25 inloggningsförsök innan den behöver startas om. Tidigare behövde webbläsaren startas om efter 1 försök. En följdeffekt av ovan är också att användaren får möjlighet att göra nya försök till legitimering om hen glömt stoppa in ett kort. Tidigare skickades användaren tillbaka till tjänsten där hen påbörjade sin inloggning. | Instruktioner kring hur detta kan konfigureras finns i kapitel 9.4.3 i SAD IdP |
2.2. Övriga ändringar
Sammanfattning | Beskrivning | För lokal Idp |
---|---|---|
Attributet för administrativa uppdrag ska kunna hämtas även via SAML | Attributet för administrativa uppdrag (authorizationScope) kan nu hämtas via SAML. Tidigare kunde det endast hämtas via OIDC | |
Attributet at_hash levereras i scopet oidc | Attributet at_hash levereras nu som standard i scopet oidc. Tidigare var detta endast dokumenterat och ej implementerat. | |
Förbättringar i IdP Public Tools SAML-validatorn | Användare har nu möjlighet att importera SAML metadata till IdP Public Tools SAML-validatorn utöver möjligheten att kunna klistra in metadata manuellt. | |
Statistik per timme | Förvaltningen på Ineras och kunder med lokal IdP kan nu få ut statistik per timme. Statistiken innehåller information om antal in- och utloggningar per timme sammanlagt och per anslutning. Statistiken är uppdelad per protokoll och lyckade/misslyckade inloggningar. Den går också att ta ut per anslutning/klient. | Detaljerad information om detta finns under rubrik 10.3 på sidan Lokal IdP |
2.3. Visuella ändringar
2.3.1. Nya vyer för autentiseringsmetoden SITHS-kort på denna enhet
2.3.1.1. För många inloggningsförsök via dubbelriktad TLS
Från och med denna version får användaren upp till 25 försök att logga in via IdP som driftas av Inera. När dessa försök är förbrukade i den pågående webbläsarsessionen (dvs. utan att alla flikar för webbläsaren stängs webbläsaren startas på nytt) fås följande meddelande.
Logiken med att användaren alltid får upp till 25 inloggningsförsök är beroende av att användarens webbläsare INTE har inställningen för att öppna flikar från föregående session aktiverad. Mer information finns i Anslutningsguide till IdP
Innan IdP 2.4 - Endast en subdomän | IdP 2.4 eller senare - med flera subdomäner aktivt |
---|---|
2.3.1.2. Inget certifikat användes
Detta kan uppstå om användaren:
- Glömmer sätta i sitt SITHS-kort
- Det är problem att importera certifikaten från kortet till datorn med Net iD eller SITHS eID-app för Windows MD (SAC minidriver)
- Användaren har satt i ett SITHS-kort avsett för en annan miljö en den där hen loggar in
Flera endpoints inaktivt (gamla lösningen) | Flera endpoints aktivt |
---|---|
3. Påverkan på existerande funktionalitet
3.1. Nya användarattribut
- Inga nya användarattribut
3.2. Ändrade användarattribut
Namn | OIDC | SAML Friendly | SAML Name | Beskrivning | Ändring |
---|---|---|---|---|---|
authorizationScope | authorizationScope | authorizationScope | urn:authorizationScope | Möjliggör för anslutande tjänsten att få administrativa uppdrag för en person. | Attributet kan från och med denna release hämtas via SAML och inte bara via OIDC |
4. Dokumentation
4.1. Uppdaterad dokumentation
Följande dokumentation är uppdaterad:
4.2. Fullständig åtgärdslista
Åtkomst till informationen nedan kräver inloggning
4.3. 2.3 Testrapport (CGI) - IdP
Åtkomst till informationen nedan kräver inloggning
4.4. 2.3 Testrapport (NMT) - IdP
Åtkomst till informationen nedan kräver inloggning
4 Comments
Christoffer Johansson
Ehlert, Stefan
Överlag kan vi säga att jag tror vi måste vara noggrannare med att inte bara skriva VAD vi har fixat utan även VARFÖR i publika delen av Release Notes.
När det gäller:
Dessa två:
Är de primärt för Lokal IdP, Tänker så att inte kunder tror att man kan hämta det från nationella IdP?
Gäller dessa två både vid anslutning till Nationell IdP och finns validatorn med för Lokal IdP´?
Ehlert, Stefan
Christoffer Johansson
Har tagit bort dom första tre punkterna.
Dom sista två punkterna gäller mycket riktigt vid anslutning till nationella IdP:n men är tekniskt sett också tillämpbara för lokal IdP
Christoffer Johansson
Vet inte om de med statistik borde tas bort. Det beror ju lite på vad kunderna som kör lokal IdP kan tänkas vara intresserade av. Det gäller ju att man ät tydlig med hur man kan dra nytta av de ändringar vi beskriver i Release Notes.
Jag gissar att kunder kan hämta ut statistiken från sina lokala IdP:er, men då kanske man får skriva in det i punkten/rubriken att "Lokal IdP stödjer nu statistik per timme aggregerat eller per anslutning"...
Jag gör ett utkast.
Christoffer Johansson
Du kan ju kolla nu vad du tycker.Fråga Rubrik 2.1.1: Antar att det finns någon instruktion i Användarhandbok eller SAD för hur man aktiverar detta om man har lokal IdP?Fråga Rubrik 2.2.4: Är detta bara hämtningsbart via endpointen eller kan man numer även välja timmar i Admin-GUI?Jag har inte gått igenom alla Jiror för att se om det är något mer som borde lyftas fram ännu, så det kan ju komma fler frågor.Klart ✅