LØSNINGSBESKRIVELSE - GENERELT

Transkript

1 AMS - A-KASSEKOMMUNIKATIONEN VIA WEBSERVICES LØSNINGSBESKRIVELSE - GENERELT VERSION 3.1 DATO 7.september 2012 REFERENCE FORFATTER Rune Gram-Madsen (KC), Tøger G. Nørgaard (KC), Kenneth Lund (KC) og Alex Larsen (AMS) Slettet: 8 Slettet: februar Slettet: Alex Larsen (AMS), KONTRAKTNUMMER SF099 Knowledge Cube A/S Bernstorffsgade 50, 7. sal DK 1577 København V T F CVR info@knowledgecube.net

2 DOKUMENTVERSIONER Version Dato Initialer Afsnit Ændringer maj 2011 rgm Første version maj 2011 rgm Input fra Anders omkring AMP juni 2011 rgm juni 2011 rgm Ændrede forudsætninger juni 2011 rgm september 2011 rgm Ændret fra Analyse til Løsningsbeskrivelse september 2011 rgm Efter review af AMS september 2011 rgm Efter review af AMS oktober 2011 rgm Hændelsesskema indlagt i dokumentet oktober 2011 rgm Efter input fra Rasmus oktober 2011 rgm Sammenskrevet efter workshop november 2011 Rgm / all Opdateret efter workshop og review december 2011 TN Konsekvensrettet efter workshop-referater samt møde i AMS d. 7.december januar 2012 TN Rettet efter review af AMS januar 2012 TN Løsningsbeskrivelse er splittet op i en generel del og en del pr. fase januar 2012 TN Revideret efter review fra AMS januar 2012 TN Revideret efter review fra AMS februar 2012 TN Revideret efter workshop med a-kasserne september 2012 KL Opdateret jf. implementerings- og test for fase 1 samt ændringer til tidsplan. Side 2 af 20

3 INDHOLDSFORTEGNELSE 1 Indledning Forudsætninger Implementeringsmodel og faser Tidsplan 5 2 A-kasserne som webserviceaftagere af DFDG Generelt aftagemønster for aftagere af DFDG Hændelser eller statusændring fra DFDG til aftager via WSRM WSRMService (WS-ReliableMessaging) CreateSequence CloseSequence TerminateSequence SequenceAcknowledgement Web Service Header elementer SequenceRequest SequenceResponse AckRequested WS-RM Policy 15 3 Sikkerhed Krav til web service aftagerne Policy og sikkerhedsmodeller Certifikatkommunikation Certifikater under TLS Serviceaftagers forpligtigelser Kodelister 19 Slettet: 1 Indledning Forudsætninger Implementeringsmodel og faser Tidsplan 5 2 A-kasserne som webserviceaftagere af DFDG Generelt aftagemønster for aftagere af DFDG Hændelser eller statusændring fra DFDG til aftager via WSRM WSRMService (WS- ReliableMessaging) CreateSequence CloseSequence TerminateSequence SequenceAcknowledgement Web Service Header elementer SequenceRequest SequenceResponse AckRequested WS-RM Policy 15 3 Sikkerhed Krav til web service aftagerne Policy og sikkerhedsmodeller Certifikatkommunikation Certifikater under TLS Serviceaftagers forpligtigelser Kodelister 19 Formateret... [1] Side 3 af 20

