Hoppa till slutet på meta-data
Gå till början av metadata

Du visar en gammal version av den här sidan. Visa nuvarande version.

Jämför med nuvarande Visa sidhistorik

« Föregående Version 16 Nästa »

Generell FAQ

Vad behöver jag för att ansluta till CGI eID Verify?

API För att ansluta till tjänsten via API krävs att ni har ett så kallat ServiceID (policy) samt en AccessToken, vilket fås av CGI. ServiceID identifierar dig som kund och AccessToken kan ses som ett lösenord till tjänsten och det är unikt för varje kund. Ni behöver även ange den IP-adress som ska kunna kommunicera med oss. Testmiljön är öppen och information om ServiceIDn och AccessToken för test finns att läsa här:Testmiljö

SAML När SAML används går all kommunikation via slutanvändarens webbläsare. Detta innebär att öppnande av brandväggar etc. inte är nödvändigt om man inte hämtar dynamiskt metadata. Vår testmiljö är öppen för er att testa men i produktion måste varje saml:Issuer vara konfigurerad och ”godkänd” av CGI. 

Vilka uppgifter behövs i samband med anslutning?

Det varierar lite beroende på vilket anslutningssätt ni väljer. Vi efterfrågar de detaljer vi behöver som en del av onboardingprocessen. Hör av dig till eServices@cgi.com för kommersiella frågor eller om du önskar en presentation av vår tjänst och vill veta mer om nästa steg.

Vad gäller kring er testmiljö?

eID Verifys testsystem är normalt tillgängligt dygnet runt. Observera att detta är ett testsystem där våra kunder och potentiella kunder ska kunna testa ny funktionalitet och förändringar. Vi erbjuder ingen SLA eller tillgänglig support på kort varsel kring vår testmiljö. Har ni som kund behov av en egen testmiljö - fråga oss. Volym- eller prestandatester mot testsystemet får ej utföras utan att först kontakta CGI

Vad är GRP?

GRP är samlingsnamnet på CGIs egenutvecklade API och en av två möjliga anslutningsmetoder till CGI eID Verify. Just nu erbjuds anslutning via API primärt på GRP version 3 vilket är ett modernt REST api. Det finns också möjlighet att ansluta via SOAP (Legacy). Kontakta oss om dokumentation gällande SOAP önskas. Aktuell dokumentation kring vårt API finner du här: API

När försvinner stöd för SOAP (Legacy) API?

Idag finns inget datum när SOAP kommer fasas ut och sluta supportas av oss. Detta gäller GRP 2.3 dvs den senaste versionen av vårt SOAP-api. Detta är byggt mot den senaste versionen av BankID och Frejas API. På sikt ser vi att detta kommer fasas ut och helt ersättas av REST.

Hur många servicefönster per år har ni?

Under varje år kommer ett visst antal servicehelger att genomföras vilket kan påverka driften av eID Verify. För aktuella datum och tider, säkerställ att ni alltid informerar oss om vem eller vilka personer och funktioner som skall ta del av mailutskick vid publicering av nyheter och information. Detta är en del av onboardingprocessen hos oss. Men vet ni med er att ni önskar addera eller justera någon kontaktperson går det bra att göra genom att meddela oss via vår kundportal. Saknar ni användare i kundportalen så meddela oss via webportals.se@cgi.com

Teknisk FAQ

Exempelmeddelanden IdP

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.

 <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"...

Authentication Response

Exempel på en lyckad inloggning med e-legitimation (test) med BankID.

 xml <saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"...

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.

 <samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"...

Logout Response

Exempel på en lyckad Logout Response.

 <saml2p:LogoutResponse xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol...

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

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

```

Övriga frågor?

Tveka inte att kontakta oss vid funderingar. Är du en befintlig kund så skickar du in din fråga eller beställning via vår kundportal. Är du en blivande kund kan du rikta frågor av kommersiell karaktär till eServices@cgi.com och frågor av teknisk karaktär till funktionstjanster@cgi.com  

  • Inga etiketter