2.5-Release notes - IdP
- Former user (Deleted)
- admin (Unlicensed)
Revisionshistorik
Innehållsförteckning
Datum i korthet
| Miljö | Beräknade releasedatum |
|---|---|
| Systemtest CGI |
|
| Acceptanstest Orange |
|
| Acceptanstest Nogui |
|
| QA Orange + Nogui | till |
| Prod Nogui |
|
| Prod Orange |
|
Förändringar
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 |
Ö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 |
Visuella ändringar
Nya vyer för autentiseringsmetoden SITHS-kort på denna enhet
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 |
|---|---|
|
|
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 |
|---|---|
|
|
Påverkan på existerande funktionalitet
Nya användarattribut
- Inga nya användarattribut
Ä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 |
Dokumentation
Uppdaterad dokumentation
Följande dokumentation är uppdaterad:
Fullständig åtgärdslista
Åtkomst till informationen nedan kräver inloggning
2.3 Testrapport (CGI) - IdP
Åtkomst till informationen nedan kräver inloggning
2.3 Testrapport (NMT) - IdP
Åtkomst till informationen nedan kräver inloggning
Lokal IdP
Lokal IdP kommer att tillgängliggöras för nerladdning, för aktuella regioner.Publik Information