4 1 Indledning I forlængelse af kommunaliseringen af beskæftigelsesindsatsen er det besluttet dels at lukke Arbejdsmarkedsportalens brugergrænseflade som adgang til det fælles datagrundlag og dels at flytte de resterende dele af a- kassekommunikationen over på webservices og væk fra den eksisterende daglige overførsel via recordbaserede filformat. Basis for a-kassernes fremtidige adgang til det de kommunale data og hændelser, bliver via webservices mod Det Fælles Datagrundlag (DFDG). Det vil sige modtagelse af hændelser, indrapportering af medlemstilgang/afgang, rådighedsvurderinger, og andre hændelser. Der er tale om en teknisk modernisering, hvor kommunikationsvejen omlægges så den følger strukturen i resten af DFDG. Slettet: a Slettet: f Slettet: d Slettet: I indeværende dokument beskrives overordnet hvorledes overgangen til webservices vil foregå i faser og hvordan den enkelte a-kasse generelt skal koble sig op mod DFDG, herunder specielt en beskrivelse af sikkerhed. Til hver fase hører endvidere en specifik løsningsbeskrivelse i et separat dokument, der for hver fase beskriver det konkrete tekniske og forretningsmæssige indhold. VIGTIGT: Hændelser via a-kassemotoren vil forsætte indtil idriftsættelse af fase 4 i projektet. Det betyder at det er a-kassernes ansvar at filtrere på dette i forhold til den idriftsættelsesplan, som aftales mellem Arbejdsmarkedsstyrelsen og a-kasserne, og sikre en juridisk cut-over. 1.1 Forudsætninger Slettet: Følgende er taget som forudsætninger for projektet: 1) A-kasserne kobles alt overvejende over på de webservices som allerede udbydes til kommunerne a. A-kasserne tilbydes at anvende WCF-SOAP snitfladerne med meddelelsesbaseret sikkerhed WS-* i. De a-kasser der ikke har mulighed for at koble op mod disse tilbydes adgang til samme WCF-SOAP webservices med transportbaseret sikkerhed over HTTPS (TLS) b. A-kasserne skal anvende funktionscertifikater i stedet for medarbejdercertifikater og/eller virksomhedscertifikater (håndteres dog i andet projekt). 2) Arbejdsmarkedsstyrelsen er p.t. i gang med en modernisering af de eksisterende webservices og a- kasserne vil først overgå fuldstændigt til webservices når moderniseringen af gennemført. 3) Der vil i forbindelse med omlægningen af a-kassekommunikationen ske en kraftig forenkling af de beskeder der sendes fra jobcentrene og arbejdsløshedskassernes tilbagemeldinger herpå. Arbejdet med udmøntning af endeligt forslag for UPH er og tilbagemeldingerne er endnu ikke afsluttet. 4) Der vil være adgang til DFDG via Arbejdsmarkedsportalens brugergrænseflade indtil der er etableret adgang til DFDG for alle a-kasser. Slettet: Moderniseringen forventes påbegyndt ved release med forventet idriftsættelse 22. oktober. 1.2 Implementeringsmodel og faser Overgangen til webservices skal løbe over en række faser. Da Arbejdsmarkedsstyrelsen sideløbende med omlægningen af a-kassekommunikationen er i gang med en modernisering af det samlede webservicekatalog er Slettet: Det er målet at hver a- kasse så vidt det er muligt kan vælge at overgå til webservices uafhængigt af hinanden, og hver a-kasse i en række trin. Side 4 af 20

5 indholdet samt tidsplan fra og med fase 2 tentativt da omlægningen af a-kassekommunikationen vil skulle ske i overensstemmelse med principperne for moderniseringen af det samlede webservicekatalog. Fase 1: Omlægning af hændelser der i dag kører via AKM (excl. UPH). Følgende hændelser er inkluderet: T, A, C, sygdom, raskmelding, ferie, oprettelse af jobplan og mindre intensiv indsats (F30-34). Hændelserne implementeres som adgang til WSRM-køen via WsrmService og beskedservices og WsrmMessageService (Version 1, 4 og 5) og UnemploymentFundInterviewService samt CodeListService. CodelistService Sidstnævnte skal anvendes til at hente de beskrevne benyttede kodelister. Forud for denne fase er implementeret adgang til UnemploymentFundMembershipService for medlems til- og afgang (MA og MT). Slettet: Hændelserne implementeres som adgang til WSRM-køen via WsrmService og WsrmMessageService samt CodeListService. Fase 2: Omlægning af UPH og tilbagemeldinger herpå til nye webservices, hvor UPH er modelleres ind i eksisterende hændelsesformat. Følgende er med: UPH er, herunder negative UPH er, V og tilbagemeldingerne RJ, RN, RI, CJ, CN. Det er valgt at have CN, CJ med her da tilbagemelding på CN sammentænkes med tilbagemeldinger på de øvrige hændelser. Hændelser implementeres som yderligere webservicemetoder via WSRM-køen og tilbagemeldinger som nye webservicemetoder i UnemploymentFundMessageService. Der vil i forlængelse af den tekniske omlægning af UPH er og tilbagemeldinger herpå ske en forretningsmæssig forenkling af UPH-området. Forenklingen af UPH-området gennemføres som en opdatering af kodelisterne. Fase 3: Omlægning til webservices for funktionalitet der i dag tilgås via Arbejdsmarkedsportalen - adgang til DFDG webservices for opslag og registrering. Fase 4: Lukning af adgang til a-kassemotor samt adgang til AT&T postkasse med AKM (tidl. Amanda) lukkes. Fase 5: Lukning af adgang til arbejdsmarkedsportalen. For faserne 1 til 3, vil der i hvert a-kassesystem skulle foretages ændringer og tilpasninger i egen brugergrænseflade (dvs. skærmbilleder og eventuelle workflow), i eget forretningslogiklag (dvs. it systemets programmer) samt i egen database. 1.3 Tidsplan Planen er at omlægningen gennemføres i løbet af 2012/2013 med faserne fordelt således: Fase februar: endelig løsningsbeskrivelse for fase 1 foreligger marts: webservicefunktionalitet udstilles i testmiljø april: idriftsættelse DFDG webservicefunktionalitet til fase april 1. juni: 1. testslot for a-kasser maj 8. juni: 2. testslot for a-kasser maj 15. juni: 3. testslot for a-kasser maj 14. september: 4. testslot for a-kasser. Side 5 af 20

