FESD Brugeradministration

Størrelse: px
Starte visningen fra side:

Download "FESD Brugeradministration"

Transkript

1 FESD Brugeradministration Standard IT- og Telestyrelsen København den 10. december 2008 FESD standardisering Brugeradministration. Datamodel Version 1.1

2 Kolofon: FESD standardisering. Brugeradministration. Datamodel.Version 1.1 Denne standard kan frit anvendes af alle. Citeres der fra standarden i andre publikationer til offentligheden, skal der angives korrekt kildehenvisning. Forslag til FESD-standarder udarbejdes af IT- og Telestyrelsen, Kontoret for standardiserings- og arkitekturpolitik, FESD-standardiseringsgruppen i samarbejde med de tre FESD leverandører Software Innovation A/S, Traen Informationssystemer A/S og CSC Danmark A/S. Kontaktperson i FESD-standardisering: Projektleder Rita Lützhøft, Mail-adresse Telefon (direkte) Traen Informationssystemer A/S Vesterbrogade 95 A 1620 København K Telefon: Web-adresse: CSC Danmark A/S Retortvej København V Telefon: Web-adresse: Software Innovation A/S Nærum Hovedgade Nærum Telefon: Web-adresse: Ministeriet for Videnskab, Teknologi og Udvikling IT- og Telestyrelsen Kontoret for standardiserings- og arkitekturpolitik Holsteinsgade 63 DK-2100 København Ø Telefon: Fax / 21

3 Indholdsfortegnelse 1 Forord Teknisk forord Del A Business Case for Brugeradministrations-model Baggrund Negative konsekvenser af fravær af fælles brugerstyring Mål for modellen Formålsbeskrivelse for brugeradministrationsmodellen NOARK4 kontra FESD Afgrænsning Del B Beskrivelse af FESD-brugeradministrationsmodel Indledning Forskelle mellem NOARK og FESD Brugeradministration Beskrivelse af klasser Bruger Sikkerhedsklassifikation Adgangsgruppe OrganisatoriskEnhed Rolle og Rettighed JournalPost Sag Del C LDAP integration Bruger OrganisatoriskEnhed Adgangsgruppe Rolle Anvendte typer i FESD-modellerne / 21

4 Forord Den offentlige sektors IT-systemer på statsligt, kommunalt og regionalt niveau skal kunne spille sikkert og effektivt sammen. Derfor arbejdes der målrettet på at få gennemført fælles standarder for elektronisk sags- og dokumenthåndtering - den såkaldte FESD-standard. Målet med standardiseringsarbejdet er at fremme digital forvaltning i den offentlige sektor, og midlet er at sikre, at de forskellige elektroniske sags- og dokumenthåndteringssystemer (ESDH) får en fælles kernefunktionalitet, og at det samtidig sikres, at denne kerne videreudvikles ensartet. En fælles kernefunktionalitet skal sikre: at der kan foretages sagsbehandling på tværs af flere organisationer at myndigheder, der arbejder med åbne sager, kan lægges sammen at der kan flyttes opgaver mellem forskellige myndigheder I forlængelse af FESD-projektkonkurrencen, som havde sin afslutning primo 2004, og hvor der blev fundet tre FESD-leverandører, blev det i forbindelse med kontraktforhandlingerne besluttet at starte en standardiseringsproces den såkaldte FESD-standardisering. For at sikre interoperabiliteten, både til andre systemer, men også så tredjepart kan udvikle moduler til systemet, blev det anset for afgørende, at der udvikles en fælles offentlig datamodel samt andre standarder på ESDH-området. Koordinering af FESD-standardiseringen er efterfølgende lagt i IT- og Telestyrelsen (ITST). Den konkrete udarbejdelse af forslag/udkast til standarder foregår i et samarbejde mellem de tre FESD-leverandører og en FESD-standardiseringsgruppe i ITST. Arbejdet med forslag/udkast til standarder tager udgangspunkt i Noark 4 s datamodel og databeskrivelser samt leverandørernes løsninger. Standarderne kan afvige fra Noark 4 på de områder, hvor det er nødvendigt for at understøtte dansk forvaltningspraksis, eller hvor parterne i FESD-standardiseringen kan opnå enighed om en afvigelse. Udkast/forslag sendes herefter i offentlig høring i ca. 1 måned. FESD-standardiseringsgruppen tilretter og færdiggør på baggrund af høringen de endelige Forslag til standarder. Standardforslagene forelægges herefter OIO-komiteen til godkendelse. Efter den samlede godkendelse bliver standarderne således offentliggjort og indgår i IT- og Telestyrelsens nye OIO-Katalog (digitaliser.dk), som indeholder en oversigt over godkendte og anbefalede standarder til digital forvaltning i det offentlige. I standarden kan forekomme brug af særligt ordvalg. Følgende termer anvendes konsekvent i den følgende betydning: skal / obligatorisk : betyder, at den nævnte metode/element/mulighed/etc. skal benyttes eller skal forefindes dvs. må ikke udelades. må ikke : betyder, at den nævnte metode/element/mulighed/etc. ikke må forefindes eller må ikke benyttes. bør / anbefalet : betyder, at det i høj grad anbefales, at den nævnte metode/element/mulighed/etc. benyttes eller forefindes. Der skal være tungtvejende grunde til at udelade. kan / optionel : betyder, at den nævnte metode/element/mulighed/etc. er en valgmulighed og derfor valgfri at medtage. Denne udgave af standarden er såkaldt konsolideret i forhold til version 1.0. På grund af den måde FESDstandardiseringsarbejdet er tilrettelagt på forskellige afleveringer på forskellige tidspunkter siden 2004 udkommer FESD-datamodellen som deldatamodeller. Det har betydet, at enkelte detaljer i det forventede slutresultat altså den samlede FESD-datamodel kan være overset. Det har endvidere været nødvendigt at konsekvenstilføje noget, der tidligere er sprunget over fx på grund af manglende standardisering på det tidspunkt, den aktuelle standard blev udarbejdet. Endvidere har NDR (Name and Design Rules) reglerne givet anledning til en del ændringer i sprogbrug (semantik) vedrørende attributter af hensyn til efterfølgende generering af 4 / 21

5 XML Den samlede FESD-datamodel (i form af deldatamodellerne) til og med 2008 er derfor gennemgået og genvurderet i forbindelse med denne standard. Denne genvurdering har ikke medført forretningsmæssige radikale ændringer i deldatamodellen, men har dog givet anledning til en del justeringer, typisk af præsentationsmæssig (semantik) karakter, især pga. NDR-reglerne. Den samlede FESD datamodel udgøres af FESD standarderne Sager og dokumenter, Brugeradministration, Udvalgsbehandling, Arkivstruktur, Emnesystematik, Navn- og adressemodel. 1.1 Teknisk forord Grundlaget for FESD-datamodellen er blevet udarbejdet på en periode på mere end fire år, hvor der er udarbejdet standarder for de forskellige delområder. Arbejdsmetoder, terminologi og anvendelse af datatyper har ændret sig i denne periode FESD-standardiseringsgruppen har f.eks. indført en konsekvent brug af UMLnotation i de senere standarder. Konsolideringen af datamodellen har derfor forudsat, at der blev defineret en fælles modelleringsmetode og et sæt af primitive datatyper, der var kompatibelt med alle deldatamodellerne. De primitive datatyper, som modellen er opbygget af, fremgår af kapitel 5. 5 / 21

