Most recent edit on 2007-09-02 17:15:18 by KristianHjortMadsen
Deletions:
5 Anbefalinger til mønstre for udvikling af portalservices
Bilag 3 Retningslinier vedrørende integrationsformen WSRP
Edited on 2007-09-02 14:17:29 by KristianHjortMadsen
No differences.
Edited on 2007-09-02 14:17:08 by KristianHjortMadsen
No differences.
Edited on 2007-09-02 14:15:58 by KristianHjortMadsen
Additions:
- Digital dokumentboks. Det anbefales, at portalservices, der skal afgive skriftlig kvittering til brugeren, gør dette ved at generere en PDF-kvittering baseret på fælles skabeloner, som er under udvikling. Kvitteringen gemmes via direkte kommunikation med en fælleskomponent ”Digital dokumentboks”, hvor brugeren kan få adgang til kvitteringen.
- Brug af digital signatur. Når der er behov for at en bruger, med samme vægt som tillægges en papirbaseret personlig underskrift, skal godkende et elektronisk dokument, kan dette håndteres med digitale signaturer. En signatur laves med et digitalt certifikat, for Det Offentlige Danmarks vedkommende, OCES certifikater.
Deletions:
- Digital dokumentboks. Det anbefales, at portalservices, der skal afgive skriftlig kvittering til brugeren, gør dette ved at generere en PDF-kvittering baseret på fælles skabeloner, som er under udvikling. Kvitteringen gemmes via direkte kommunikation med en fælleskomponent ”Digital dokumentboks”, hvor brugeren kan få adgang til kvitteringen.
Brug af digital signatur. Når der er behov for at en bruger, med samme vægt som tillægges en papirbaseret personlig underskrift, skal godkende et elektronisk dokument, kan dette håndteres med digitale signaturer. En signatur laves med et digitalt certifikat, for Det Offentlige Danmarks vedkommende, OCES certifikater.
Edited on 2007-09-02 14:15:06 by KristianHjortMadsen
Additions:
Brug af digital signatur. Når der er behov for at en bruger, med samme vægt som tillægges en papirbaseret personlig underskrift, skal godkende et elektronisk dokument, kan dette håndteres med digitale signaturer. En signatur laves med et digitalt certifikat, for Det Offentlige Danmarks vedkommende, OCES certifikater.
Deletions:
Brug af digital signatur. Når der er behov for at en bruger, med samme vægt som tillægges en papirbaseret personlig underskrift, skal godkende et elektronisk dokument, kan dette håndteres med digitale signaturer. En signatur laves med et digitalt certifikat, for Det Offentlige Danmarks vedkommende, OCES certifikater.
Edited on 2007-09-02 14:14:41 by KristianHjortMadsen
Additions:
I processen bliver brugeren præsenteret for det dokument, der skal underskrives af en signeringsservice og skal så tillade denne service adgang til sit digitale certifikat, typisk ved at afgive sit certifikat password. Resultatet er en digital signatur, som efterfølgende kan gemmes, f.eks. af en notarservice, og senere hentes frem for at godtgøre at personen vitterligt har underskrevet dokumentet på et givet tidspunkt. Denne godtgørelse kendes normalt som ”uafviselighed”. Notarservicen har til formål at sikre, at signaturen blev lavet med et gyldigt certifikat, hvornår underskriften blev lavet, og i det hele taget garantere signaturens ægthed på underskriftstidspunktet.
VIRK Virksomhedsportalen udstiller en signeringsservice, som en serviceudbyder kan integrere til for at få dannet signaturer på egne dokumenter (se [VIRKBRS] s. 22 ff). Virk.dk stiller ikke nogen notarservice til rådighed, men overlader denne opgave til den enkelte serviceudbyder.
BORGER Borgerportalen udstiller ikke en signeringsservice.
OIM giver ingen generelle retningslinjer for hvordan en digital signatur oprettes.
Deletions:
I processen bliver brugeren præsenteret for det dokument, der skal underskrives af en signeringsservice og skal så tillade denne service adgang til sit digitale certifikat, typisk ved at afgive sit certifikat password. Resultatet er en digital signatur, som efterfølgende kan gemmes, f.eks. af en notarservice, og senere hentes frem for at godtgøre at personen vitterligt har underskrevet dokumentet på et givet tidspunkt. Denne godtgørelse kendes normalt som ”uafviselighed”. Notarservicen har til formål at sikre, at signaturen blev lavet med et gyldigt certifikat, hvornår underskriften blev lavet, og i det hele taget garantere signaturens ægthed på underskriftstidspunktet.
VIRK Virksomhedsportalen udstiller en signeringsservice, som en serviceudbyder kan integrere til for at få dannet signaturer på egne dokumenter (se [VIRKBRS] s. 22 ff). Virk.dk stiller ikke nogen notarservice til rådighed, men overlader denne opgave til den enkelte serviceudbyder.
BORGER Borgerportalen udstiller ikke en signeringsservice.
OIM giver ingen generelle retningslinjer for hvordan en digital signatur oprettes.
Edited on 2007-09-02 14:13:13 by KristianHjortMadsen
Additions:
4 Anbefalinger til mønstre for udvikling af portalservices
4 Anbefalinger til mønstre for udvikling af portalservices<- du er her!
Nedenfor opremses en række emner uden for rammerne af version 1.0 af integrationsmodellen, som er opsamlet under udarbejdelsen af integrationsmodellen. Fremtidige versioner af integrationsmodellen kan eventuelt inkludere og uddybe sådanne emner med anbefalinger og retningslinier. Emnerne kan dog allerede på nuværende tidspunkt have serviceudbydernes interesse i forbindelse med deres udvikling af portalservices, hvorfor de kort nævnes her. Yderligere information må søges hos andre kilder.
Som eksempel på et mønster kan nævnes opsamling af statistikoplysninger. Der forventes i regi af Den Digitale Taskforce udarbejdet fælles metode og retningslinier for hvordan portalservices afleverer besked om, at en bruger har gennemført den funktion, som portalservicen stiller til rådighed. Disse retningslinier kan understøttes af en fælles komponent, der kan anvendes direkte i serviceudbydernes løsninger.
- Et væsentligt emne er udvikling og anvendelse af fælleskomponenter. Det er god praksis at udvikle fælles løsninger på fælles opgaver, og så integrere til disse fælleskomponenter fra andre portalservices.
- Sådanne fælleskomponenter betragtes i integrationsmodellen på lige fod med myndighedernes øvrige portalservices, såfremt de skal udstilles på en af portalerne. Det er således uden for integrationsmodellens emneområde at give særskilte retningslinier for udvikling af - og integration med - disse fælleskomponenter. For at fremme god praksis nævnes her eksempler på sådanne fælleskomponenter, som er undervejs.
- Digital dokumentboks. Det anbefales, at portalservices, der skal afgive skriftlig kvittering til brugeren, gør dette ved at generere en PDF-kvittering baseret på fælles skabeloner, som er under udvikling. Kvitteringen gemmes via direkte kommunikation med en fælleskomponent ”Digital dokumentboks”, hvor brugeren kan få adgang til kvitteringen.
Brug af digital signatur. Når der er behov for at en bruger, med samme vægt som tillægges en papirbaseret personlig underskrift, skal godkende et elektronisk dokument, kan dette håndteres med digitale signaturer. En signatur laves med et digitalt certifikat, for Det Offentlige Danmarks vedkommende, OCES certifikater.
I processen bliver brugeren præsenteret for det dokument, der skal underskrives af en signeringsservice og skal så tillade denne service adgang til sit digitale certifikat, typisk ved at afgive sit certifikat password. Resultatet er en digital signatur, som efterfølgende kan gemmes, f.eks. af en notarservice, og senere hentes frem for at godtgøre at personen vitterligt har underskrevet dokumentet på et givet tidspunkt. Denne godtgørelse kendes normalt som ”uafviselighed”. Notarservicen har til formål at sikre, at signaturen blev lavet med et gyldigt certifikat, hvornår underskriften blev lavet, og i det hele taget garantere signaturens ægthed på underskriftstidspunktet.
VIRK Virksomhedsportalen udstiller en signeringsservice, som en serviceudbyder kan integrere til for at få dannet signaturer på egne dokumenter (se [VIRKBRS] s. 22 ff). Virk.dk stiller ikke nogen notarservice til rådighed, men overlader denne opgave til den enkelte serviceudbyder.
BORGER Borgerportalen udstiller ikke en signeringsservice.
OIM giver ingen generelle retningslinjer for hvordan en digital signatur oprettes.
Deletions:
4 Overordnede retningslinier for integration af portalservices
Introduktion
Sikkerhed
Visuelt design og navigation
Portalkontekst
SLA skabelon
4 Overordnede retningslinier for integration af portalservices<- du er her!
I version 1.0 af integrationsmodellen kan der være retningslinier for integration af portalservices i en eller begge portaler, der gælder uanset hvilken integrationsform eller portalservicetype, der vælges.
I bilag 1-3 angives de retningslinier, der er rettet mod hver af de tre integrationsformer Link, Iframe og WSRP. Der vil være variation på tværs af integrationsformer i forhold til hvor specifikke retningslinierne for de enkelte punkter vil være, ligesom udvalgte punkter kan være irrelevante for en given integrationsform. Dette vil blive afklaret i det kommende arbejde frem mod version 1.0, bl.a. gennem dialog med portalejerne.
Sikkerhed
I version 1.0 af integrationsmodellen vil i dette afsnit indgå overordnede retningslinier vedrørende sikkerhed.
Sikkerhedsmæssige aspekter, der antages at blive håndteret af de enkelte portalservices eller tværgående løsninger (fx E&S’ bruger/rettighedssystem i virksomhedsportalen) - og dermed at ligge udenfor integrationsmodellen - inkluderer:
Brugeradministration og rolleopsætning
Autorisation til dele af funktionaliteten og/eller dataudsnit i en portalservice
Visuelt design og navigation
I version 1.0 af integrationsmodellen vil i dette afsnit indgå overordnede retningslinier vedrørende visuelt design og navigation.
Portalkontekst
I version 1.0 af integrationsmodellen vil i dette afsnit indgå overordnede retningslinier vedrørende portalkontekst.
SLA skabelon
Der udarbejdes til version 1.0 af integrationsmodellen en skabelon, som portalejerne kan anvende til at fastlægges specifikke SLA’er for de portalservices, som serviceudbyderne udstiller i de to portaler. Det vides pt. ikke i hvilket omfang portalejerne udarbejder specifikke SLA’er. Følgende emner vil indgå i skabelonen:
- Beskrivelse af portalservice.
En kort beskrivelse af portalportalservicen med særligt fokus på den eller de funktioner, som portalservicen stiller til rådighed for en slutbruger.
- Kritisk funktionalitet.
Angivelse af den eller de funktioner, som er kritiske for, at portalservicen er aktiv, set fra en slutbrugers synspunkt. Der peges på udvalgte eller alle funktioner i portalservicen, som skal være aktive, for, at portalservicen betragtes som aktiv.
- Afhængigheder til andre.
Angivelse af funktioner i portalen, fælleskomponenter (fx IdP) og andre portalservices, som portalservicen er afhængig af for at kunne leve op til SLA kravene.
- Grænseflader.
Angivelse af øvrige funktioner i portalen, fælleskomponenter (fx IdP) og andre portalservices, som portalservicen har grænseflader til, men ikke er afhængig af for at kunne leve op til SLA kravene.
- Planlagt nedetid / servicevinduer.
Angivelse af tidsintervaller hvor planlagt nedetid kan forekomme, omfanget af planlagt nedetid og varsler i forbindelse med planlagt nedetid.
- Oppetid.
Angivelse af kriterier for, at en portalservice anses for at være aktiv (”oppe”), fx at portalservicen skal svare inden for en fastsat periode ved brugerinteraktioner samt metode for beregning af oppetid/tilgængelighed og angivelse af acceptable oppetider.
- Svartid.
Angivelse af metode for måling af svartid samt acceptabel svartid og den procentvise andel af brugerinteraktioner, som skal overholde svartidskravet. Endvidere angives tidsgrænse for hvornår en funktion anses for ikke at være tilgængelig.
- Mængder.
Angivelse af hvor mange gennemførte gennemløb af en funktion i portalservicen, som portalservicen skal kunne levere pr. dag.
- Skalerbarhed.
Angivelse af i hvilket omfang kravene til tilgængelighed, svartid og mængder kan skaleres i forhold til udviklingen i anvendelsen over tid. Der kan fx være tale om en portalservice, hvor det forventes at brugergruppen udvides løbende.
- Backup og genetablering.
Angivelse af hvor hurtigt portalservicen og tilhørende data skal kunne genetableres efter at portalservicen har været inaktiv.
- Overvågning.
Angivelse af hvordan overholdelse af SLA-kravene overvåges.
- Rapportering.
Angivelse af hvordan rapportering vedrørende overvågning af SLA-krav foretages.
- Organisation (support mv.).
Angivelse af de kontaktpunkter og deres åbningstider, som serviceudbyder og portalejer stiller til rådighed.
Edited on 2007-06-06 04:49:42 by WebMaster
Additions:
4 Overordnede retningslinier for integration af portalservices
2 Introduktion
3 Processer omkring integration af en portalservice i portalerne
4 Overordnede retningslinier for integration af portalservices<- du er her!
5 Anbefalinger til mønstre for udvikling af portalservices
Deletions:
3 Overordnede retningslinier for integration af portalservices
2 Processer omkring integration af en portalservice i portalerne
3 Overordnede retningslinier for integration af portalservices<- du er her!
4 Anbefalinger til mønstre for udvikling af portalservices
Edited on 2007-06-03 17:19:10 by WebMaster
Additions:
Indhold
Edited on 2007-05-30 17:46:16 by WebMaster
Additions:
3 Overordnede retningslinier for integration af portalservices
Deletions:
Overordnede retningslinier for integration af portalservices
Edited on 2007-05-30 17:44:26 by WebMaster
No differences.
Edited on 2007-05-30 17:39:50 by WebMaster
Additions:
Overordnede retningslinier for integration af portalservices
SLA skabelon
OIM Oversigt
Deletions:
Overordnede retningslinier for integration af portalservices
SLA skabelon
Edited on 2007-05-30 05:23:44 by WebMaster
Additions:
Den Offentlige Integrationsmodel, OIM
Deletions:
Overordnede retningslinier for integration af portalservices
Oldest known version of this page was edited on 2007-05-30 05:17:26 by WebMaster []
Page view:
Overordnede retningslinier for integration af portalservices
I version 1.0 af integrationsmodellen kan der være retningslinier for integration af portalservices i en eller begge portaler, der gælder uanset hvilken integrationsform eller portalservicetype, der vælges.
I bilag 1-3 angives de retningslinier, der er rettet mod hver af de tre integrationsformer Link, Iframe og WSRP. Der vil være variation på tværs af integrationsformer i forhold til hvor specifikke retningslinierne for de enkelte punkter vil være, ligesom udvalgte punkter kan være irrelevante for en given integrationsform. Dette vil blive afklaret i det kommende arbejde frem mod version 1.0, bl.a. gennem dialog med portalejerne.
Sikkerhed
I version 1.0 af integrationsmodellen vil i dette afsnit indgå overordnede retningslinier vedrørende sikkerhed.
Sikkerhedsmæssige aspekter, der antages at blive håndteret af de enkelte portalservices eller tværgående løsninger (fx E&S’ bruger/rettighedssystem i virksomhedsportalen) - og dermed at ligge udenfor integrationsmodellen - inkluderer:
Brugeradministration og rolleopsætning
Autorisation til dele af funktionaliteten og/eller dataudsnit i en portalservice
Visuelt design og navigation
I version 1.0 af integrationsmodellen vil i dette afsnit indgå overordnede retningslinier vedrørende visuelt design og navigation.
Portalkontekst
I version 1.0 af integrationsmodellen vil i dette afsnit indgå overordnede retningslinier vedrørende portalkontekst.
SLA skabelon
Der udarbejdes til version 1.0 af integrationsmodellen en skabelon, som portalejerne kan anvende til at fastlægges specifikke SLA’er for de portalservices, som serviceudbyderne udstiller i de to portaler. Det vides pt. ikke i hvilket omfang portalejerne udarbejder specifikke SLA’er. Følgende emner vil indgå i skabelonen:
- Beskrivelse af portalservice.
En kort beskrivelse af portalportalservicen med særligt fokus på den eller de funktioner, som portalservicen stiller til rådighed for en slutbruger.
- Kritisk funktionalitet.
Angivelse af den eller de funktioner, som er kritiske for, at portalservicen er aktiv, set fra en slutbrugers synspunkt. Der peges på udvalgte eller alle funktioner i portalservicen, som skal være aktive, for, at portalservicen betragtes som aktiv.
- Afhængigheder til andre.
Angivelse af funktioner i portalen, fælleskomponenter (fx IdP) og andre portalservices, som portalservicen er afhængig af for at kunne leve op til SLA kravene.
- Grænseflader.
Angivelse af øvrige funktioner i portalen, fælleskomponenter (fx IdP) og andre portalservices, som portalservicen har grænseflader til, men ikke er afhængig af for at kunne leve op til SLA kravene.
- Planlagt nedetid / servicevinduer.
Angivelse af tidsintervaller hvor planlagt nedetid kan forekomme, omfanget af planlagt nedetid og varsler i forbindelse med planlagt nedetid.
- Oppetid.
Angivelse af kriterier for, at en portalservice anses for at være aktiv (”oppe”), fx at portalservicen skal svare inden for en fastsat periode ved brugerinteraktioner samt metode for beregning af oppetid/tilgængelighed og angivelse af acceptable oppetider.
- Svartid.
Angivelse af metode for måling af svartid samt acceptabel svartid og den procentvise andel af brugerinteraktioner, som skal overholde svartidskravet. Endvidere angives tidsgrænse for hvornår en funktion anses for ikke at være tilgængelig.
- Mængder.
Angivelse af hvor mange gennemførte gennemløb af en funktion i portalservicen, som portalservicen skal kunne levere pr. dag.
- Skalerbarhed.
Angivelse af i hvilket omfang kravene til tilgængelighed, svartid og mængder kan skaleres i forhold til udviklingen i anvendelsen over tid. Der kan fx være tale om en portalservice, hvor det forventes at brugergruppen udvides løbende.
- Backup og genetablering.
Angivelse af hvor hurtigt portalservicen og tilhørende data skal kunne genetableres efter at portalservicen har været inaktiv.
- Overvågning.
Angivelse af hvordan overholdelse af SLA-kravene overvåges.
- Rapportering.
Angivelse af hvordan rapportering vedrørende overvågning af SLA-krav foretages.
- Organisation (support mv.).
Angivelse af de kontaktpunkter og deres åbningstider, som serviceudbyder og portalejer stiller til rådighed.