...
Utöver denna guide finns följande dokumentation framtagen för tjänsten.
| Sidträd | ||||
|---|---|---|---|---|
|
| Sidträd | ||
|---|---|---|
|
...
För slutanvändaren kan valet av autentiseringsmetod påverka det senare uppdragsvalet senare användarval av tjänste-id/organisation/medarbetaruppdrag om ett sådant krävs.
- SITHS-kort på denna enhet kommer alltid föredra HSA-id-certifikat
- SITHS eID på denna/annan enhet föredrar ett personnummer-certifikat om ett sådant finns. Beroende på vilka uppdrag som har kopplats i HSA för personnumret jämfört med vad som är kopplat till HSA-id:t kan SITHS eID på denna/annan enhet resultera i att användaren får fler valbara alternativ i tjänste-id- och uppdragsvalet.
...
| Expandera | ||
|---|---|---|
| ||
För att säkerställa att användaren måste välja ett certifikat när SITHS-kort på denna enhet används dirigerar IdP:n användaren om till olika subdomäner vid varje inloggningsförsök i den pågående webbläsarsessionen. OM användaren inte valde något certifikat, t ex. inte hade sitt SITHS-kort i kortläsaren, visas denna dialog och användaren får ett nytt försök genom att välja Försök igen.
OM användaren har kommit till maxvärdet för antalet inloggningsförsök innan webbläsaren måste startas om (i skrivande stund 25 försök för IdP som driftas av Inera) visas denna dialog och användaren måste starta om webbläsaren för att starta om antalet försök.
OBS! Logiken med att användaren alltid får 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 (se exempel nedan). Inställningen gör att räknaren i cookien för vilken endpoint/domännamn användaren ska hamna på inte nollställs korrekt. Användaren kommer såldes att fortsätta på det värde som webbläsaren senast hade och nollställas först när den når maxvärdet (25) och användaren då startar om webbläsaren. Rent praktiskt innebär det att användaren istället för 25st nya försök kommer ha färre försök på sig innan meddelandet ovan ovan om För många inloggningsförsök via dubbelriktad TLS presenteras.
|
SITHS eID på denna/annan enhet - Out-of-band authentication (OOB)
...
- PROD - https://test.idp.inera.se/
- TEST/QA - https://test.idp.ineratest.org/
...
Användarval
Under inloggningsflödet kan användaren bli presenterad med en vy där användaren behöver göra ett uppdragsval. Uppdragsvalet val av tjänste-id/organisation/medarbetaruppdrag. Valet innebär att användaren specifikt måste välja med vilket tjänste-id och hos , vilken vårdgivare/vårdenhet och/eller vilket medarbetaruppdrag användaren avser att logga in hosmed. För att slutföra inloggningen måste ett val göras, annars misslyckas inloggningen.
...
- Inloggning med SITHS eID på denna/annan enhet föredrar personnummer-certifikat om ett sådant finns
- En användares personnummer kan ha uppdrag kopplade till sig i HSA som inte också är kopplade på användarens HSA-id. Detta kan i sin tur resultera i att användaren får fler uppdragsval att välja mellan på för denna autentiseringsmetod.
- Inloggning med SITHS-kort på denna enhet alltid föredrar HSA-id-certifikat.
.När ett val behöver göras finns det ett flertal scenarion att förhålla sig till. Dessa finns specifierade här nedan.
Användaren har ett tjänste-id utan uppdrag
I detta fall kommer IdP:n automatiskt välja tjänste-id:t. I praktiken innebär det att användaren inte kommer bli presenterad med något val i webbläsaren.
Användaren har flera tjänste-id:n där inget tjänste-id har medarbetaruppdrag
I det här fallet har inget av användarens tjänste-id:n några uppdrag kopplade till sig. När detta inträffar får användaren en vy presenterad för sig där endast ett tjänste-id kan väljas.
Användaren har ett tjänste-id med ett medarbetaruppdrag
När detta fall inträffar väljer IdP:n automatiskt tjänste-id:t och det tillhörande uppdraget. I praktiken innebär det att användaren inte kommer bli presenterad med något val i webbläsaren.
Användaren har ett tjänste-id med flera medarbetaruppdrag
I det här fallet kommer användaren få välja bland alla uppdrag som finns kopplade till användarens tjänste-id. Notera i bilden nedan hur HSA-id:t i kolumnen längst ut till höger är detsamma för alla uppdrag.
Hur dessa scenarion fungerar går att läsa här: /wiki/spaces/ST/pages/4251549871
Förval av principalen
IdP stödjer förval av principalen (den inloggade användaren). Förvalet möjliggörs genom att tillåta SAML- och OIDC-anslutningar att skicka in värden som del av deras legitimerings- och signeringsbegäran. Dessa värden används sedan av IdP:n för att kunna göra ett val at av tjänste-id, organisation och/eller medarbetaruppdraget medarbetaruppdrag utan användarinteraktion om möjligt. Alternativt om inte tillräckligt precisa värden skickats in kan IdP:n visa ett urval av valmöjligheter i tjänste-id- organisations- eller medarbetaruppdragsväljaren som på förhand har filtrerats med hjälp av de inskickade värdena.
Med denna mekanism har anslutande system möjlighet att på förhand välja vilket personnummer, tjänste-id, medarbetaruppdrag eller organisationsnummer organisations-id, organisationsnummer eller medarbetaruppdrag användaren måste slutföra inloggningen med. Om något av de inskickade värden inte kan uppfyllas av användaren (antingen genom att fel kort använts eller uppgifter saknas i HSA) kommer inloggningen eller signeringen att misslyckas.
...
| Expandera | ||||||
|---|---|---|---|---|---|---|
| ||||||
|
...
| Expandera | ||||||
|---|---|---|---|---|---|---|
| ||||||
|
...