6 - 8. oktober 26. oktober: 5. testslot for a-kasser. - [TBD]: idriftsættelse a-kassernes it-systemer. - [TBD]: Juridisk cut-over. - Slettet: Fase maj: Webservicedokumentation, WSDL samt master-testplan udsendes i kladde juli: Varsling af funktionalitet samt webservicedokumentation udsendes i endelig version juli: Endelig udgave af WSDL er udsendes august: webservices vil være tilgængelige oktober: idriftsættelse DFDG. - [TBD]: integrationstest. - [TBD]: idriftsættelse a-kassernes it-systemer. Fase 3 - [TBD]: Webservicedokumentation, WSDL samt master-testplan udsendes i kladde. - [TBD]: Varsling af funktionalitet samt webservicedokumentation udsendes i endelig version. - [TBD]: Endelig udgave af WSDL er udsendes. - [TBD]: webservices vil være tilgængelige. - [TBD]: idriftsættelse DFDG. - [TBD]: integrationstest. - [TBD]: idriftsættelse a-kassernes it-systemer. Fase 4 og 5 - [TBD] Slettet: <#>Vil følge releaseplanen for og dermed vil a-kasserne fuldt ud indgå på linie med andre webserviceaftagere i AMS faste releasecyklus: <#> Slettet: Slettet: xxx Slettet: xxx Slettet: Vil følge releaseplanen for Slettet: 1 Slettet: Vil følge releaseplanen for eller Side 6 af 20

7 2 A-kasserne som webserviceaftagere af DFDG A-kassernes adgang til DFDG-Webservices inddeles i tre dele: 1. Hændelser fra DFDG til A-kassen 2. Tilbagemeldinger og registreringer fra A-kassen til DFDG 3. Opslagsservices som A-kasserne kan anvende Hændelser fra DFDG til A-kassen A-kassen vil som udgangspunkt kun modtage hændelser på medlem i egen kasse som er ledig. Dvs. dagpengemodtager og dimittender. I visse situationer vil a-kassen desuden modtage hændelser for personer som ikke er medlem af den pågældende a-kasse (besked om MA ved a-kasseskift) samt hændelser for personer der aktuelt ikke er ledige dagpengemodtagere. Alle beskeder til a-kasserne udsendes via WSRM kø. Dette er en kø af beskeder som a-kasserne selv skal tømme med jævne mellemrum. Hver besked vil indeholde en webservicemetode, der skal kaldes. A-kasserne skal bruge WsrmService for at gennemløbe køen og derefter forskellige beskedservices for hver enkelt webservicemetode. Slettet: WsrmMessageService For brug af WSRM køen se da senere i afsnittet. Tilbagemeldinger og registreringer fra A-kassen til DFDG A-kassen vil kunne tilbagemelde og registrere til DFDG ved at kalde en række registreringsmetoder i webservicene JobcenterMessageService, UnemploymentEnrollmentService, AbsenceRegistrationService og UnemploymentFundMembershipServic. A-kasserne vil kun kunne foretage registreringer og tilbagemelde vedrørende en ledig, der er medlem af dennes a-kasse. Opslagsservices som A-kasserne kan anvende A-kassen vil kunne hente data for personer som er registreret som medlem i deres kasse ved en kalde en række forskellige opslagsmetoder i et antal webservices: UnemploymentFundEventHistoryService (hændelsesoverblik for enkelt person), PersonStatusService, PersonHistoryService og Getmetoderne i JobplanReportingService. Desuden skal A-kasserne kalde CodeListService en gang i døgnet for at hente de aktuelle kodelister, der benyttes på tværs af webservices. Det udvikles nye, konsoliderede og opdaterede versioner af en række webservices i forbindelse med moderniseringen af det samlede webservicekatalog. Slettet: UnemploymentFund- Service Slettet: Slettet: UnemploymentFund- PersonService Slettet: Slettet: Mht. opslagsservices gælder følgende principper: 1. A-kasserne vil kunne se informationer vedrørende en ledig, der er medlem af dennes a-kasse. 2. Hvis a-kassen skal se data for et medlem, der aktuelt ikke er ledig dagpengemodtager skal a-kassen først afgive en begrundelse for at få adgang. 3. A-kassen vil have adgang til opslag i det fælles datagrundlag vedrørende et tidligere medlem i en periode på 90 dage efter medlemmets afgang med henblik på færdigbehandling af uafsluttede hændelser. A-kassen vil i sådanne situationer skulle angive begrundelse. 4. A-kassen vil have adgang til opslag i det fælles datagrundlag vedrørende en persons seneste eller nuværende a-kassetilhørsforhold. Dette for at lette sagsgangen omkring medlemsoverflytninger. Da personen ikke er medlem i kassen endnu skal a-kassen angive en begrundelse. Når et medlem optages i en ny a-kasse, skal den Side 7 af 20

