Här beskriver vi CGI:s implementation av SAML i sin Identity Provider (IdP) för en normal standardanslutning. Vänligen kontakta CGI via funktionstjanster@cgi.com om ni vill göra en anslutning som inte följer den standardanslutning som beskrivs i detta dokument eller om ni har frågor av teknisk karaktär och önskar vägledning.

1 Översikt

CGI:s IdP-tjänst baseras på en SAML 2.0 standard med vissa givna profiler. Kunder som litar på vår IdP kallas för Service Provider (SP) och måste kunna hantera de protokoll och profiler som IdP-tjänsten hanterar.

1.1 SAML 2.0 Profiles

SAML specificerar ett antal profiler som beskriver olika användningsfall. CGI stödjer två profiler: ”Web browser SSO”- och ”Single Logout SLO”-profilerna.

1.2 SAML 2.0 Bindings

I SAML 2.0 finns ett antal så kallade ”bindings”, olika sätt som meddelanden mellan SP och IdP utbyts på. Vi använder normalt två av dessa sätt i en standardanslutning.

I SSO-profilen används ”HTTP Redirect (GET) ” för SP och på IdP används ”HTTP POST”.

I SLO-profilen används bindningen ”HTTP POST” både i SLO Request och Response.

1.3 SSO – Single Sign-On

Vid vanlig SP-initierad inloggning:

1. Klienten hämtar en sida som kräver autentisering.

2. SP kontrollerar om klienten har en inloggad session. Om ej, genereras ett SAML ”authentication request”-meddelande och klienten riktas om till IdP med meddelandet.

3. Klienten skickar ”authentication request”-meddelandet med GET-metoden till IdP.

4. Om klienten inte redan är inloggad mot IdP tillkommer steg för eventuellt val av autentiseringmetod samt autentisering.

5. Efter autentiseringen skickas en webbsida tillbaka till klienten. Webbsidan innehåller responsen samt kod för att klienten skall posta den till SP.

6. Responsen postas till SP.

7. SP kontrollerar att responsen stämmer. Om den stämmer loggas användaren in och den önskade sidan returneras.

ClientService ProviderIdentity Provider1. Hämtar sida som kräver inlogg (GET)2. Ompekning till IDP med AuthnRequest3. Skicka AuthnRequest till IDP (GET)Autentiseringenskiljer mellanolika metoder.opt[ 4. Autentiseringsförfarande ]5 Ompekning till SP med AuthnResponse6 Skicka AuthnResponse till SP (POST)7 Leverera begärd sidaClientService ProviderIdentity Provider

1.4 IdP-initierad inloggning (Unsolicited Response)

Initierad inloggning (Unsolicited Response) stöds ej i eID Verify.

1.5 SLO – Single Logout

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

4 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 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

```

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

I AuthnRequesten kan SP:n sätta dels ForceAuthn och dels IsPassive för att styra hur IdP:n ska hantera inloggningen.

• IsPassive=true innebär att om användaren inte är inloggad på IdP:n skickas AuthnFailed tillbaka till SP:n (ingen användarinteraktion tillåts).

• ForceAuthn=true innebär att användaren måste logga in, oavsett om användaren redan var inloggad. (användarinteraktion krävs)

CGI kan konfigurera varje SP med "Only allow active authn" som Ja eller Nej. Med detta kan olika ”funktioner” med isPassive fås:

Om "Only allow active authn" för SP är Ja (aktiverad):

• ..och IsPassive är false tvingas alltid användaren att logga in.

• ..och IsPassive är true skickas alltid authnfail till SP:n.

Om "Only allow active authn" INTE är aktiverad (Nej):

• ..och IsPassive är false blir man inloggad automatiskt om man är inloggad, annars får man logga in manuellt.

• ..och IsPassive är true returneras direkt AuthOk eller AuthFail beroende på om användaren är inloggad eller ej.