...
Initierad inloggning (Unsolicited Response) stöds ej i eID Verify.
1.5 SLO – Single Logout
Observera att en SP som skickar SLO till IdP:n samtidigt stoppar all fortsatt federering för användaren. En SP måste vara medveten om vad avsikten vid en utloggning är. En utloggning av användaren i SP:s egna system är en sak, men att även sända en SLO kan orsaka problem om användaren har för avsikt att från en federering arbeta vidare hos annan SP.
2 Metadata
Metadata-filerna beskriver IdP-funktionen mer formellt och innehåller även certifikatet som används för att signera assertions i både test och i produktion.
Vi rekommenderar att ni i ert SP-system antingen har en tydlig rutin för att manuellt uppdatera med ny metadata från IdP:n eller att ni bygger in en automatisk hämtning av ny metadatafil. Ibland måste metadatat ändras, exempelvis när certifikatet på IdP:n går ut och måste bytas. Om någon viktig förändring kommer ske i metadatafilen går CGI ut med information till alla kunder i förväg.
Ta alltid ut metadata direkt från IdP test eller IdP produktion för att vara säker på att få senaste version. Detta görs enklast genom att ange nedanstående länkar när ni hämtar hem metadatafilen (xml).
2.1 Metadata för test - Privata legitimationer
Legitimation | Inloggningsmetod | LoA-nivå | Default Authentication Context | Metadata |
|---|---|---|---|---|
BankID | BankID annan enhet | 3 | ||
BankID | BankID samma enhet | 3 | ||
Freja | Freja+ annan enhet | 3 | ||
Freja | Freja+ samma enhet | 3 | ||
eIDAS | Foreign eID | 3 | ||
Telia | Telia | 3 | ||
Default IdP med samtliga ovanstående inloggningsmetoder, LoA och Authentication Context som är aktiva på kund/sp | ||||
2.2 Metadata för test - Tjänstelegitimationer
Legitimation | Inloggningsmetod | LoA-nivå | Authentication Context | Metadata |
|---|---|---|---|---|
Siths MTLS | - | 3 | METADATA KOMMER SNART | |
Siths | - | 3 | METADATA KOMMER SNART | |
Freja OrgID | - | 3 | ||
Default IdP med samtliga ovanstående tjänstelegitimationer, LoA och Authentication Context som är aktiva på kund/sp | ||||
2.3 Metadata för produktion - Privata legitimationer
Legitimation | Inloggningsmetod | LoA-nivå | Default Authentication Context | Metadata |
|---|---|---|---|---|
BankID | BankID annan enhet | 3 | ||
BankID | BankID samma enhet | 3 | ||
Freja | Freja+ annan enhet | 3 | ||
Freja | Freja+ samma enhet | 3 | ||
eIDAS | Foreign eID | 3 | METADATA KOMMER SNART | |
Telia | Telia | 3 | ||
Default IdP med samtliga ovanstående inloggningsmetoder, LoA och Authentication Context som är aktiva på kund/sp | ||||
2.4 Metadata för produktion - Tjänstelegitimationer
Legitimation | Inloggningsmetod | LoA-nivå | Authentication Context | Metadata |
|---|---|---|---|---|
Siths MTLS | - | 3 | ||
Siths | - | 3 | METADATA KOMMER SNART | |
Freja OrgID | - | 3 | ||
Default IdP med samtliga ovanstående tjänstelegitimationer, LoA och Authentication Context som är aktiva på kund/sp | METADATA KOMMER SNART | |||
3 SAML-attribut
Som utgångspunkt och grundkonfiguration följer vi DIGG Tekniskt Ramverk 1.1.4 ( Tekniska anslutningsregler för Sweden Connect-federationen ) samt 1.3.3 ( Tekniska anslutningsregler för Sweden Connect-federationen )
Vilket innebär att vi svarar uncertified-loa3 på LoA3. Observera att det tydligt framgår att "Det står en tredjeparts-legitimeringstjänst fritt att definiera egna identifierare" val av att så långt det går följa tekniskt ramverk görs för att upprätthålla en så god interopabilitet som möjligt.
3.1 Attributsprofiler
CGI SLO skall alltid tillämpas för att säkerställa att sessioner inte lever vidare. Av den anledningen bör alltid kunder som har flera SP där SSO nyttjas skicka SLO.
2 Metadata
Metadata-filer beskriver IdP-funktionen mer formellt och innehåller även certifikatet som används för att signera assertions i både test och i produktion.
Vi rekommenderar att ni i ert SP-system antingen har en tydlig rutin för att manuellt uppdatera med ny metadata från IdP:n eller att ni bygger in en automatisk hämtning av ny metadatafil. Ibland måste metadatat ändras, exempelvis när certifikatet på IdP:n går ut och måste bytas. Om någon viktig förändring kommer ske i metadatafilen går CGI ut med information till alla kunder i förväg.
Ta alltid ut metadata direkt från IdP test eller IdP produktion för att vara säker på att få senaste version. Detta görs enklast genom att ange nedanstående länkar när ni hämtar hem metadatafilen (xml).
Metadata för test och produktion finns här: Metadata
3 SAML-attribut
Som utgångspunkt och grundkonfiguration följer vi DIGG Tekniskt Ramverk 1.1.4 ( Tekniska anslutningsregler för Sweden Connect-federationen ) samt 1.3.3 ( Tekniska anslutningsregler för Sweden Connect-federationen )
Vilket innebär att vi svarar uncertified-loa3 på LoA3. Observera att det tydligt framgår att "Det står en tredjeparts-legitimeringstjänst fritt att definiera egna identifierare" val av att så långt det går följa tekniskt ramverk görs för att upprätthålla en så god interopabilitet som möjligt.
3.1 Attributsprofiler
CGI har tagit hänsyn till den information som finns i privata e-legitimationer med statlig legitimitet i Sverige samt även arbetet inom EU kring federeringslösningar. Nya SAML-attribut kan komma att tillkomma.
Alla attribut i SAML-biljetten kommer direkt från certifikatet, och i vissa fall är det delar av datat i certifikatet som är utmappat. Attribut från externa datakällor kan framöver också komma att läggas in som tilläggstjänst.
Beroende på e-legitimationsutfärdare kan attribut skilja. Attribut som inte kan mappas mot certifikatinformation plockas bort i svaret.
Valbara attributsprofiler
NAME | FRIENDLY NAME | DESCRIPTION | ELN-AP-Pnr-01 | ELN-AP-NaturalPerson-01 | ELN-AP-OrgPerson-01 | ELN-AP-eIDAS-NatPer-01 | DIGG-AP-HSAid-01 |
|---|---|---|---|---|---|---|---|
urn:oid:2.5.4.4 | sn | Surname | X | X | X | X | |
urn:oid:2.5.4.42 | givenName | Given Name | X | X | X | X | |
urn:oid:2.16.840.1.113730.3.1.241 | displayName | Display Name | X | X | X | X | |
urn:oid:1.2.752.29.4.13 | personalIdentity-Number | National civic registration number/code | X | ||||
urn:oid:1.3.6.1.5.5.7.9.1 | dateOfBirth | Date of birth | X | X | X | ||
urn:oid:1.3.6.1.5.5.7.9.3 | gender | Gender | X | ||||
urn:oid:1.2.752.201.3.8 | birthName | Name at the time of birth | X | ||||
urn:oid:2.5.4.6 | c | Country | X | ||||
urn:oid:1.3.6.1.5.5.7.9.2 | placeOfBirth | Place of birth | X | ||||
urn:oid:2.5.4.10 | o | Organizational name | X | ||||
urn:oid:2.5.4.97 | organizationIdentifier | Organizational identifier code | X | ||||
urn:oid:1.2.752.201.3.1 | orgAffiliation | <uid>@<orgnr> | X | ||||
urn:oid:1.2.752.201.3.2 | transactionIdentifier | Transaction identifier | X | ||||
urn:oid:1.2.752.201.3.4 | prid | Provisional identifier | X | ||||
urn:oid:1.2.752.201.3.5 | pridPersistence | Provisional identifier persistence indicator | X | ||||
urn:oid:1.2.752.201.3.7 | eidasPersonIdentifier | eIDAS uniqueness identifier for natural persons | X | ||||
urn:oid:1.2.752.201.3.9 | eidasNatural-PersonAddress | eIDAS Natural Person Address | X | ||||
urn:oid:1.2.752.29.6.2.1 | employeeHsaId | HSA-ID | X |
4 e-tjänstelegitimationer
Vi har tagit hänsyn till den information som finns i privata de e-legitimationer med statlig legitimitet i Sverige samt även arbetet inom EU kring federeringslösningar. Nya SAML-attribut kan komma att tillkomma.
Alla attribut i SAML-biljetten kommer direkt från certifikatet, och i vissa fall är det delar av datat i certifikatet som är utmappat. Attribut från externa datakällor kan framöver också komma att läggas in som tilläggstjänst.
Beroende på e-legitimationsutfärdare kan attribut skilja. Attribut som inte kan mappas mot certifikatinformation plockas bort i svaret.
Valbara attributsprofiler
...
NAME
...
FRIENDLY NAME
...
DESCRIPTION
...
ELN-AP-Pnr-01
...
ELN-AP-NaturalPerson-01
...
ELN-AP-OrgPerson-01
...
ELN-AP-eIDAS-NatPer-01
...
DIGG-AP-HSAid-01
...
urn:oid:2.5.4.4
...
sn
...
Surname
...
X
...
X
...
X
...
X
...
urn:oid:2.5.4.42
...
givenName
...
Given Name
...
X
...
X
...
X
...
X
...
urn:oid:2.16.840.1.113730.3.1.241
...
displayName
...
Display Name
...
X
...
X
...
X
...
X
...
urn:oid:1.2.752.29.4.13
...
personalIdentity-Number
...
National civic registration number/code
...
X
...
urn:oid:1.3.6.1.5.5.7.9.1
...
dateOfBirth
...
Date of birth
...
X
...
X
...
X
...
urn:oid:1.3.6.1.5.5.7.9.3
...
gender
...
Gender
...
X
...
urn:oid:1.2.752.201.3.8
...
birthName
...
Name at the time of birth
...
X
...
urn:oid:2.5.4.6
...
c
...
Country
...
X
...
urn:oid:1.3.6.1.5.5.7.9.2
...
placeOfBirth
...
Place of birth
...
X
...
urn:oid:2.5.4.10
...
o
...
Organizational name
...
X
...
urn:oid:2.5.4.97
...
organizationIdentifier
...
Organizational identifier code
...
X
...
urn:oid:1.2.752.201.3.1
...
orgAffiliation
...
<uid>@<orgnr>
...
X
...
urn:oid:1.2.752.201.3.2
...
transactionIdentifier
...
Transaction identifier
...
X
...
urn:oid:1.2.752.201.3.4
...
prid
...
Provisional identifier
...
X
...
urn:oid:1.2.752.201.3.5
...
pridPersistence
...
Provisional identifier persistence indicator
...
X
...
urn:oid:1.2.752.201.3.7
...
eidasPersonIdentifier
...
eIDAS uniqueness identifier for natural persons
...
X
...
urn:oid:1.2.752.201.3.9
...
eidasNatural-PersonAddress
...
eIDAS Natural Person Address
...
X
...
urn:oid:1.2.752.29.6.2.1
...
employeeHsaId
...
HSA-ID
...
X
3.3 e-tjänstelegitimationer
Vi har tagit hänsyn till den information som finns i de e-tjänstelegitimationer som idag har en spridning i Sverige, utgivna av SITHS och Freja OrgID.
eID-tjänsten har en IdP speciellt för e-tjänstelegitimationer, IdP företag. Se 2.2 Tjänstelegitimationer ovan.
BEHÖVS NEDAN TABELL SPECIFIKT FÖR ATT BESKRIVA ATTRIBUT FÖR TJÄNSTELEG? NEJ!
...
NAME
...
FRIENDLY NAME
...
DESCRIPTION
...
XX
...
YY
...
ZZ
...
ÅÅ
...
ÄÄ
...
ÖÖ
4 Exempelmeddelanden IdP
4.1 Authentication Request
Kort förklaring kring vad detta är behövs.
I produktion har CGI:s IdP kontroll på vilka SP som det är tillåtet att skicka svar till. Vi behöver alltså ha adressen AssertionConsumerServiceURL (ACS) som skall användas. Vi kan godkänna alla URL:er under en adress, som: https://sp.exempel.com/*
AssertionConsumerServiceURL kopplas till en SP och ett unikt ServiceID i eID-tjänsten. Om flera olika ”kunder” i samma e-tjänst använder samma AssertionConsumerServiceURL måste även saml:Issuer även användas och detta måste då vara unikt för varje SP.
Men IdP test godkänner * som Issuer/EntityID och AssertionConsumerServiceURL, så för testmiljön kan ni ange vilken adress ni vill.
| Expandera | ||
|---|---|---|
| ||
|
4.2 Authentication Response
...
| Expandera | ||
|---|---|---|
| ||
|
4.3 Logout Request
Observera att Logout Request inte per automatik fungerar hela vägen ut i IdP test. IdP:n vet inte var SLO-responsen skall skickas, men användaren blir ändå utloggad ur IdP:n. Skall hela SLO-flödet testas i IdP test måste test-SP konfigureras in speciellt i IdP test vilket normalt inte görs/ingår. I produktion konfigureras SLO normalt för varje SP.
| Expandera | ||
|---|---|---|
| ||
|
4.4 Logout Response
| Expandera | ||
|---|---|---|
| ||
|
4.5 Authentication Response – Login Fail + Avbryt/Cancel
Om användaren misslyckas med inloggningen med sin e-legitimation hos IdP visar IdP:n direkt upp felmeddelanden till användaren.
OBS om ni önskar få tillbaka responsen så meddela CGI i samband med beställning.
```xml
https://my.sp/0MzT-aPAv;USER_CANCEL ```
StatusMessage innehåller ett ReferensID följt av något av följande fel.
ALREADY_IN_PROGRESS
CANCELLED
CERTIFICATE_ERR
EXPIRED_TRANSACTION
INVALID_PARAMETERS
START_FAILED
USER_CANCEL
UNKNOWN
4.5.1 DIGG tekniskt ramverk
Ifall det finns behov av att få cancel enligt DIGG tekniska ramverk så är det möjligt, dock kräver det att kör mot specifik IDP som har den inställningen.
```xml
https://m00-mg-local.testidp.funktionstjanster.se/samlv2/idp/metadata/0/24User pressed cancel
```
5.1 Certifikat för att verifiera XML-DSig
SP måste verifiera att signaturen på IdP:ns svar är korrekt (XML-C14N). För detta behövs CGI:s publika nyckel för IdP-tjänsten. Certifikatet återfinns i metadatat.
Varför finns detta här? Passar det bättre under annat avsnitt eller i FAQ? Är det relevant på en översikt kring SAML/IdP?
6 Tydlighet att inloggning sker på annan domän
Vi rekommenderar att varje SP på sina sidor förklarar att tjänsten säker inloggning sker från CGI och att URL på inloggningssidan kommer vara på funktionstjanster.se
Detta för att vara tydlig till användaren och undvika att användaren blir osäker.
Varför finns detta här? Passar det bättre under annat avsnitt eller i FAQ? Är det relevant på en översikt kring SAML/IdP?
7 Eget domännamn
Det är möjligt att använda eget domännamn på federationen om så önskas. Då ser era användare t.ex. http://m0x-mg-local.idp.myndighet.se istället för m0x-mg-local.idp.funktionstjanster.se i adressfältet. Kunden behöver delegera en subdomän till funktionstjänsters DNS för att detta ska fungera.
Varför finns detta här? Passar det bättre under annat avsnitt eller i FAQ? Är det relevant på en översikt kring SAML/IdP?
10 Övriga funktioner
Språkstöd
Det finns möjlighet att införa kundanpassade sidor på IdP:n med språkstöd. Vilket språk som skall visas styrs av vad som anges i requesten. Alla texter som sen skall visas behöver in i en språkfil alternativ hanteras via CSS med fördel för kundanpassade sidor. Detta är lite arbete att sätta upp, men skall man ha många olika språk är det bäst att göra rätt från början. Fördelen är att alla feltexter då också kommer på rätt språk. För att välja språk i anropet kan "?lang=en" eller "?lang=sv" läggas till på AssertionConsumerServiceUrl i AuthnRequest-anropet.
Det är även möjligt att använda sig av en ”flagga” på sidan som byter språket via länk.
```html /mg-local/setlanguage?lang=en
/mg-local/setlanguage?lang=sv ```
Länkar behöver uppdateras om länkar ska presenteras/exemplifieras.
10.2 Begär en autentiseringsmetod eller LOA-klass
10.2.1 Begär LOA-klass med AuthnContextClassRef
För att begära en specifik LOA-klass skicka med klassens uri i AuthnContextClassRef. För definition av LOA-klasser se DIGGs tekniska ramverk
LOA-klasser kan endast nyttjas via IdP som stödjer tekniskt ramverk, se metadata ovan.
För mer information kontakta funktionstjanster@cgi.com
Varför finns detta här? Passar det bättre under annat avsnitt eller i FAQ? Är det relevant på en översikt kring SAML/IdP? Ska det flyttas till tidigare avsnitt?
10.2.2 Begär autentiseringsmetod med local.methodid
Använd i första hand en IdP som enbart har en autentiseringsmetod.
En SP kan i requesten till IdP:n direkt ange vilken autentiseringsmetod som skall användas. Alternativt anropa en IDP som bara har en inloggningsmetod. Nedan beskrivs hur man skickar med metod i AuthnRequest-anropet. Om man listar inloggningsmetoderna i den egna Discovery-tjänsten minimeras det GUI som IdP:n visar till användaren.
I requesten så kan vi ta mot och tolka strängen local.methodid
IdP test har följande möjliga inloggningsmetoder:
BankID(på den här enheten) local.methodid.ccp10
Mobilt BankID (på annan enhet) local.methodid.ccp11
Telia (inloggning med Net iD) local.methodid.ccp8
övriga Steria, SignGuard (dubbelriktad ssl): local.methodid.ccp2
Exempel: Inloggning med BankID i test.
```xml
| Kodblock |
|---|
<saml2:AuthnContextClassRef xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">urn:local.methodid.ccp10</saml2:AuthnContextClassRef>
|
```
IdP produktion har följande möjliga inloggningsmetoder:
BankID(på den här enheten): local.methodid.ccp10
Mobilt BankID(på annan enhet): local.methodid.ccp11
Telia e-legitimation: local.methodid.ccp8
Övriga Steria, SignGuard: local.methodid.ccp1
Varför finns detta här? Passar det bättre under annat avsnitt eller i FAQ? Är det relevant på en översikt kring SAML/IdP? Ska det flyttas till tidigare avsnitt?
10.4 Skicka med personnummer till inloggningsmetoden
Det är även möjligt att skicka med personnummer om man har valt att använda sig av BankID på annan enhet.
```xml https://my.sp/191212121212
```
Varför finns detta här? Passar det bättre under annat avsnitt eller i FAQ? Är det relevant på en översikt kring SAML/IdP? Ska det flyttas till tidigare avsnitt?
10.5 Information kring respektive certifikatsutgivare
Varför finns detta här? Passar det bättre under annat avsnitt eller i FAQ? Är det relevant på en översikt kring SAML/IdP? Ska det flyttas till tidigare avsnitt? Gäller hela 10.5 avsnittet.
...
tjänstelegitimationer som idag har en spridning i Sverige, utgivna av SITHS och Freja OrgID.
eID Verify har en IdP speciellt för e-tjänstelegitimationer, IdP företag. Se Metadata
5 Certifikat för att verifiera XML-DSig
SP måste verifiera att signaturen på IdP:ns svar är korrekt (XML-C14N). För detta behövs CGI:s publika nyckel för IdP-tjänsten. Certifikatet återfinns i metadatat.
6 Tydlighet att inloggning sker på annan domän
Vi rekommenderar att varje SP på sina sidor förklarar att tjänsten säker inloggning sker från CGI och att URL på inloggningssidan kommer vara under funktionstjanster.se
Detta för att vara tydlig till användaren och undvika att användaren blir osäker.
7 Eget domännamn
Det är möjligt att använda eget domännamn på federationen om så önskas. Då ser era användare t.ex. https://idp.myndighet.se istället för domän under funktionstjanster.se i adressfältet.
8 Övriga funktioner
8.1 Begär en autentiseringsmetod eller LOA-klass
8.1.1 Begär LOA-klass med AuthnContextClassRef
För att begära en specifik LOA-klass skicka med klassens uri i AuthnContextClassRef. För definition av LOA-klasser se DIGGs tekniska ramverk
För mer information kontakta funktionstjanster@cgi.com
8.1.2 Begär autentiseringsmetod med eid:names
Använd i första hand en IdP som enbart har en autentiseringsmetod
På vår Metadata sida finns fullständig information om vilken IdP som erbjuder vilken metod.
En SP kan i requesten till IdP:n direkt ange vilken autentiseringsmetod som skall användas. Alternativt anropa en IDP som bara har en inloggningsmetod. Nedan beskrivs hur man skickar med metod i AuthnRequest-anropet. Om man listar inloggningsmetoderna i den egna Discovery-tjänsten minimeras det GUI som IdP:n visar till användaren.
I requesten kan vi ta mot och tolka strängen eid:names
IdP test har följande vanliga inloggningsmetoder:
BankID eid:names:bankid
Freja eid:names:freja
Exempel: Inloggning med BankID i test.
```xml
| Kodblock |
|---|
<saml2:AuthnContextClassRef xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">urn:eid:names:bankid</saml2:AuthnContextClassRef>
|
```
IdP produktion har följande vanliga inloggningsmetoder:
BankID eid:names:bankid
Freja eid:names:freja
8.3 Personnummer med BankID
Idag skall personnummer endast skickas med till BankID vid enstaka use-case gällande signering. Personnummer skall endast skickas då syftet är att låsa QR-koden så att den bara går att scanna med BankID app av personen som startat signering med rörlig QR kod. Detta för att säkerställa att samma individ som startade signeringen är den som avslutar.
8.4 Information kring respektive utfärdare
8.4.1 Telia
Vid inloggning med Telia så försöker den först verifiera att det finns en NetID installation, om den ej finner någon installation av NetID så kommer den försöka med dubbelsidig SSL. Dock måste användaren manuellt som det ser ut idag göra denna bekräftelse.
...
8.
...
4.2 BankID
BankID hanteras som BankID på samma enhet och BankID på annan enhet.
...
8.
...
4.2.1 BankID på samma enhet
Denna metod använder sig av BankID funktionen autostart.
...
8.
...
4.2.2 BankID på annan enhet
Denna metod kräver att personnumer matas in. Detta kan ske på SP sidan om så önskas. Personnummer måste även skickas med QR kod scannas. QR kod måste också användas vid signering om inloggning skett med BankID på annan enhet.
8.4.3 Freja eID
Freja eID hanteras som en metod som kan användas både på samma enhet med autostart eller på annan enhet med QR-kod
10.5.3 Mobilt BankID, BankID på kort, BankID på fil
Idag accepteras alla typer av BankID, det är dock möjligt att separera dessa om så önskas. Då blir det fler alternativ för användaren som visas på discoverytjänsten.
...
9 ipv4/ipv6
Vår IdP hanterar både ipv4 och ipv6. Om användaren har dualstack så är det operativsystemet som avgör vilket som kommer användas. Oftast är det ipv6.
...
10 Federering
Federering(SSO) är ej standard för nya tjänster. Det innebär att man måste beställa vilka man skall tillåtas federera med.
...
10.1 Tvingad autentisering eller kontroll av att användare fortfarande är inloggad (aktiv) i IdP:n
För en användare som loggat in med e-legitimation via IdP:n, så är den inloggningen giltig (aktiv) i 60 minuter såvida en SLO-request inte skickats. Detta innebär att användaren kan växla mellan olika e-tjänster och få SSO. (så kallad federering). Men ibland är detta inte önskvärt utan e-tjänsten kanske vill kräva en ny autentisering. Det kan också vara så att e-tjänsten vill kontrollera att användaren verkligen fortfarande är inloggad i IdP:n och att IdP:n inte mottagit någon SLO-request för användaren från annan SP eller att 60-minuters gränsen inte passerat. Dessa två funktioner går att använda och kombinera i SAML standarden med ForceAuthn och IsPassive.
...