8 nye a-kasse selv hente status for personen via PersonStatusService og hente hændelseslog via Unemployment- FundEventHistoryService. Hændelser der vedrører den gamle kasse behandles af denne. Det er op til den enkelte a-kasse, at sikre begrundelsesstyret adgang til data i det fælles datagrundlag samt gennemføre den nødvendige logning ved opslag i data som er omfattet af kravet herom. Slettet: UnemploymentFund- PersonService 2.1 Generelt aftagemønster for aftagere af DFDG Et enkelt webservice-kald består af en forespørgsel og et følgende svar sendt over A) http med SOAP sikret med WS-Security eller B) https med SOAP sikret med TLS. Som udgangspunkt anbefales model A til arbejdsmarkedsportalens webservices, men for de A-kasser eller leverandører der ikke har mulighed for at anvende WS-Security tilbydes adgang til model B. Forskellen på de to adgange vil være forskellige end points til den samme webservice samt forskellig brug af certifikater (se afsnittet om sikkerhed for mere info om dette), eksempelvis: WS-security: TLS: (Bemærk det ekstra t i akmwcftservice og https i stedet for http) Når en aftager skal sende en meddelelse sker det ved at aftageren kalder en af DFDG s webservicemetoder, der som input tager en meddelelse i SOAP/XML-format. Webservicen checker, at formatet af meddelelsen er korrekt i forhold til det XML-Schema, der er defineret for meddelelsestypen. Hvis dette check passeres, checkes om dataindholdet i meddelelsen er validt i forhold til den ønskede forretningsoperation. Herefter udføres forretningsoperationen og et ID (en GUID) returneres til kalder som illustreret i figuren nedenfor. Figur 1: Kommunikationsmønster for meddelelse fra aftaler til web service 2.2 Hændelser eller statusændring fra DFDG til aftager via WSRM Side 8 af 20

9 Når der er registreret en hændelse eller et statusskift i DFDG udsendes en notifikation til relevante aftagere. Hændelser opsamles således ikke pr. dag. Dette betyder derfor også som udgangspunkt at hændelser f.eks. sygdom eller fravær udsendes når det registreres og ikke først når det indtræffer. Aftager skal altså som udgangspunkt selv stå for dette bogholderi. Notifikationen sendes via webserviceprotokol, der tager afsæt i WSRM Webservice Reliable Messaging standarden. Køen er implementeret sådan at aftager selv skal tage initiativ til at tømme køen (polle), f.eks. hvert 10. minut. Aftager modtager en liste af webservice endpoints og et operationsnavn, der peger på metoder i WsrmMessageService - typisk af formen GetXXX, hvor XXX er navnet på en forretningshændelse. Operationen returnerer en liste af hændelsesobjekter af en specifik type. Samlet returneres der pt. højest 500 objekter ad gangen, uagtet hvor mange hændelser, der ligger i køen. Hvert objekt er forsynet med en EventDate og den modtagne liste af objekter skal sorteres så ældste objekt behandles først. Denne sortering er meget vigtig da der sagtens kan modtages flere hændelser for samme person. Figur 2: Kommunikationsmønster for meddelelser fra webservice til aftager Ovenstående viser sekvensen af operationer, der skal til for at tømme køen. Hændelser i f.eks. Jobnet, Arbejdsmarkedsportalen eller jobcenteret, modtages af DFDG og lægges på en kø som en XML besked. Herefter starter ovenstående sekvens. Når aftageren har hentet alle meddelelser, foretager aftageren derefter et afsluttende kald, som bekræftelse på modtagelse. Hvis DFDG også har registreret alle meddelelser som korrekt afhentet, vil DFDG herefter fjerne de meddelelser, der netop er hentet fra køen. Hvis der sker fejl under afhentning, kan aftager afbryde under vejs. Hvis der afbrydes under vejs vil beskederne fortsat ligge i køen indtil næste gang aftager forsøger at hente dem. Side 9 af 20