6 2 Del A Business Case for Brugeradministrations-model Dette forslag til standard beskriver forholdet mellem brugeradministration i ESDH-systemer og i eksterne brugerstyringssystemer. Standarden anvender de anbefalinger der er i referencemodel for brugerstyring (Se 2.1 Baggrund En central barriere i forbindelse med skabelsen af en sammenhængende it-arkitektur for digitale offentlige løsninger i Danmark er fraværet af ensartet brugerstyring. Brugerstyring handler bl.a. om, hvorledes brugere identificeres, hvilke rettigheder de skal have, og hvorledes der sikres sporbarhed i forhold til brugernes handlinger samt den nødvendige bagvedliggende administration. I ældre it-løsninger har brugerstyring normalt været en integreret del af løsningen, hvilket har betydet, at for hver ny løsning kom der en ny måde at håndtere brugere på. I nye it-løsninger er brugerstyring som regel eksternaliseret, således at denne funktionalitet kan varetages af en fælles brugerstyringsløsning. 2.2 Negative konsekvenser af fravær af fælles brugerstyring Fravær af en fælles brugerstyringsløsning har en række konsekvenser mht. økonomi, brugeroplevelse, sværere indførsel af nye løsninger mm. Her gives en række eksempler: Organisationer med en række silo-baserede løsninger 1, som har hver deres måde at håndtere brugerstyring på, har højere administrative it-udgifter i forhold til en tilsvarende løsningsportefølje, hvor fælles brugerstyring anvendes. Eksempelvis bruger Helpdesk i sådanne organisationer ofte en meget stor del af deres tid på at resette brugernes kodeord fordi hvert system har sit eget kodeord og sin egen frekvens for, hvornår der skal skiftes kodeord etc. Hvis fælles brugerstyring skal etableres mellem flere organisationer, skal der være samme tillid til de andre organisationer som til egen organisation. Der er i dag ingen mekanismer til etablering af sådan tillid mellem organisationer. Yderligere er der også bekymring for, om der kan ske krænkelser af privatlivet fred, hvis der eksempelvis implementeres løsninger, således at borgerne kun skal afgive data én gang, hvorefter de stilles til rådighed for flere myndigheder. Der skal sikres, at de forskellige brugere kun anvender data i den kontekst, der er relevant og tilladt ifølge den administrative lovgivning for deres opgave. 2.3 Mål for modellen Grundlaget for FESD er en række visioner, der blandt andet er kommet til udtryk i de krav, der indgår i de indgåede rammekontrakter: 1. Danne grundlaget for større kvalitet og effektiv borgerservice. 2. Fjerne afhængigheden af papir i sagsbehandlingen. 3. Understøtte samarbejde og omstrukturering mellem myndigheder 4. Skabe en fælles kernefunktionalitet for ESDH-systemer og sikre en ensartet videreudvikling af kernen. 5. Sikre udvikling ifølge fællesoffentliges retningslinier for anvendelse af IT 6. Sammenlægning af myndigheder med åbne sager. 7. Flytning af udvalgte opgaver mellem myndigheder. 1 Silo-baserede løsninger: I denne sammenhæng tænkes der primært på ældre it-løsninger, hvor brugerstyring normalt er en integreret del af løsningen, hvilket betyder, at der for hver løsning er en selvstændig håndtering af brugere. 6 / 21

7 8. Implementere Den virtuelle Forvaltning på udvalgte områder, fx a. Understøtte sagsbehandling på tværs af flere institutioner b. Danne grundlag for videndeling med politikere og borgere c. Muliggøre selvbetjening etc. Alle disse overordnede visioner og pejlemærker skal så endeligt sammenstilles med behovsopgørelsens krav til funktionalitet og arkitektur, herunder specielt overholdelse af lovgivningsmæssige krav i bilag 2 og modularisering i bilag Formålsbeskrivelse for brugeradministrationsmodellen Udarbejdelsen af et åbent grænsesnit på brugeradministrationsområdet skal udover den overordnede vision om effektivisering og behovsopgørelsens bilag 2 kap. 7-9 samt arkitekturprincippet om modularisering, sikre opfyldelsen af vision nummer 3 Understøtte samarbejde og omstrukturering mellem myndigheder. Herudover skal den opfylde den helt overordnede vision om at..indhøste effektiviseringsgevinster.. samt.. lette det daglige arbejde. Nedenstående er behandlingen opdelt i en række punkter i forhold til administration af brugere. Modellen skal baserer sig på fastlagte standarder og anbefalinger, herunder især de tværgående projekt vedr. Brugerstyring og deres anbefalinger af eksempelvis LDAP 3.0 2, SAML samt RBAC 4, og skal derigennem eksempelvis kunne udnytte allerede eksisterende brugerkataloger, som er fælles for flere systemer (Active Directory, Novell Directory). Videre skal: Modellen skal kunne understøtte at organisationen kan opdeles i både tværgående grupper og grupper som del af en traditionel hierarkisk struktur. Modellen skal understøtte rettighedstildelinger til forretningsprocesser, ikke kun til ressourcer. Modellen skal understøtte administration af informationer om brugeren, brugerens organisatoriske tilhørsforhold samt brugerens rettigheder. Modellen skal kunne indgå på tværs af systemer mht. rettighedstildeling Modellen skal gøre det let at administrere mange brugere Modellen understøtter konkret følgende to scenarier: Integration til LDAP 3.0. Således vil ESDH-systemer, som overholder brugeradministrationsstandarden, skulle tilbyde brugeradministration af ESDH-brugere i et eksternt LDAP baseret brugerkatalog. Udveksling af enkeltsag. I det omfang der defineres standarder for udveksling af enkeltsager, vil brugeradministrationsmodellen med definitioner af sikkerhedsklassifikation, adgangsgrupper samt organisatorisk tilhørsforhold kunne understøtte disse sikkerhedsaspekter ved udvekslingen. 2 LDAP Lightweight Directory Access Protocol er en netværksprotokol til at forespørge og modificere directory service, brugerkataloger, over TCP/IP. LDAP kataloget bruger X.500s datamodel. Modellen er opbygget af træer, som indeholder en mænge af navne attributter med værdier. 3 SAML Security Assertion Markup Language (SAML) er en XML standard til udveksling af autenticitet og autorisation data mellem sikre domæner. SAML er standardiseret af OASIS Security Service Technical Committee. Standarden beskæftiger sig med web single sign-on (SSO). Der findes et udkast til en dansk SAML SSO profil (tilgængelig på OIO) 4 RABC I et computersystem er sikker Role-Based Access Control (RBAC) en måde at begrænse system adgang til autoriserede brugere. 7 / 21

8 2.5 NOARK4 kontra FESD Standardiseringen af FESD-datamodellen skal, jf. FESD-kontrakten, tage udgangspunkt i datamodellen for NOARK4, med mindre der er argumenter for afvigelse i den danske forvaltningspraksis, eller leverandørerne i fællesskab kan opnå enighed om afvigelser. På brugerstyringsområdet er der i Danmark udviklet en referencemodel for brugerstyring og et sæt af vejledninger. For at sikre sammenhæng og interoperabilitet i dansk kontekst har FESD-standardiseringen indarbejdet disse anbefalinger. NOARK-modellen beskriver en fast struktur for håndtering af roller og rettigheder. Praksis i danmark er, at der i den offentlige forvaltning opereres med forskellige sæt af roller og rettigheder i de enkelte myndigheder. FESD-standardiseringen har derfor fokuseret på at skabe en mere generel ramme for håndtering af brugeradministration, end den der er beskrevet i NOARK, for at tilgodese den danske praksis. Dette er mere detaljeret beskrevet i kapitel Afgrænsning Modellen understøtter ikke alle aspekter ved udveksling af hele eller dele af en sagsportefølje. Den standard for beskrivelse af roller, rettigheder, sikkerhedsklassifikation samt adgangsgrupper som brugeradministrationsmodellen indeholder, styrer udelukkende visse generelle og modelmæssige aspekter af sikkerheden. Der er således IKKE nogen definition af hvilke roller, rettigheder eller sikkerhedsklassifikationer, der skal tilbydes i et ESDH-system, og disse egenskaber ved sagen kan således ikke overføres direkte fra system til system. Dette problem kan kun løses ved, at myndigheder, som skal udveksle sager og dokumenter, ensarter den konkrete sikkerhedsimplementering. Der skal laves en selvstændig vurdering af vægtningen i DS 484, ligesom håndtering af digitale signaturer ikke er dækket af denne standard. Denne standard håndterer ikke i sig selv federal identity management. De nødvendige mekanismer til at håndterer tværorganisatorisk identitetsudveksling og trust, bør ikke styres med udgangspunkt i ESDH systemet. Ønsker man at etablerer tværorganisatorisk identitetsudveksling og trust bør man basere det på et centralt brugerkatalog, der ligger udenfor ESDH systemet. Standarden behandler udelukkende autorisation i relation til ESDH systemet og ikke autentifikation af brugere. Se nedenstående figur for definition af standardens dækningsområde. 8 / 21

9 9 / 21

10 3 Del B Beskrivelse af FESD-brugeradministrationsmodel 3.1 Indledning Den model, der beskrives i det efterfølgende, skal kunne anvendes i forbindelse med: 1. Oprettelse og vedligeholdelse af medarbejdere. 2. Oprettelse og vedligeholdelse af organisatoriske enheder 3. Styring af tilgang til sager og journalposter For at opfylde punkt 1 skal modellen kunne indeholde data om medarbejderen samt dennes adresse-relaterede data. Til det formål indgår klassen Bruger i modellen. Denne klasse indeholder de mest basale informationer om medarbejderen, mens alle adresse/kontakt-relaterede informationer indeholdes i Adressemodellen, som Bruger-klassen refererer til. For at opfylde punkt 2 indgår klassen OrganisatoriskEnhed i modellen. Denne indeholder kun de allermest nødvendige oplysninger og har referencer til Adressemodellen for resten af de organisatoriske informationer. Grunden til, at der findes en Bruger og en OrganisatoriskEnhed klasse i figur 1 er, at der skal kunne relateres til disse fra andre steder i FESD-datamodellen. Man kunne tænke sig, at man blot refererede fra sagens ansvarlige enhed til Adresse.OrganisatoriskEnhed, men dette ville give mulighed for, at andre organisatoriske enheder, som ikke var en del af systemejerens organisation, kunne blive sagsansvarlige. Det samme gælder for brugeren. Derudover har Bruger klassen også den egenskab, at det kun er brugere, som er oprettet i brugerregistret, der kan logge på systemet. Det sidste punkt omkring tilgangsrettigheder til sager og journalposter håndteres ved klasserne Sikkerhedsklassifikation, Adgangsgruppe og OrganisatoriskEnhed. Disse relateres til hhv. Sag og Journalpost, og kun brugere, der er relateret til minimum samme sæt af disse klasser, kan få tilgang til hhv. sagen eller journalposten. class Bruger Administration Bruger + globalbrugeridentifikator: UUID + Identifikator: UUID + Navn: char(64) + oprettetda to: date + udgaaetdato: date [0..1] Sikkerhedsklassifikation + anvendelsesområdetekst: string [0..1] + betegnelsetekst: string [0..1] + hjemmeltekst: string [0..1] + sikkerhedsklassifikationkode: char(2) + slutdato: date [0..1] + startdato: date 1 Rolle + Navn: char(50) + oprettetdato: date + udgaaetdato: date [0..1] Role Area Journa lpost 0..1 admunit 0..1 organizationalaccess 0..1 AdgangsGruppe + beskrivelsetekst: string [0..1] + kode: char(2) + Navn: char(50) + oprettetda to: date + udgaaetdato: date [0..1] 1..* Retti ghed 1..* 1 OrganisatoriskEnhed organizationalaccess 1 Sag Navn: char(50) + forkortelsenavn: code + identifikator: UUID + navn: char(50) + nedlagtdato: date [0..1] + oprettetda to: date parentunit admunit Figur 1: Oversigt over Brugeradministrationsmodellen 10 / 21

11 3.1.1 Forskelle mellem NOARK og FESD Brugeradministration Generelt Umiddelbart er der forskelle mellem FESD og NOARK i forhold til rettigheder; bl.a. er det tilladt kun at have globale roller i FESD Brugeradministrationsmodellen, hvorimod der i NOARK skal tildeles en administrativ enhed. I det følgende gennemgås de vigtigste afvigelser fra NOARK. Bruger klassen brugerid er char(30) i NOARK i klassen Person. FESD-modellen bruger UUID som nøgler. NOARK har ikke support for UUID. Sikkerhedsklassifikation Vedrørende sikkerhedsklassifikation kan der mappes til TGKODE og TGHJEMMEL. I forhold til brugeren indeholder NOARK godkendt (tabellen PERKLARER) og autoriseret (tabellen PERTGKODE), men tilsvarende findes ikke i brugeradministrationsmodellen. Adgangsgruppe I forhold til adgangsgruppe kan man i Brugeradministration have mange grupper relateret til den samme sag eller journalpost, mens man i NOARK kun kan have en gruppe. Rolle + Rettighed + RolleOmråde Rolle-klassen i NOARK består af en række prædefinerede roller, mens rolle i Brugeradministration er løsere defineret for at kunne håndtere forskelligheder i systemers implementering af roller. Rolleområde kan mappes til PERROLLE klassen, men indeholder ikke arkivinformation. OrganisatoriskEnhed NOARK har ikke en direkte reference fra orgenhed (ADMINDEL) til Journalpost kun gennem afsender/modtager. 3.2 Beskrivelse af klasser Dette afsnit beskriver de grundlæggende klasser i FESD-brugeradministrationsmodellen Bruger Bruger indeholder kun ganske få data. Der er således ingen mulighed for lagring af adresser, telefonnumre, historiske adresser etc. Disse vil normalt blive vedligeholdt enten i det fælles brugerkatalog (LDAP) eller i fx et personalesystem. I forbindelse med udveksling af data mellem myndigheder vil det ikke være nødvendigt at udveksle adresseinformation om brugere, idet en udveksling af brugere kun kommer på tale, når der flyttes hele sagsporteføljer inkl. medarbejdere mellem myndighederne. Dette er typisk tilfældet, når en myndighed slås sammen eller opsplittes. I begge tilfælde vil brugerens stamdata (adresse etc) ejes af det nye fælles brugerkatalog og ikke af ESDH-systemet og vil blive opdateret gennem det system, der ejer data. Dan Eng Type Kardinalitet Beskrivelse navn name char(64) [1] Den samlede længde af brugernavnet må ikke overstige 50 tegn. Brugernavnet er entydigt oprettetdato creationdate date [1] Angiver datoen for brugerens oprettelse. udgaaetdato expireddate date [0..1] Angiver datoen for brugerens ophør. Brugere, som har en ud- 11 / 21

12 Dan globalbrugeridentifikator Eng Type Kardina- Beskrivelse litet gået dato, der er mindre end dags dato, kan ikke logge på systemet. globaluseridentfier UUID [1] Er den unikke nøgle for brugeren på tværs af systemer. Er en del af de danske SAML basisatributter. identifikator user UUID [1] Unik bruger identifikator indenfor ESDH systmet/domænet Relationer Association 0..1 Bruger Sikkerhedsklassifikation Bruger Adgangsgruppe Bruger RolleOmråde Bruger Rolle 1 Bruger 1..* OrganisatoriskEnhed Dan betegnelsetekst Eng Kardinalitet sikkerhedsklassifikationkode classificationshortname char(2) [1] Entydig kort kode for sikkerhedsklassifikationen. classificationdescriptor Type Sikkerhedsklassifikation Klassens instanser omfatter alle de forskellige sikkerhedsklassifikationer, som organisationen opererer med. Det kan være Til Tjenstlig brug, Fortroligt, Personligt etc. Enhver bruger, som må se et dokument, der er klassificeret via en sikkerhedsklassifikation, skal have en relation til den samme instans af klassen Sikkerhedsklassifikation. Beskrivelse string [0..1] En længere beskrivelse af sikkerhedsklassifikationen. Fx Til Tjenstligt brug. startdato startdate date [1] Angiver den dato sikkerhedsklassifikationen er oprettet. slutdato enddate date [0..1] Angiver den dato sikkerhedsklassifikationen ikke mere må bruges. hjemmeltekst legalauthority string [0..1] Her angives navnet på den hjemmel, som sikkerhedsklassifikationen har. Fx Persondataloven 27 stk. 10. anvendelsesområde- Tekst areaofuse string [0..1] En yderligere uddybning og beskrivelse af hvornår man skal 12 / 21

13 Dan Eng Type Kardina- Beskrivelse litet benytte sikkerhedsklassifikationen. En sag eller en journalpost kan have en relation til netop én sikkerhedsklassifikation. Relationer Association 0..1 Bruger Sikkerhedsklassifikation 1 Sikkerhedsklassifikation 0..1 JournalPost 1 Sikkerhedsklassifikation 0..1 Sag Adgangsgruppe En Adgangsgruppe er en gruppe af brugere, som kan gives adgang til en sag eller en journalpost. Hvor Sikkerhedsklassifikation beskriver eksterne klassificeringer (såsom fra persondataloven eller fra Statsministeriets sikkerhedsinstruks), beskriver Adgangsgruppe interne klassificeringer. Typisk brug af en Adgangsgruppe kan være en gruppe af brugere, der har adgang til personalesager. Dan Eng Type Kardinalitet Beskrivelse kode code char(2) [1] Entydig forkortelse af Adgangs- GruppeNavn navn name char(50) [1] Entydigt navn for gruppen beskrivelsetekst descriptor string [0..1] Uddybende beskrivelse af gruppen. oprettetdato creationdate date [1] Angiver den dato tilgangsgruppen er oprettet. udgaaetdato expireddate date [0..1] Angiver den dato tilgangsgruppen ikke mere må bruges. Relationer Association AdgangsGruppe JournalPost AdgangsGruppe Sag Bruger AdgangsGruppe 13 / 21

14 3.2.4 OrganisatoriskEnhed Klassen beskriver organisatoriske enheder i brugerens organisation. OrganisatoriskEnhed benyttes på sag og journalpost på to måder. Dels relaterer de til den ansvarlige enhed for sag og journalposten, og dels relaterer de til sagen og journalposten som de organisatoriske enheder, der har adgang til hhv. sagen og journalposten. Yderligere oplysninger om den organisatoriske enhed registreres i den tilhørende Adresse.OrganisatoriskEnhed. Ydermere kan en Bruger være tilknyttet én eller flere organisatoriske enheder. Dette understøtter både hierarkiske og matrixorganisationer. OrganisatoriskEnhed relaterer også til sig selv for at kunne beskrive organisationshierarkiet. Dan Eng Type Kardinalitet Beskrivelse navn name char(50) [1] Navn på den organisatoriske enhed. identifikator unitidentifier UUID [1] Entyding ID på den organisatoriske enhed, særligt til brug for relationen ModerEnhed (parentunit), der beskriver organisationshierarkiet oprettetdato creationdate date [1] Angiver den dato den organisatoriske enhed er oprettet. forkortelsenavn nedlagtdato expireddate date [0..1] Angiver den dato den organisatoriske enhed ikke mere må bruges. nameshortname- Code code [0..1] Kortform af enhedsnavn Relationer Association OrganisatoriskEnhed Sag 1 OrganisatoriskEnhed 0..1 Sag 0..1 OrganisatoriskEnhed 1 OrganisatoriskEnhed OrganisatoriskEnhed JournalPost 1 OrganisatoriskEnhed 0..1 JournalPost OrganisatoriskEnhed RolleOmråde 1 Bruger 1..* OrganisatoriskEnhed 14 / 21

15 3.2.5 Rolle og Rettighed Klassen Rolle bruges til at samle et antal Rettigheder, således at administrationen af rettigheder til brugere kan administreres lettere. Således kan man tænke sig, at Rollen Sagsbehandler består af et antal rettigheder (bl.a. retten til at oprette sager), og man ved at tilknytte eller fjerne roller fra brugere samlet kan flytte en bruger fra en funktion til en anden. Associationen RolleOmråde begrænser brugerens udøvelse af rollens rettigheder indenfor en organisatorisk enhed. Således kan man være Sagsbehandler i 4. kontor, samtidig med man er Leder i 3. kontor. NB. RolleOmråde er ikke et obligatorisk association, idet det tillades ESDH-systemer udelukkende at have globale roller. De rettigheder, som disse roller kan have, er rettigheder overfor det samlede system. Det er således rettigheder som Opret Sag, Se Sag, Skift Sagsansvarlig osv. Altså rettigheder som ikke knytter sig til specifikke objekter. Denne model omfatter ikke roller med rettigheder til specifikke objekter. Rettighederne er ikke udspecificeret, da de typisk er forskellige fra system til system og fra leverandør til leverandør, samt fra myndighed til myndighed. Dette giver en begrænsning i nytten af at udveksle roller og rettigheder direkte fra system til system, idet der ikke vil kunne angives nogle generiske roller, som alle vil skulle implementere. Desuden vil myndighedsspecfikke roller altid være genstand for en manuel/analytisk konvertering, hvor man i det modtagne system skal finde ud af, om man allerede har roller, som kan benyttes, eller der skal skabes nye roller. Det tværoffentlige brugerstyringsprojekt peger på brugen af RBAC (Role Based Access Control) som en model for modellering af rollebaseret brugerstyring. RBAC er en konceptuel standard, som beskriver en række anbefalinger og principper for brugerstyring den beskriver ikke en konkret implementering, men det kan afgøres, om en given implementering overholder RBAC-standarden eller ej. Løsningsmodellen er forberedt til at kunne rumme dels den nuværende situation, hvor det er den enkelte leverandør/myndighed, der definerer roller/rettigheder, dels en fremtidig løsning, hvor der kan indpasses standardiserede roller/rettigheder. Rolle Type Kardinalitet Beskrivelse Dan Eng navn name char(50) [1] Entydigt navn på Rollen. oprettetdato creationdate date [1] Angiver den dato rollen er oprettet. udgaaetdato expireddate date [0..1] Angiver den dato rollen ikke mere må bruges. Relationer Association Rolle 1..* Rettighed Bruger Rolle Rolle RolleOmråde Rettighed Dan Eng Type Kardinalitet Beskrivelse 15 / 21

16 name name char(50) [1] Entydigt navn på rettigheden Relationer Association Rolle 1..* Rettighed JournalPost Her beskrives relationen mellem klasser i Brugeradministration og klassen JournalPost fra FESD Datamodel for sager og dokumenter. Relationer Association OrganisatoriskEnhed JournalPost 1 OrganisatoriskEnhed 0..1 JournalPost AdgangsGruppe JournalPost 1 Sikkerhedsklassifikation 0..1 JournalPost Sag Her beskrives relationen mellem klasser i FESD Brugeradministration og klassen Sag i FESD Datamodel for sager og dokumenter. Association OrganisatoriskEnhed Sag 1 OrganisatoriskEnhed 0..1 Sag AdgangsGruppe Sag 1 Sikkerhedsklassifikation 0..1 Sag 16 / 21

17 4 Del C LDAP integration Som nævnt i indledningen er et af de gennemgående krav til fremtidens løsninger på brugeradministrationsområdet, at de baserer sig på åbne standarder. Målet er, at den enkelte myndigheds generelle administrationsværktøjer, hvis de overholder samme standarder, kan anvendes som administrationsværktøj til ESDHløsningen. LDAP (LDAP = Lightweight Directory Access Protocol) er i denne sammenhæng valgt som standard referenceprotokol. Brugeradministrationsmodulet skal integrere til et LDAP-directory, der indeholder de grundlæggende data omkring brugere, organisatoriske enheder og grupper/roller. Brugerkataloget skal kunne svare på opslag, som om det er et LDAP 3.0 baseret directory, som implementerer core-datamodellen som beskrevet i RFC Opslag bør som standard benytte skemaet INetOrgPerson RFC Dette er en del af anbefalingerne fra det fælles tværoffentlige brugerstyringsprojekt. 4.1 Bruger Brugers data fødes fra et objekt, der implementerer organizationalperson oid eller et schema, der er en specialisering af dette (det anbefales generelt i det tværoffentlige brgerstyringsprojekt at anvende InetOrgPerson oid , der er mere anvendt, idet det indeholder certifikat, mailadresse etc.). LDAP-e Bruger-Felt Beskrivelse Cn Brugernavn Brugernavnet skal være mindre end 50 tegn i LDAP ellers er det ikke en lovlig ESDH-bruger 4.2 OrganisatoriskEnhed Organisatioriske enheder (OrganisatoriskEnhed) populeres med data fra et objekt, der implementerer organizationalunit oid eller en specialisering af denne. LDAP-e OrgEnhed-Felt Beskrivelse Ou EnhedsNavn Enhedsnavnet skal være mindre end 50 tegn i LDAPellers er det ikke en lovlig ESDH-enhed. 4.3 Adgangsgruppe Adgangsgrupper fødes med data fra groupofuniquenames LDAP-e Bruger-Felt Beskrivelse Cn gruppenavn Rollenavnet skal være mindre end 50 tegn i LDAP ellers er det ikke en lovlig adgangsgruppe i ESDHsystemet. 4.4 Rolle Rolle fødes med data fra groupofuniquenames Alle groupofuniquenames i LDAP-directoryet er potentielle roller i ESDH-systemet. Privilegier til de enkelte roller tildeles i ESDH-systemet. LDAP-e Bruger-Felt Beskrivelse Cn rollenavn Rollenavnet skal være mindre end 50 tegn i LDAP ellers er det ikke en lovlig rolle i ESDH-systemet. Brugen af roller via groupofuniquenames i LDAP er ikke entydigt defineret i denne standard. Det skyldes at LDAP ikke direkte understøtter rollers dobbelte tilhørsforhold til en bruger i en bestemt organisatorisk enhed. Imidlertid vil den enkelte implementation af standarden kunne vælge en eller flere måder at kompensere for denne mangel i LDAP. Et eksempel på dette er beskrevet i nedenstående use-case. 17 / 21

18 Opret Bruger eksempel use-case Man kunne forestille sig at en ny bruger blev meldt ind i ad-grupperne (groupofuniquenames ) Sagsbehandler, Teknisk Gruppe og Domain Users. Endvidere ligger brugeren i OrgEnheden teknisk forvaltning. Hermed vil ESDH systemet sammenligne navnene i forbindelse med en læsning. Brugeren vil blive placeret i orgenheden teknisk forvaltning. Gruppen sagsbehandler findes som rolle i ESDH systemet og brugeren tildeles derfor denne rolle. Gruppen teknisk gruppe findes ikke i tilgængelige roller, men findes i Adgangsgruppe, hermed får brugeren den adgangsgruppe. Gruppen Domain Users findes ikke i ESDH systemet og har derfor ingen effekt på brugeroprettelsen. Ovenstående er kun et eksempel på hvordan en implementering af standarden ville kunne vælge at fortolke LDAP strukturen således at den manglende strukturelle information om rollers dobbelttilhørsforhold alligevel vil kunne benyttes indenfor standarden. 18 / 21

19 5 Anvendte typer i FESD-modellerne FESD-modellerne er udarbejdet i UML med det formål at beskrive den logiske informationsarkitektur i en FESD-løsning. UML-modellen er opbygget af et antal klasser, der igen er opbygget af relationer til andre klasser og primitive typer, så man kan opfatte UML-modellen som opbygget af byggesten, hvoraf den mindste er de primitive datatyper. I UML-modellen beskriver de primitive datatyper det logiske domæne, som datatypen kan antage, men ikke hvordan den fysiske repræsentation af data skal være. I skemaerne ses for hver primitiv datatype, der anvendes i FESD-UML-modellen, den tilsvarende datatype for hhv. SQL og XSD. integer Benyttes til angivelse af heltal. Der kan benyttes en angivelse af max længde hvis intet er angivet, vil domænet være i intervallet mellem og Anvendte længder i den nuværende model: 2, 3, 4, 6, 8, 10. Benyttes alene til naturlige tal (positive heltal). Benyttes også til at danne identifikator med udfaldsrum UML Type Beskrivelse SQL datatype XSD datatype Integer Heltal i rummet mellem og , begge tal inclusive. Den maksimale længde angives i modellen NonNegativeInteger Naturlige tal Heltal i rummet mellem 0 og , begge tal inclusive NUMBER(Maksimal længde) NUMBER(Maksimal længde) xsd:int xsd:int boolean Er en grundtype i UML. UML Type Beskrivelse SQL datatype XSD datatype Boolean Udfaldsrummet er binært true / false (eller rigtigt / forkert). BOOLEAN xsd:boolean Identifikationstyper UML Type Beskrivelse SQL datatype XSD datatype URI Enhver mulig lovlig URI. Der kan evt. anvendes en maxlængde. STRING xsd:anyuri HttpURI Lovlig http(s)-adresse STRING xsd:anyuri MailToURI Smtp-adresse på en mailmod- STRING xsd:anyuri 19 / 21 Evt. restrictions der afgrænser til http.

20 tager. UUID Identifikator på objekt UUID xsd:anyuri UserIdentifier SystemIdentifier BinaryObject Det er en identifikation af bruger Det er en identifikation af systemer Et binary large object - også kaldet blob - er en samling af binære data, der opbevares som en separat entitet i et database management system. Blobs er typisk billeder, lyd og andre medieobjekter, selvom binær eksekverbar kode til tider også opbevares som en blob. Database support for blob er ikke universal. Binary Large Object (BLOB) Evt. restrictions der afgrænser til mailadresser. Evt. restrictions der afgrænser til UUID. char Benyttes til karakterstrenge af varierende længde, men med en defineret maksimal længde. Anvendte længder: 1, 2, 3, 4, 15, 16, 20, 34, 40, 50, 60, 70, 110, 120, 255. Benyttes også nogle steder til at angive en boolsk værdi. UML Type Beskrivelse SQL datatype XSD datatype Char Den minimale og maksimale længde er angivet i modellen. VARCHAR(maksimal længde) xsd:string Med restriction på den maximale længde ShortText Anvendes til felter der indeholder en kort beskrivende tekst VARCHAR(70) xsd:string Med restriction på den maximale længde Text Anvendes til en beskrivende tekst med en fast længde. VARCHAR(255) xsd:string Med restriction på den maximale længde Code Anvendes til at beskrive en kode, der er nøgle/fremmednøgle i en opslagstabel. VARCHAR(2) xsd:string Med restriction på den maximale længde Name Anvendes til felter der indeholder navne, der kan opfattes som brugervendte nøgler. VARCHAR(70) xsd:string Med restriction på den maximale længde ReferenceText Anvendes til at felter der indeholder tekster, der af brugerne opfattes som fremmednøgler. VARCHAR(40) xsd:string Med restriction på den maximale længde 20 / 21

21 date, datetime og time. Typen Date bruges til at angive dato. Typen DateTime bruges til Dato og tidspunkt, også i betydningen tidsstempel. Typen Time bruges til klokkeslæt. UML Type Beskrivelse SQL datatype XSD datatype Year Årstal VARCHAR (4) xsd:gyear Date Dato DATE xsd:date DateTime Dato og tidspunkt DATETIME xsd:datetime Time Tidspunkt uden datoangivelse TIME xsd:time string Er en grundlæggende type i UML. UML Type Beskrivelse SQL datatype XSD datatype String Tekststreng af vilkårlig længde STRING xsd:string float Defineres som sådan: UML Type Beskrivelse SQL datatype XSD datatype Float Decimaltal hvor længde og præcision begrænses til en samlet størrelse på 16-bit. DECIMAL(X,Y) xsd:float 21 / 21

FESD Arkivstruktur. Standard. FESD-standardisering Arkivstruktur. Datamodel Version 1.1. IT- og Telestyrelsen København den 10. december 2008.

FESD Arkivstruktur. Standard. FESD-standardisering Arkivstruktur. Datamodel Version 1.1. IT- og Telestyrelsen København den 10. december 2008. FESD Arkivstruktur Standard IT- og Telestyrelsen København den 10. december 2008. FESD-standardisering Arkivstruktur. Datamodel Version 1.1 Kolofon: FESD-standardisering. Arkivstruktur. Datamodel. Version

Læs mere

Høring. Dette udkast til forslag til FESD-standard er i offentlig høring i perioden fra 12. juli 2007 til 22. august 2007

Høring. Dette udkast til forslag til FESD-standard er i offentlig høring i perioden fra 12. juli 2007 til 22. august 2007 Høring Dette udkast til forslag til FESD-standard er i offentlig høring i perioden fra 12. juli 2007 til 22. august 2007 IT- og Telestyrelsen København den 12. juli 2007 FESD-standardisering Grænseflade

Læs mere

UDSNIT 8. februar 2008

UDSNIT 8. februar 2008 UDSNIT 8. februar 2008 Dette udsnit indeholder indeholder en introduktion til hvad begrebet brugerstyring dækker over Kolofon: OIO Referencemodel for tværgående brugerstyring Dette baggrundsdokument kan

Læs mere

FESD Sikker epostløsning

FESD Sikker epostløsning FESD Sikker epostløsning Standard IT- og Telestyrelsen København den 11. december 2008. FESD-standardisering Sikker epostløsning. Grænsesnit. Version 1.1 Kolofon: FESD-standardisering. Sikker epostløsning.

Læs mere

Anbefaling til unik Id-nøgle

Anbefaling til unik Id-nøgle Anbefaling til unik Id-nøgle 1 / 15 Kolofon: OIO Referencemodel for tværgående brugerstyring Denne anbefaling kan frit anvendes af alle. Citeres fra anbefalingen i andre publikationer til offentligheden

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL UUID UBL 2.0 UUID G32 Version 1.1 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL UUID Version 1.1 Side 1 Kolofon Kontakt: IT- & Telestyrelsen E-mail:

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL Udvidelse UBL 2.0 Extension G33 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Udvidelse Version 1.2 Side 1 Kolofon Kontakt: IT- & Telestyrelsen

Læs mere

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø Høringssvar vedr. FESD GIS-integrationsmodel version 2.0 Geodata Danmark har

Læs mere

OIOUBL Guideline. OIOUBL Guideline

OIOUBL Guideline. OIOUBL Guideline OIOUBL Guideline OIOUBL Guideline OIOUBL Datatyper UBL 2.0 Datatypes G29 Version 1.3 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 Kolofon Kontakt: Digitaliseringsstyrelsen E-mail:

Læs mere

Skanningsmodul Standard IT- og Telestyrelsen København den 8. september 2005

Skanningsmodul Standard IT- og Telestyrelsen København den 8. september 2005 Skanningsmodul Standard IT- og Telestyrelsen København den 8. september 2005 FESD standardisering FESD-modul. Skanningsmodul Version 1.0 Kolofon: FESD moduler. Skanningsmodul. FESD standardisering. Skanningsmodul

Læs mere

Udvalget for Videnskab og Teknologi B 103 - Svar på Spørgsmål 1 Offentligt

Udvalget for Videnskab og Teknologi B 103 - Svar på Spørgsmål 1 Offentligt Udvalget for Videnskab og Teknologi B 103 - Svar på Spørgsmål 1 Offentligt Bilag 1 Vurdering af økonomiske konsekvenser af beslutningsforslag B 103 1. Indhold i beslutningsforslag B 103 Det overordnede

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL Kontakt UBL 2.0 Contact G34 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OUOUBL Kontakt Version 1.2 Side 1 Kolofon Kontakt: IT- & Telestyrelsen

Læs mere

Autencitetssikring. Vejledning til autenticitetssikringsniveau for den fællesoffentlige log-in-løsning. Side 1 af 12 19. september 2008. Version 1.0.

Autencitetssikring. Vejledning til autenticitetssikringsniveau for den fællesoffentlige log-in-løsning. Side 1 af 12 19. september 2008. Version 1.0. Side 1 af 12 19. september 2008 Autencitetssikring Vejledning til autenticitetssikringsniveau for den fællesoffentlige log-in-løsning Version 1.0. Denne vejledning introducerer problemstillingen omkring

Læs mere

FESD standardisering Udveksling Version 1.0

FESD standardisering Udveksling Version 1.0 FESD standardisering Udveksling Version 1.0 Kolofon: FESD standardisering. Udveksling Version 1.0 FESD udvekslingspakke Udarbejdet af IT- og Telestyrelsen, IT-strategisk kontor, FESD standardiseringsgruppen

Læs mere

Den nye fælles offentlige kravspecifikation. v/ projektleder Anna Schou Johansen

Den nye fælles offentlige kravspecifikation. v/ projektleder Anna Schou Johansen Den nye fælles offentlige kravspecifikation v/ projektleder Anna Schou Johansen Mål og visioner for kravspecifikationen Øget intern og ekstern sammenhæng Effektivisere indkøb og systemopbygning Optimering/effektivisering

Læs mere

Att: Mads Ellehammer:

Att: Mads Ellehammer: KL Att: Mads Ellehammer: 27. august 2008 FESD-standardiseringsgruppen har nu færdigbehandlet de indkomne svar til høringen, som løb fra den 22. marts 2008 til 23. maj 2008, og ønsker med dette brev at

Læs mere

FESD Ledelsesinformation

FESD Ledelsesinformation FESD Ledelsesinformation Version 2.1 Standard IT- og Telestyrelsen København den 18. december 2008. FESD-standardisering Ledelsesinformation. Modul. Version 2.1 Kolofon: FESD-standardisering. Ledelsesinformation.

Læs mere

Guide til integration med NemLog-in / Brugeradministration

Guide til integration med NemLog-in / Brugeradministration Guide til integration med NemLog-in / Brugeradministration Side 1 af 9 21. januar 2013 TG Denne guide indeholder en kort beskrivelse af, hvorledes man som itsystemudbyder (myndighed eller it-leverandør)

Læs mere

OIOUBL Guideline. OIOUBL Guideline

OIOUBL Guideline. OIOUBL Guideline OIOUBL Guideline OIOUBL Guideline OIOUBL Dokument Reference UBL 2.0 Document Reference G21 Version 1.3 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 Kolofon Kontakt: Digitaliseringsstyrelsen

Læs mere

FESD Emnesystematik. Standard. FESD-standardisering FESD Emnesystematik. Datamodel Version 1.1. IT- og Telestyrelsen København 10.

FESD Emnesystematik. Standard. FESD-standardisering FESD Emnesystematik. Datamodel Version 1.1. IT- og Telestyrelsen København 10. FESD Emnesystematik Standard IT- og Telestyrelsen København 10. december 2008 FESD-standardisering FESD Emnesystematik. Datamodel Version 1.1 Kolofon: FESD-standardisering. Emnesystematik. Datamodel. Version

Læs mere

Udvalget for Videnskab og Teknologi (2. samling) UVT alm. del - Svar på Spørgsmål 19 Offentligt

Udvalget for Videnskab og Teknologi (2. samling) UVT alm. del - Svar på Spørgsmål 19 Offentligt Udvalget for Videnskab og Teknologi (2. samling) UVT alm. del - Svar på Spørgsmål 19 Offentligt Ministeren for videnskab, teknologi og udvikling Udvalget for Videnskab og Teknologi Folketinget Christiansborg

Læs mere

Sag og dokument standarderne - Hvad og hvorfor

Sag og dokument standarderne - Hvad og hvorfor Sag og dokument standarderne - Hvad og hvorfor > Sag og dokument standarderne Hvad og hvorfor Dette dokument kan frit anvendes af alle. Citeres der fra dokumentet i andre publikationer til offentligheden,

Læs mere

OIO standardservice til Journalnotat. Generel servicevejledning. KMD Sag Version 1.0 01-09-2013. KMD A/S Side 1 af 15. September 2013 Version 1.

OIO standardservice til Journalnotat. Generel servicevejledning. KMD Sag Version 1.0 01-09-2013. KMD A/S Side 1 af 15. September 2013 Version 1. OIO standardservice til Journalnotat Generel servicevejledning KMD Sag Version 1.0 01-09-2013 KMD A/S Side 1 af 15 Generel servicevejledning til OIO Journalnotat Ekstern standardservice Opdateret 01.09.2013

Læs mere

Informationsforvaltning i det offentlige

Informationsforvaltning i det offentlige Informationsforvaltning i det offentlige 1 Baggrund Den omfattende digitalisering af den offentlige sektor i Danmark er årsag til, at det offentlige i dag skal håndtere større og større mængder digital

Læs mere

OI OXML som obligatorisk, åben standard. - uddybende vejledning. 1 Om dette dokument. 2 Baggrund. 2.1 Datastandardisering

OI OXML som obligatorisk, åben standard. - uddybende vejledning. 1 Om dette dokument. 2 Baggrund. 2.1 Datastandardisering OI OXML som obligatorisk, åben standard - uddybende vejledning 1 Om dette dokument Dette dokument beskriver anbefalet praksis for at anvende OIOXML som åben, obligatorisk standard. IT- og Telestyrelsen

Læs mere

Høring. FESD-standardisering FESD Datafølgeseddel. Protokol Version 0.8

Høring. FESD-standardisering FESD Datafølgeseddel. Protokol Version 0.8 Høring Dette udkast til forslag til FESD-standard er i offentlig høring i perioden fra 12. juli 2007 til 22 august 2007. IT- og Telestyrelsen København 12. juli 2007 FESD-standardisering FESD Datafølgeseddel.

Læs mere

0.9 19-09-2012 DAVAR Omdøbt til SagDokumentFormat. Attention er skilt ud i et selvstændigt format, AttentionFormat.

0.9 19-09-2012 DAVAR Omdøbt til SagDokumentFormat. Attention er skilt ud i et selvstændigt format, AttentionFormat. Specifikation 19. september 2012 DAVAR J.nr. 2012-6211-281 Sagdokumentformat Versionshistorik Version Dato Initialer Noter 0.7 15-06-2012 DAVAR Høringsversion. Indsat MeddelelseAttention. 0.9 19-09-2012

Læs mere

Præsentation af BSK regionens identity and access management platform

Præsentation af BSK regionens identity and access management platform Regionshuset It digital forvaltning BSK programmet Olof Palmens alle 17 Kontakt@regionmidtjylland.dk www.regionmidtjylland.dk Præsentation af BSK regionens identity and access management platform BrugerStamdataKataloget

Læs mere

Leverancebeskrivelse - Bilag 1

Leverancebeskrivelse - Bilag 1 Leverancebeskrivelse - Bilag 1 Miniudbud iht. rammeaftale 02.18 om Borgerskab og Service Juli 2008 Dato: 17-07-2008 Kontor: Udviklingsenhed J.nr.: I4148 Sagsbeh.: CHS Fil-navn: Leverancebeskrivelse bilag

Læs mere

Guide til kravspecifikation

Guide til kravspecifikation Side 1 af 10 10. november 2008 Guide til kravspecifikation Version 1.0. Denne guide indeholder en række råd til brug i kravspecifikationer for IT systemer, der skal anvende NemLog-in løsningen. Hensigten

Læs mere

OIO står for Offentlig Information Online og er det offentliges fællesbetegnelse for it-arkitektur, it-standarder og digital forvaltning.

OIO står for Offentlig Information Online og er det offentliges fællesbetegnelse for it-arkitektur, it-standarder og digital forvaltning. 1 af 6 30-01-2009 12:42 Vejledning Brugervejledning for OIO-katalog over offentlige it-standarder Version 2.0 - April 2008 INDHOLDSFORTEGNELSE Indledning OIO på nettet Standarder og standardisering Offentlig

Læs mere

AuthorizationCodeService

AuthorizationCodeService AuthorizationCodeService Sammenhængende Digital Sundhed i Danmark, version 1.1 W 1 AuthorizationCodeService Sammenhængende Digital Sundhed i Danmark version 1.1 Kåre Kjelstrøm Formål... 3 Introduktion...

Læs mere

It-arkitekturprincipper. Version 1.0, april 2009

It-arkitekturprincipper. Version 1.0, april 2009 It-arkitekturprincipper Version 1.0, april 2009 Fælles it-arkitekturprincipper Som offentlig it-chef, projektleder eller professionel, der arbejder med digitalisering, skal du træffe mange valg i en hektisk

Læs mere

Høringsnotat - specifikation af serviceinterface for SAG version 1 2

Høringsnotat - specifikation af serviceinterface for SAG version 1 2 N OTAT Høringsnotat - specifikation af serviceinterface for SAG version 1 2 Specifikation af serviceinterface for SAG Version 1.2 (Sag-standard) Den fællesoffentlige styregruppe for Sag og Dokument sendte

Læs mere

OBJECT IDENTIFICERES OID PHMR

OBJECT IDENTIFICERES OID PHMR OBJECT IDENTIFICERES OID PHMR MedCom. Odense d. 27. feb. 2014 Thor Schliemann OID OG INTEROPERABILITET OID er et omdrejningspunktet for interoperabilitet I både teknisk og semantisk interoperabilitet er

Læs mere

Elektronisk samhandling i dansk offentlig sektor

Elektronisk samhandling i dansk offentlig sektor Elektronisk samhandling i dansk offentlig sektor v. Michael Bang Kjeldgaard IT- og Telestyrelsen Oslo 11. september 2008 Lessons learned Velfungerende ramme for koordinering Tilgang der matcher modenhedsniveau

Læs mere

Indholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase

Indholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase Indholdsfortegnelse 5. Administrationsdatabase... 2 5.1 Metadata... 2 5.2 Administrationsdata... 3 5.2.1 Indstillingsmuligheder... 3 5.2.2 Webside... 4 5.2.3 Klikafgift (Udgået)... 4 5.2.4 Modtageboks...

Læs mere

Bilag 3. Teknisk løsningsbeskrivelse

Bilag 3. Teknisk løsningsbeskrivelse Bilag 3 Teknisk løsningsbeskrivelse Side 1 af 14 Indholdsfortegnelse 3 TEKNISK LØSNINGSBESKRIVELSE...3 3.1 Vejledning til udfyldelse af bilag...3 3.2 Vision for IT-arkitekturen...4 3.3 Generel arkitektur...5

Læs mere

Version 1.0. Vilkår for brug af Støttesystemet Adgangsstyring

Version 1.0. Vilkår for brug af Støttesystemet Adgangsstyring Version 1.0 Vilkår for brug af Støttesystemet Adgangsstyring kombit@kombit.dk CVR 19 43 50 75 Side 1/10 1. Indledning og vejledning I forbindelse med det forestående monopolbrud konkurrenceudsætter KOMBIT

Læs mere

Baggrundsbeskrivelse for installation af føderation i partnerorganisationer til Danmarks Miljøportal. Baggrund. 1. Hvad er føderation

Baggrundsbeskrivelse for installation af føderation i partnerorganisationer til Danmarks Miljøportal. Baggrund. 1. Hvad er føderation Baggrundsbeskrivelse for installation af føderation i partnerorganisationer til Danmarks Miljøportal. Miljøportalsekretariatet Ref.: jejnb Den 22. november 2007 Baggrund I forbindelse med strukturreformen

Læs mere

Effektiv sagsbehandling og hurtig borgerservice

Effektiv sagsbehandling og hurtig borgerservice Effektiv sagsbehandling og hurtig borgerservice 360 Kommuneløsning Med udvidet borgerselvbetjening og tværgående digitale arbejdsgange er kommunen efterhånden blevet borgernes primære kontaktpunkt til

Læs mere

Høringssvar vedrørende Specifikation af serviceinterface for person (part)

Høringssvar vedrørende Specifikation af serviceinterface for person (part) IT- og Telestyrelsen Holsteinsgade 63 2100 København Ø Høringssvar vedrørende Specifikation af serviceinterface for person (part) Dette er KLs høringssvar på den offentlige høring om specifikation af serviceinterface

Læs mere

Digital strategi, indsatsområde 1, delprojekt 1, Generiske sagsbehandlingsbegreber

Digital strategi, indsatsområde 1, delprojekt 1, Generiske sagsbehandlingsbegreber HØRINGSDOKUMENT Fra: Til: Resumé: David Rosendahl Høringsparter Arbejdsgruppen har identificeret de overordnede og tværgående begreber i sagsbehandlingsprocessen og struktureret og defineret disse generiske

Læs mere

ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER

ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER Kommunernes it-arkitekturråd 8. maj 2014 AGENDA Væsentligste observationer og konklusioner Relevans for kommuner STRATEGI OG ARKITEKTUR Analysen giver et bud

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline UBL 2.0 Datatyper OIOUBL Datatypes G29 Version 1.1 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 Kolofon Kontakt: IT- & Telestyrelsen E-mail: oioubl@itst.dk OIOUBL

Læs mere

IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007

IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 Holsteinsgade 63 2100 København Ø Att. Palle Aagaard FESD Grænseflade til CMS-løsninger, høringssvar fra Gentofte Kommune Gentofte Kommune har med

Læs mere

Minikonference om Sag og Dokumentstandarder 15. juni 2011, Odense

Minikonference om Sag og Dokumentstandarder 15. juni 2011, Odense CPR Broker version 2.0 Minikonference om Sag og Dokumentstandarder 15. juni 2011, Odense Steen Deth, Chefarkitekt sde@gentofte.dk CPR data hvor svært (og interessant) kan det være? Kommune Borgerservice

Læs mere

It arkitektur- og sikkerhedskrav Løn og personalesystemsudbud. Region Midtjylland 2010.

It arkitektur- og sikkerhedskrav Løn og personalesystemsudbud. Region Midtjylland 2010. It arkitektur- og sikkerhedskrav Løn og personalesystemsudbud Region Midtjylland 2010. 1 1 Indledning 1.1 Versionshistorie Version Dato Ansvarlig Status Beskrivelse 1.0 2010-05-04 HENSTI Lukket Definition

Læs mere

SUP-specifikation, version 2.0. Bilag 9. SUP-Styregruppen. Sikkerhed og samtykke. Udkast af 12. juni Udarbejdet for

SUP-specifikation, version 2.0. Bilag 9. SUP-Styregruppen. Sikkerhed og samtykke. Udkast af 12. juni Udarbejdet for SUP-specifikation, version 2.0 Bilag 9 Sikkerhed og samtykke Udkast af 12. juni 2003 Udarbejdet for SUP-Styregruppen Uddrag af indholdet kan gengives med tydelig kildeangivelse Indholdsfortegnelse 1 Introduktion...

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL Adresser UBL 2.0 Address G36 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Adresser Version 1.2 Side 1 Kolofon Kontakt: IT- & Telestyrelsen

Læs mere

Brugeradministrationssystemet

Brugeradministrationssystemet NOTAT Den 13. december 2006 Version 1.0 Brugeradministrationssystemet Af Jens Ole Back, Chefkonsulent, Kontoret for teknik og miljø, KL Det fællesoffentlige Partnerskab om Danmarks Miljøportal (Partnerskabet)

Læs mere

DKAL Snitflader REST Register

DKAL Snitflader REST Register DKAL Snitflader REST Register 1 Indholdsfortegnelse A2.1 INTRODUKTION 3 A2.1.1 HENVISNINGER 3 A2.1.2 LÆSEVEJLEDNING 4 A2.1.2.1 SÅDAN LÆSES EN REST GRAF 4 A2.1.2.2 SÅDAN LÆSES EN RESSOURCE OG EN TYPE 4

Læs mere

Generelt Internationalisering

Generelt Internationalisering Bekendtgørelse om krav til anvendelse af Informations- og Side 1 af 7 Generelt Digital Konvergens samarbejdet, har i sit hidtidige arbejde fokuseret på at implementere vindende, digitale standarder, der

Læs mere

Digital Signatur OCES en fælles offentlig certifikat-standard

Digital Signatur OCES en fælles offentlig certifikat-standard Digital Signatur OCES en fælles offentlig certifikat-standard IT- og Telestyrelsen December 2002 Resumé Ministeriet for Videnskab, Teknologi og Udvikling har udarbejdet en ny fælles offentlig standard

Læs mere

DK-Cartridge 1.0. Distributionsformat for digital læringsindhold VERSION: 1.0

DK-Cartridge 1.0. Distributionsformat for digital læringsindhold VERSION: 1.0 DK-Cartridge 1.0 Distributionsformat for digital læringsindhold VERSION: 1.0 DATO: 9. december 2015 1 Indholdsfortegnelse 1 Introduktion... 3 2 Formål... 3 3 Afgrænsninger... 3 4 DK-Cartridge instanser...

Læs mere

Bilag 9 - Opsamling på høringssvar fra netværket til Arkitekturrapport for KITOS

Bilag 9 - Opsamling på høringssvar fra netværket til Arkitekturrapport for KITOS NOTAT Bilag 9 - Opsamling på høringssvar fra netværket til Arkitekturrapport for KITOS (Bilag til dagsordenspunkt 10, Arkitekturrapport for KITOS) Lars Nico Høgfeldt, Odense Kommune Generel indledning

Læs mere

Revision af tekniske standarder i OIO-kataloget 2007

Revision af tekniske standarder i OIO-kataloget 2007 Revision af tekniske standarder i OIO-kataloget 2007 høringssvar Jens Mikael Jensen Document: Høringssvar vedr- revision af tekniske standarder I OIO-kataloget 2007 Page 1 of 5 1. Resumé IT & Telestyrelsen

Læs mere

Solrød Kommunes supplerende kravspecifikation, som uddyber og præciserer kraven

Solrød Kommunes supplerende kravspecifikation, som uddyber og præciserer kraven Solrød Kommunes supplerende kravspecifikation, som uddyber og præciserer kraven Krav Beskrivelse Prioritet Krav opfyldt -krav til integration med fagsystemer 3.1.1 3.1.2 3.1.3 3.1.4 Ejendoms- og Miljødatabasen,

Læs mere

Underbilag 2O Beskedkuvert Version 2.0

Underbilag 2O Beskedkuvert Version 2.0 Underbilag 2O Beskedkuvert Version 2.0 Indhold Indledning... 34 2 Beskedkuvertens struktur... 34 3 Indhold af Beskedkuverten... 34 3. Overordnet indhold... 45 3.2 Detaljeret indhold af Beskedkuverten...

Læs mere

DANSK PROFILERING AF PHMR AFSÆT I TELEMEDICINSKE PROJEKTER OG REFERENCEARKITEKTURER

DANSK PROFILERING AF PHMR AFSÆT I TELEMEDICINSKE PROJEKTER OG REFERENCEARKITEKTURER DANSK PROFILERING AF PHMR AFSÆT I TELEMEDICINSKE PROJEKTER OG REFERENCEARKITEKTURER MedCom 28. Oktober 2013 Thor Schliemann OM REFERENCEARKITEKTURER (I) Tager udgangspunkt i forretningsmæssige målsætninger

Læs mere

En teknisk introduktion til NemHandel

En teknisk introduktion til NemHandel En teknisk introduktion til NemHandel Indhold > Indledning 3 Standarder 5 OIOUBL 5 OIO RASP 6 OIO SMI 7 Biblioteker 8 Web applikationer 9 Fakturablanket 9 NemHandel Registrering 9 NemHandel.dk 10 Web services

Læs mere

Strategi 2013-2017 Danmarks Miljøportal

Strategi 2013-2017 Danmarks Miljøportal Strategi 2013-2017 Danmarks Miljøportal Introduktion Danmarks Miljøportal (DMP) har ansvaret for en digital infrastruktur på miljøområdet, der gør det muligt for myndigheder og offentlighed at få nem adgang

Læs mere

Høring i forbindelse med revision af certifikatpolitik for OCESpersoncertifikater (Offentlige Certifikater til Elektronisk Service) 27.

Høring i forbindelse med revision af certifikatpolitik for OCESpersoncertifikater (Offentlige Certifikater til Elektronisk Service) 27. Høringsparter vedr. certifikatpolitikker Se vedlagte liste Høring i forbindelse med revision af certifikatpolitik for OCESpersoncertifikater (Offentlige Certifikater til Elektronisk Service) 27. februar

Læs mere

Sag og Dokument - Høringskonference. Nanna Skovgaard, Kontorchef Center for Offentlig Digitalisering og Indkøb

Sag og Dokument - Høringskonference. Nanna Skovgaard, Kontorchef Center for Offentlig Digitalisering og Indkøb Sag og Dokument - Høringskonference Nanna Skovgaard, Kontorchef Center for Offentlig Digitalisering og Indkøb Jeg vil sige noget om Hvad det er vi gør i Økonomistyrelsen? Erfaringer fra FESD Hvor vi står

Læs mere

KURSUSPORTALEN RETNINGSLINJER

KURSUSPORTALEN RETNINGSLINJER KURSUSPORTALEN RETNINGSLINJER Indhold Indledning... 3 Kursusportalens rammer... 3 Typer af Kursus... 3 Hvad er et regionalt kursus... 3 Domæner... 3 Systemroller... 3 Katalog... 4 Personalisering... 4

Læs mere

Arbejdsgange og retningslinier vedr. brug af KMD-SAG-EDH

Arbejdsgange og retningslinier vedr. brug af KMD-SAG-EDH FAABORG-MIDTFYN KOMMUNE Arbejdsgange og retningslinier vedr. brug af KMD-SAG-EDH KMD-sag-edh Side 1 af 10 MÅL MED ELEKTRONISK DOKUMENTHÅNDTERING 4 AFGRÆNSNING 4 SIKKERHED 4 DOKUMENTER 5 Dokumentdefinition

Læs mere

Fællesoffentlig beskedmodel version 1.0

Fællesoffentlig beskedmodel version 1.0 Side: 1 Fællesoffentlig beskedmodel version 1.0 Dokumentet indeholder dels en informationsmodel for hændelsesbeskeden og dens miljø, dels en generisk datamodel for hændelsesbeskeden, som kan danne en fælles

Læs mere

CCS Formål Produktblad December 2015

CCS Formål Produktblad December 2015 CCS Formål Produktblad December 2015 Kolofon 2015-12-14

Læs mere

Politik for Elektronisk Sags- og dokumenthåndtering Godkendt af Styregruppen for edoc

Politik for Elektronisk Sags- og dokumenthåndtering Godkendt af Styregruppen for edoc Politik for Elektronisk Sags- og dokumenthåndtering Godkendt af Styregruppen for edoc Politik for Elektronisk Sags- og Dokumenthåndtering i Region Nordjylland (ESDH) Lovgivning/aftalegrundlag Politikken

Læs mere

Sundhed.dk. Den fælles offentlige sundhedsportal Side1

Sundhed.dk. Den fælles offentlige sundhedsportal Side1 Sundhed.dk Den fælles offentlige sundhedsportal Side1 Adgangsstyring i sundhed.dk kort og længere sigt Ronnie Eriksson, sundhed.dk EPJ-observatoriets årskonference, 28. oktober 2004 Side3 Emner 1. Principper

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL Valutakurser og -koder UBL 2.0 Currency Exchange Rates G18 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Valutakurser og -koder Version

Læs mere

spørgsmål vedrørende privatlivets fred

spørgsmål vedrørende privatlivets fred Problemidentificerende spørgsmål vedrørende privatlivets fred Appendiks 4 Håndbog i: Privatlivsimplikationsanalyse IT og Telestyrelsen INDHOLDSFORTEGNELSE Brug af problemidentificerende spørgsmål... 3

Læs mere

Balancen mellem de interne nødvendigheder og de eksterne påvirkninger reguleres i kommunens it-strategi som præsenteres herunder.

Balancen mellem de interne nødvendigheder og de eksterne påvirkninger reguleres i kommunens it-strategi som præsenteres herunder. It-strategi 1.0 Indledning Flere og flere forretningsprocesser i kommunerne stiller krav til it-understøttelse, og der er store forventninger til at den offentlige sektor hænger sammen inden for it-området.

Læs mere

FESD Sikker epostløsning

FESD Sikker epostløsning FESD Sikker epostløsning Standard IT- og Telestyrelsen København den 23. august 2006. FESD-standardisering Sikker epostløsning. Grænsesnit Version 1.0 Kolofon: FESD-standardisering. Sikker epostløsning.

Læs mere

Introduktion til Digital Post. Februar 2016

Introduktion til Digital Post. Februar 2016 Introduktion til Digital Post Februar 2016 Hvem skal læse dokumentet? Vejledningen er relevant for dig, hvis du har brug for en introduktion til Administrationsportalen i Digital Post og hvad der skal

Læs mere

Anvendelse af dobbelthistorik i GD2

Anvendelse af dobbelthistorik i GD2 Grunddataprogrammet under den Fællesoffentlige Digitaliseringsstrategi GD2 - Adresseprogrammet Anvendelse af dobbelthistorik i GD2 Implementerings regler og eksempler på dobbelthistorik MBBL- REF: Version:

Læs mere

Webservice til upload af produktionstilladelser

Webservice til upload af produktionstilladelser BILAG 1 Webservice til upload af produktionstilladelser Indhold og anvendelse Denne web-service gør det muligt for 3. parts programmer i kommuner og amter at Uploade og registrere kommunale produktionstilladelser

Læs mere

Leverings- og vedligeholdelsesvilkår for Moderniseringsstyrelsen lokale datavarehus LDV

Leverings- og vedligeholdelsesvilkår for Moderniseringsstyrelsen lokale datavarehus LDV Leverings- og vedligeholdelsesvilkår for Moderniseringsstyrelsen lokale datavarehus LDV Indhold 1. DEFINITIONER... 2 2. BAGGRUND OG FORMÅL... 2 3. MODERNISERINGSSTYRELSENS YDELSER... 3 4. INSTITUTIONENS

Læs mere

It-delstrategi for administrativ it-anvendelse

It-delstrategi for administrativ it-anvendelse Administrativ DELSTRATEGI 2011-2015 NOTAT It-delstrategi for administrativ it-anvendelse 9. september 2011 Indholdsfortegnelse 1. Formål...2 2. Baggrund...2 3. Vision...3 4. Strategisk retning...3 4.1.

Læs mere

4. Den offentlige sektors brug af it

4. Den offentlige sektors brug af it Den offentlige sektors brug af it 39 4. Den offentlige sektors brug af it Figur 4.1 Digitale serviceydelser til borgere og virksomheder 1 8 6 Pct. af myndigheder 87 88 9 94 94 Downloade blanketter digitalt

Læs mere

2.15 21/05/2013 Tilføjet dokumentation af bvn input for GetEngagementDetailed

2.15 21/05/2013 Tilføjet dokumentation af bvn input for GetEngagementDetailed APOS2 REST API Forord Dette dokument er en del af APOS version 2 manualerne. APOS version 2 (APOS2 herefter) er et organisation, klassifikation og personale system baseret på Sag & Dokument standarderne.

Læs mere

Risikovurdering vedr. Google Apps. Sammenfatning. Risikovurdering

Risikovurdering vedr. Google Apps. Sammenfatning. Risikovurdering Risikovurdering vedr. Google Apps Sammenfatning Side: 1 af 6 1. Introduktion IT Crew har faciliteret gennemførelse af en risikovurdering på en workshop med Odense Kommune d. 25. august 2010. Workshoppen

Læs mere

Det skal understreges, at kassation af dokumenter er en mulighed, og ikke en pligt for kommunerne.

Det skal understreges, at kassation af dokumenter er en mulighed, og ikke en pligt for kommunerne. KL notat 26-06-2014/FLN Beslutning om kassation i ESDH-systemer med tjekliste Notatet er til brug for den kommunale myndigheds beslutning, om den vil gøre brug af muligheden for kassation fra ESDH eller

Læs mere

Afleveringsbestemmelse for Kingo

Afleveringsbestemmelse for Kingo Kultur- og Fritidsforvaltningen Stadsarkivet Afleveringsbestemmelse for Kingo Efter drøftelse mellem Center for Specialundervisning, Børne- og Ungeforvaltningen og Københavns Stadsarkiv fastsættes hermed

Læs mere

Kundens IT miljø - Region Midtjylland

Kundens IT miljø - Region Midtjylland Kundens IT miljø - Region Midtjylland af Peder Thorsø Lauridsen, it-arkitekt, Arkitektur og Design. Revideret 16. maj 2011. Kundens IT miljø - Region Midtjylland Overordnet beskrivelse af it-installationen

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL Priser UBL 2.0 Prices G25 Version 1.1 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 Kolofon Kontakt: IT- & Telestyrelsen E-mail: oioubl@itst.dk OIOUBL Version

Læs mere

Teknisk Dokumentation

Teknisk Dokumentation Sundhedsstyrelsens E2B Bivirkningswebservice Teknisk Dokumentation Side 1 af 8 Indhold Indledning... 3 Terminologi... 3 Arkitektur... 4 Web Service Snitflade... 4 Valideringsfejl... 5 Success... 5 E2B...

Læs mere

Specifikationsdokument for LDAP API

Specifikationsdokument for LDAP API Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Specifikationsdokument for LDAP API DanID A/S 5. juni 2014 Side 1-15

Læs mere

STS NETVÆRKSDAGE ADGANGSSTYRING. Brian Storm Graversen April 2016

STS NETVÆRKSDAGE ADGANGSSTYRING. Brian Storm Graversen April 2016 STS NETVÆRKSDAGE ADGANGSSTYRING Brian Storm Graversen April 2016 Emner Motivation og baggrund Introduktion til jobfunktionsrollebegrebet Hvad er en jobfunktionsrolle Typer af brugersystemroller Dataafgrænsninger

Læs mere

Kort og godt om test af arkiveringsversioner

Kort og godt om test af arkiveringsversioner Kort og godt om test af arkiveringsversioner Data og dokumenter fra den offentlige forvaltnings it-systemer, som skal bevares for eftertiden, skal afleveres til arkiv i form af arkiveringsversioner. Arkiveringsversioner

Læs mere

Identity og Access Management

Identity og Access Management Identity og Access Management Udfordringen Hvor er vi i dag Hvordan griber vi det an 06-09-2013 1 Udfordring Når en medarbejder skifter stilling så tildeles en ny netværksidentitet (brugerid) Arbejdskrævende

Læs mere

Fordeling af journalnotater og dokumenter Udkast til løsningsmodel. Marts 2014

Fordeling af journalnotater og dokumenter Udkast til løsningsmodel. Marts 2014 Fordeling af journalnotater og dokumenter Udkast til løsningsmodel Marts 2014 1 Indledning Denne præsentation beskriver, på et overordnet plan, følgende områder i forhold til en fremtidig fordelingsmekanisme,

Læs mere

Baggrund og løsningsbeskrivelse DUBU 2.0

Baggrund og løsningsbeskrivelse DUBU 2.0 Baggrund og løsningsbeskrivelse DUBU 2.0 1 Formål Det overordnede formål med DUBU-systemet er at skabe bedre styring og sagsbehandling på området Udsatte børn og unge. Systemet skal både understøtte den

Læs mere

Leverings- og vedligeholdelsesvilkår. for. Økonomistyrelsen lokale datavarehus ØS LDV

Leverings- og vedligeholdelsesvilkår. for. Økonomistyrelsen lokale datavarehus ØS LDV Leverings- og vedligeholdelsesvilkår for Økonomistyrelsen lokale datavarehus ØS LDV Økonomistyrelsen Landgreven 4, postboks 2193 DK-1017 København K (i det følgende benævnt Økonomistyrelsen) 1 INDHOLDSFORTEGNELSE

Læs mere

Rapport dannet den: 5. oktober 2010 1 Spil kontrol

Rapport dannet den: 5. oktober 2010 1 Spil kontrol 1 Spil kontrol kan vindes af 1 Jackpot - Identifikation - Gevinst - TotalGevinst - DatoTid - KommissionRake Spil - Identifikation - KøbDatoTid - Salgskanal - ForventetSlutDatoTid - FaktiskSlutDatoTid -

Læs mere

Snitfladebeskrivelse HentYdelseInformation BYS P11-4 KMD Børneydelse Version 1.0.0, 2012.05.22

Snitfladebeskrivelse HentYdelseInformation BYS P11-4 KMD Børneydelse Version 1.0.0, 2012.05.22 Snitfladebeskrivelse HentYdelseInformation BYS P11-4 KMD Børneydelse Version 1.0.0, 2012.05.22 Indholdsfortegnelse Indholdsfortegnelse Ændringer i forhold til forrige version... 2 1 Brug af snitfladebeskrivelsen...

Læs mere

Administration af brugere vha. sammenhængende log-in

Administration af brugere vha. sammenhængende log-in Hvad er sammenhængende log-in? Danmarks Miljøportal Ref.: jejnb 21. august 2012 Formål Formålet med beskrivelsen er at skabe et overblik over sammenhængende log-in, som en nem og enkel måde at administrere

Læs mere

Dokumentationsguide for dansk Bankkonto

Dokumentationsguide for dansk Bankkonto Dokumentationsguide for dansk Bankkonto OIOXML dokumentationsguide for dansk Bankkonto Denne guide er udarbejdet af Peter Neergaard Jensen, IT- og Telestyrelsen, i regi af Kernekomponentgruppen under XML-projektet

Læs mere

Statens Arkivers brug af digitale arkivalier Erfaringer med brug af digitale arkivalier i Statens Arkiver

Statens Arkivers brug af digitale arkivalier Erfaringer med brug af digitale arkivalier i Statens Arkiver Statens Arkivers brug af digitale arkivalier Erfaringer med brug af digitale arkivalier i Statens Arkiver Lone Smith Jespersen Specialkonsulent, Statens Arkiver Emner Sofia-systemet grundlaget for at bruge

Læs mere

Er standardisering en forudsætning for at systemer kan tale sammen?

Er standardisering en forudsætning for at systemer kan tale sammen? HVORFOR STANDARDER? Er standardisering en forudsætning for at systemer kan tale sammen? Nej, men standardisering reducerer den kompleksitet, der er ved at integrere systemer væsentligt. Så i praksis vil

Læs mere