10 Webservice Aftager Webservice DFDG Forretningslag DFDG Forespørgsel om nye meddelelser (CreateSequence) Find ventende meddelelser Ventende meddelelser Svar med ventende meddelelser Hent meddelelser af type x Sekvens af medd. af type x Hent meddelelser af type x Sekvens af medd. af type x gentages n gange Fejl under modtagelse? Afslut (CloseSequence) CloseSequence Response Figur 3: Kommunikationsmønster for meddelelser fra webservice til aftager ved fejl 2.3 WSRMService (WS-ReliableMessaging) Følgende afsnit beskriver service elementerne i WS-ReliableMessaging i forhold til denne løsning. Implementeringen af WS-ReliableMessaging er udarbejdet på baggrund af OASIS specifikationen Web Service Reliable Messaging (WS-Reliable Messaging) 14 marts WSRM gør det muligt for aftagerne at hente og kvittere for modtagelsen af en række beskeder fra flere services på en ensartet måde. De services, der er en del af WSRM kommunikationen (dvs. de services, der leverer beskeder til aftageren), som er indeholdt i en WSRM Sequence, benytter specifikke WSRM Soap Header beskeder til input og output. Det er nødvendigt, at aftageren benytter disse headere, da det ellers ikke vil være muligt at benytte WSRM servicen. WS-RM servicen indeholder fire webservicemetoder, der er nødvendige for at implementere WS-Reliable Messaging protokollen, som beskrevet i foregående afsnit. Side 10 af 20

11 CreateSequence: initierer en pålidelig overførsel af meddelelser og returnerer en beskrivelse af hvilke meddelelser, der er klar til afhentning. Acknowledge: bekræftelse på modtagne beskeder fra services. CloseSequence: bruges til at afbryde en pålidelig overførsel inden normal afslutning. Hele overførslen betragtes som annulleret, og serveren vil derfor ikke slette beskeder, som er blevet sendt i den pågældende overførsel, ligesom aftageren vil få disse sendt beskeder igen ved næste overførsel. TerminateSequence: afslutter en korrekt gennemført overførsel efter det er konstateret, at alle meddelelser i overførslen er modtaget korrekt CreateSequence CreateSequence metoden benyttes til at initiere en WS-ReliableMessage overførsel af meddelelser og returnerer en beskrivelse af hvilke meddelelser, der er klar til afhentning (serviceinventory). Serviceaftageren skal derefter kalde alle de services, der er angivet i serviceinventorydelen af CreateSequence- Respons meddelelsen. Samtlige beskeder i inventory beskeden skal hentes og accepteres i form af en Acknowledgement for hver besked. Det vil ikke være muligt at afslutte WSRM sequencen korrekt med mindre, at aftageren har hentet samtlige beskeder. Når alle services er kaldt og meddelelserne er accepteret Acknowledged skal Sequencen lukkes via TerminatSequence. Hvis aftageren ikke har hentet og accepteret alle meddelelser i sequencen, kan sequencen ikke termineres, og det er ikke muligt at oprette nye sequences. Input: Element AcksTo (øvrige WS-RM elementer) Beskrivelse WS-Addressing endpoint, hvortil bekræftelser skal sendes. (Bruges ikke af servicen, da det er klienten, der sender bekræftelser men skal medtages alligevel for at overhold WS-RM schemaer). Format: WS-Addressing EndPoint. Øvrige WS-RM elementer accepteres, men behandles ikke. Xml eksempel: <wsrm:createsequence> <wsrm:ackto>... </wsrm:ackto> </wsrm:createsequence> Output: Element Identifier Inventory Beskrivelse Unikt sekvens-id, der skal benyttes i forbindelsen med al øvrig kommunikation inden for denne sequence. Format: GUID Extension element, som ikke er indeholdt i WS-RM. Består af underele- Side 11 af 20

12 menter: <Inventory> <Service name= UnemployedRegistration count= 2 /> <Service name= Appropriation count= 1 /> </Inventory> Dette eksempel fortæller, at der venter to meddelelser af typen UnemployedRegistration og én af typen Appropriation. Der kan være ligeså mange <Service> tags som der er service metoder til afhentning af meddelelser. Formateret: Engelsk (Storbritannien) Formateret: Engelsk (Storbritannien) Xml eksempel: <wsrm:createsequenceresponse> <wsrm:identifier>.. </wsrm:identifier> <ams:inventory> <ams:service name= UnemployedRegistration count= 2 /> <ams:service name= Appropriation count= 1 /> </ams:inventory> </wsrm:createsequenceresponse> CloseSequence CloseSequence: bruges til at afbryde en pålidelig overførsel inden normal afslutning. Hele overførslen betragtes som annulleret, og serveren vil derfor ikke slette beskeder, som er blevet sendt i den pågældende overførsel, ligesom aftageren vil få disse sendt beskeder igen ved næste overførsel. Input: Element Identifier Beskrivelse Unikt sekvens id, leveret som output af kaldet til CreateSequence Format: GUID Xml eksempel: <wsrm:closesequence> <wsrm:identifier>.. </wsrm:identifier> </wsrm:closesequence> Output: Element Identifier Beskrivelse Unikt sekvens-id leveret som output af kaldet til CreateSequence Format: GUID Xml eksempel: <wsrm:closesequenceresponse> <wsrm:identifier>.. </wsrm:identifier> </wsrm:closesequenceresponse> Side 12 af 20

13 2.3.3 TerminateSequence TerminateSequence afslutter en korrekt gennemført overførsel efter det er konstateret, at alle meddelelser i overførslen er modtaget korrekt. Input: Element Identifier Beskrivelse Unikt sekvens-id leveret som output af kaldet til CreateSequence Format: GUID Xml eksempel: <wsrm:terminatesequence> <wsrm:identifier>.. </wsrm:identifier> </wsrm:terminatesequence> Output: Element Identifier TerminateSequenceCorrect MissingRange Beskrivelse Unikt sekvens-id leveret som output af kaldet til CreateSequence Format: GUID Servicens svar på bekræftelsen i input. Hvis bekræftelsen var korrekt, returneres true, ellers false. Format: boolean Dette element angiver hvilke sekvensnumre, som er afsendt, men ikke kvitteret for. Elementet er kun til stede hvis AckCorrect=false. Format: <MissingRange Lower= 2 Upper= 4 /> for sammenhængende interval, eller: <MissingRange Lower= 2 Upper= 3 /> <MissingRange Lower= 6 Upper= 6 />... for ikke-sammenhængende intervaller. Xml eksempel: <wsrm:terminatesequenceresponse> <wsrm:identifier>.. </wsrm:identifier> <wsrm:terminatesequencecorrect>.. </wsrm:terminatesequencecorrect> <wsrm:missingrangecollection> <wsrm:missingrange Upper="int" Lower="int" /> <wsrm:missingrange Upper="int" Lower="int" /> </wsrm:missingrangecollection> </wsrm:terminatesequenceresponse > 2.4 SequenceAcknowledgement SequenceAcknowledgement sendes som bekræftelse på modtagne beskeder. Side 13 af 20

14 Input: Element Identifier AcknowledgementRange eller None Beskrivelse Unikt sekvens-id leveret som output af kaldet til CreateSequence Format: GUID Angivelse af modtagne meddelelser på aftagersiden. None angiver at ingen meddelelser er modtaget. Er der modtaget mindst én, angives det på følgende måde: <AcknowledgementRange Lower= 1 Upper= 3 > som fortæller, at meddelelser med sekvensnumre 1, 2, 3 er modtaget. For ikke sammenhængende intervaller, f.eks. hvis sekvensnumre 1,3,4 er modtaget, bruges flere AcknowledgementRange: <AcknowledgementRange Lower= 1 Upper= 1 > <AcknowledgementRange Lower= 3 Upper= 4 > Xml eksempel: <wsrm:sequenceacknowledgement> <wsrm:identifier>.. </wsrm:identifier> <AcknowledgementRange Lower= 1 Upper= 1 > <AcknowledgementRange Lower= 3 Upper= 4 > </wsrm:sequenceacknowledgement> Output: Vigtigt!: Denne besked er ikke defineret i WS-RM, men er nødvendig i det aktuelle setup, hvor meddelelser sendes modsat i forhold til WS-RM basis profilen. Element Identifier AckCorrect Beskrivelse Unikt sekvens-id leveret som output af kaldet til CreateSequence Format: GUID Servicens svar på bekræftelsen i input. Hvis bekræftelsen var korrekt, returneres true, ellers false. Format: boolean Xml eksempel: <wsrm:sequenceacknowledgementresponse> <wsrm:identifier>.. </wsrm:identifier> <wsrm:ackcorrect>.. </wsrm:ackcorrect> </wsrm:sequenceacknowledgementresponse> Side 14 af 20

15 2.5 Web Service Header elementer De web services, der kræver WS-RM, benytter en række SoapHeader blokke, der benyttes til at formidle information relateret til WS-RM sekvensen SequenceRequest SequenceRequest header elementet skal sendes med i Soap Headeren til services, der kræver WS- ReliableMessaging Xml eksempel: <wsrm:sequencerequest> <wsrm:identifier>.. </wsrm:identifier> </wsrm:sequencerequest> SequenceResponse SequenceResponse header elementet sendes af de services, der er den del af WS-ReliableMessaging sekvensen. Header elementet indeholder information om det messagenumber, der skal benyttes til Acknowledgement meddelelsen. Identifier-elementet og Messagenumber-elementet skal benyttes, når Acknowledgement meddelelsen skal sendes retur til WSRM servicen. Xml eksempel: <wsrm:sequenceresponse> <wsrm:identifier>.. </wsrm:identifier> <wsrm:messagenumber>.. </wsrm:messagenumber> </wsrm:sequenceresponse> AckRequested AckRequested header elementet sendes af de services, der er den del af WS-ReliableMessaging sekvensen. Elementet fortæller serviceaftageren, at der skal sendes en Acknowledgement for modtagelsen af meddelelsen, så snart meddelelsen er modtaget. Xml eksempel: <wsrm:ackrequested> <wsrm:identifier>.. </wsrm:identifier>.. </wsrm:ackrequested> WS-RM Policy Følgende beskriver WS-RM policyen for alle de services der benytter WSRM. Max Antal gensendelser: 3 Det maksimale antal accepterede gensendelser er 3, hvis der herefter ikke er modtaget en Ack, termineres sekvensen. Der skal sendes en Acknowledgement for alle beskeder Der skal sendes en Acknowledgement for alle beskeder i en sequence før WSRM sekvensen kan afsluttes. Side 15 af 20

16 Alle beskeder i WSRM service inventory skal hentes Alle beskeder i WSRM service inventory beskeden skal hentes af aftageren, det er ikke muligt at afslutte en sequence, hvor ikke alle beskeder er hentet. Side 16 af 20

17 3 Sikkerhed Følgende afsnit beskriver de overordnede informationer i forhold til sikkerhed og de i dette dokument beskrevne web services. 3.1 Krav til web service aftagerne Web service aftageren skal etablere og opretholde fornødne sikkerhedsmæssige tiltag til sikring af, at meddelelser, der udveksles via Webservices, ikke kommer til uvedkommendes kendskab, forvanskes eller går til grunde. Det er web service aftagernes eget ansvar at sikre, at dennes IT-systemer er konfigureret og eventuelt tilrettet i nødvendigt omfang til at kunne få adgang til de i dette dokument beskrevne Web services. Ligeledes er web service aftagernes ansvar at sikre, at der er knyttet forsvarlige sikkerhedsforanstaltninger til de applikationer og systemer, denne benytter for at kunne anvende de i dette dokument beskrevne Webservices. Yderligere specifikation af de krav der stilles til web service aftageren findes i tilslutningsaftalen for de i dette dokument beskrevne services. 3.2 Policy og sikkerhedsmodeller. Sikkerheden i de udarbejdede web services er baseret på brugen af OCES-certifikater og understøtter en sikkerhedsmodel Sik 3 baseret på funktionscertifikater. Som udgangspunkt benyttes http med SOAP sikret med WS-Security (meddelsesbaseret sikkerhed), men for de A-kasser eller leverandører der ikke har mulighed for at anvende WS-Security tilbydes adgang til TLS via https (transportbaseret sikkerhed). 3.3 Certifikatkommunikation Generelt baserer datakommunikation, der er sikret med certifikater, sig på, at både afsender og modtager har et certifikat og at hvert certifikat består af en privat og en offentlig del. Den private del udleveres aldrig til andre, den offentlige del udleveres til parter, man ønsker at kommunikere sikkert med. AMS stiller et certifikat til rådighed pr. miljø (udviklingstestmiljø, produktionsmiljø), aftager ønsker at kommunikere sikkert med. Aftager skal tilsvarende anskaffe sig et mindst et OCES-certifikat via DanID ( 1. I langt de fleste tilfælde vil en aftager have en lokal certifikatadministrator (LRA) som kan udstede certifikater på vegne af DanID. For alle certifikater, uanset typen, gælder at de skal være udstedt under samme CVR-nummer som oplyst i tilslutningsaftalen med AMS. Der skal bestilles et funktionscertifikat pr. a-kasse, der skal have adgang; dvs. en a-kasse skal bruge netop et funktionscertifikat. A-kasse-leverandører med flere a-kasser på samme a-kasse system skal således også bruge et funktionscertifikat pr. a-kasse. 1 Til testopkobling kan systemforvalter på vegne af AMS udstede et midlertidigt certifikat til aftager. Dette kan dog udelukkende bruges til test. Side 17 af 20

18 Forudsætningen for kunne anvende de bestilte certifikater i forbindelse med adgang til Arbejdsmarkedsportalens webservices er: Aftager skal have etableret tilslutningsaftale med AMS. Aftager skal have godkendt samtlige certifikater hos AMS. Dette sker ved fremsendelse (pr ) af de offentlige dele af certifikaterne til systemforvalter. Hvis der udelukkende er tale om medarbejdercertifikater kan godkendelsen også ske ved at forsøge pålogning på Aftager skal bruge: Et eller flere funktionscertifikater idet der som minimum skal anvendes et funktionscertifikat pr aftagende system(f 1 F n ) Arbejdsmarkedsstyrelsens offentlige servercertifikat til det miljø, hvorfra der skal aftages webservices, f.eks. service.bm.dk (AMS 1 ) Aftager skal: Importere/installere (AMS 1 ) i sit lokale Certificate Store, så det kan ses af det system, der skal foretage forespørgslen. Kryptere sin forespørgsel med (AMS 1 ) Signere sin forespørgsel med den private del af (F x ) Afsende sin forespørgsel mod det pågældende miljø og webservice. Aftager vil modtage et svar: Krypteret med (F x ) Signeret med (AMS 1 ) Aftager skal dekryptere svaret med den private del af F x Ved anvendelse af funktionscertifikater til webservice kald på vegne af en bruger skal der medsendes et metadataobjekt i SOAP-beskeden, der unikt identificerer, hvilken bruger der har udløst forespørgslen: Metadatamodellen er baseret på følgende oplysninger: User Identifier - Unik bruger identifikation Local User Identifier - Lokal bruger identifikation (optionel) UserName (GivenName, MidleName, SurName) - Bruger navn (baseret på OIO XML navne standarden) User - Bruger adresse (optionelt) Dette vil dog først være muligt fra fase 2. I DFDG vil der blive ført en log over metadataoplysningerne. 3.4 Certifikater under TLS Som udgangspunkt anvendes samme certifikater som beskrevet i det foregående afsnit, Certifikatkommunikation. Forskellen er, at certifikaterne ikke anvendes til kryptering og signering af de enkelte forespørgsler, men i stedet til 1) sikring af en TLS-forbindelse som forespørgsler og svar kan sendes over 2) til logning og autentificering på webservicesiden af aftager. Side 18 af 20

19 Aftager skal: Importere/installere (AMS 1 ) som trusted root certificate, så det kan ses af det system, der skal foretage forespørgslen. Installere aftagers certifikat (F x ) pr. TLS-forbindelse, der skal opsættes. Sende sin forespørgsel i klartekst mod det pågældende miljø og webservice. Aftager vil modtage et svar i klartekst. 3.5 Serviceaftagers forpligtigelser Følgende beskriver de forpligtelser serviceaftageren påtager sig i forbindelse med en hver form for brug af de i dette dokument beskrevne services. Serviceaftageren forpligter sig til følgende: Serviceaftageren er forpligtet til at logge de kvitteringer der returneres af servicen. Loggen skal opbevares i 6 måneder hvorefter den skal slettes. Ved anvendelsen af metadatamodellen er det aftager systemet der er ansvarlig for authentication og authorisation af den enkelte bruger, samt at sikre at den enkelte bruger alene kan tilgå data i henhold til kravene i persondata-loven. Serviceaftageren forpligter sig til at logge alle SOAP faults incl. fejl koden som en del af deres fejl log. 3.6 Kodelister Mange af webservicekaldene anvender lister, det kan være jobcentre, a-kasser, klientkategori eller lign., som en del af request eller response parametrene. For ikke at skulle opdatere WSDL grænsefladen hver gang, der ændres i disse lister, er der oprettet en række kodelister med disse værdier som udbydes parallelt med de services, der anvender dem. Kodelisterne er etableret som selvstændige services, som de aftagende systemer skal kalde for at hente gældende kodelister for enkelte værdier. Kodelisterne skal max. hentes en gang i døgnet, og skal derfor ikke kaldes i forbindelse med hver request til en service. Det er serviceaftagers ansvar til en hver tid at anvende de aktuelle kodelister. Ændringer i kodelister varles i hh. varslingsfrister i webserviceaftalerne. Det er aftagerapplikationens opgave at udstille kodelisterne til brugerne på en sigende måde. Det kan således ikke i alle tilfælde anbefales at benytte beskrivelserne direkte i aftagerapplikationerne i forbindelse med indberetninger, da beskrivelserne kan indeholde referencer til felter i webservicebeskeden, som ikke modsvarer en semantik eller begrebsmodel, der giver mening for brugeren af den enkelte applikation. Det tilstræbes dog at kolonnen Name i kodelisten udtrykker et for brugeren sigende navn for kodeværdien. Der er start- og slutdatoer for alle kodeværdier. Der må kun registreres kodeværdier, der er aktuelle - det vil sige, hvor slutdatoen er mindre end dags dato. Hvis slutdatoen er overskredet skal værdien kun bruges ved læsning af gamle værdier og eventuelle opdateringer af forhold der allerede eksisterer. Kodelisterne er opbygget efter en fælles struktur: Element Beskrivelse Identifier Identifier elementet der angiver den id der skal benyttes til servicen for dette Side 19 af 20

20 kode liste element. Type: int Name Description StartDate EndDate Et sigende navn for kodeværdien. Min. Length: 1 Max. Length: 100 Type: string En kort beskrivelse af kodes betydning Min. Length: 1 Max. Length: 500 Type: string Dato fra hvornår kodeværdien gælder Format: xsd:datetime Dato for hvornår kodeværdien udløber Format: xsd:datetime Side 20 af 20

21

22

23