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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kommissorium for Domænebestyrelsen for Bygninger, Boliger og Forsyning

Kommissorium for Domænebestyrelsen for Bygninger, Boliger og Forsyning Kommissorium for Domænebestyrelsen for Bygninger, Boliger og Forsyning Introduktion Besluttet af Styregruppen for Tværoffentligt Samarbejde, marts 2008 I forlængelse af den fællesoffentlige strategi for

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

Service Orienteret Arkitektur en succes, der i stigende grad kræver IT Governance fokus

Service Orienteret Arkitektur en succes, der i stigende grad kræver IT Governance fokus Service Orienteret Arkitektur en succes, der i stigende grad kræver IT Governance fokus 4. oktober 2006 C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y DEVOTEAM i Danmark og i Europa 2 Devoteam

Læs mere

Standard IT- og Telestyrelsen København den 17. december 2007

Standard IT- og Telestyrelsen København den 17. december 2007 Standard IT- og Telestyrelsen København den 17. december 2007 FESD-standardisering FESD Datafølgeseddel. Protokol Version 1.0 Kolofon: FESD-standardisering. FESD Datafølgeseddel. Protekol. Version 1.0

Læs mere

Baggrundsinformation

Baggrundsinformation 1. Begreber Baggrundsinformation Sags- og Dokumentindekset skal indeholde sags- og dokumentmetadata, samt nøgler til andre relaterede forretningsobjekter fra Afsendersystemer, således at der kan leveres

Læs mere

Digital post Snitflader Bilag A2 - REST Register Version 6.3

Digital post Snitflader Bilag A2 - REST Register Version 6.3 Digital post Snitflader Bilag A2 - REST Register Version 6.3 1 Indholdsfortegnelse A2.1 INTRODUKTION 4 A2.1.1 HENVISNINGER 4 A2.2 OVERSIGT OVER FUNKTIONSOMRÅDE 5 A2.2.1 OPRET / HENT OPLYSNINGER OM SLUTBRUGER

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

OIOXML dokumentationsguide Person

OIOXML dokumentationsguide Person OIOXML dokumentationsguide Person OIOXML dokumentationsguide Person . Ejerskab Indenrigs og Sundhedsministeriets CPR-kontor i medfør af Bekendtgørelse af lov om Det Centrale Personregister, jf. lov nr.

Læs mere

Arkitekturrapport: Kommunernes Ydelsessystem (KY) Arkitekturrapport: Kommunernes Ydelsessystem

Arkitekturrapport: Kommunernes Ydelsessystem (KY) Arkitekturrapport: Kommunernes Ydelsessystem Arkitekturrapport: Kommunernes Ydelsessystem 1 Indholdsfortegnelse Baggrund for projekt... 3 Resultat af gennemført arkitekturanalyse... 5 Anvendelse af forretningsservices... 9 Baggrund for projekt Baggrund

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

IT-SIKKERHEDSPOLITIK UDKAST

IT-SIKKERHEDSPOLITIK UDKAST IT-SIKKERHEDSPOLITIK UDKAST It-sikkerhedspolitikken tilstræber at understøtte Odsherred Kommunes overordnede vision. It- og øvrig teknologianvendelse, er et af direktionens redskaber til at realisere kommunens

Læs mere

De fællesoffentlige komponenter: Federativa identitetslösningar, Erfarenheter från Danmark

De fællesoffentlige komponenter: Federativa identitetslösningar, Erfarenheter från Danmark De fællesoffentlige komponenter: Federativa identitetslösningar, Erfarenheter från Danmark Digital post, NemSMS & Fjernprint samt strategien for udvikling af mobile løsninger for Digital post og Min side

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

Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3

Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3 Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3 1 Indholdsfortegnelse B.1. INTRODUKTION... 4 B.1.1. HENVISNINGER... 4 B.1.2. INTEGRATION MED EKSISTERENDE

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

En teknisk introduktion til NemHandel

En teknisk introduktion til NemHandel En teknisk introduktion til NemHandel 02. december 2014 Indhold INDHOLD... 1 INDLEDNING... 2 STANDARDER... 4 OIOUBL e-handelsstandard... 4 OIORASP - transportprotokol... 5 BETINGELSER FOR ANVENDELSE AF

Læs mere

E-sundhedsobservatoriet. Sådan sikrer du en effektiv håndtering af brugere i EPJ

E-sundhedsobservatoriet. Sådan sikrer du en effektiv håndtering af brugere i EPJ E-sundhedsobservatoriet Sådan sikrer du en effektiv håndtering af brugere i EPJ Hvem er jeg? Dennis Mølkær Jensen Region Nordjylland Teamkoordinator - Udviklingsafsnit Teknisk projektleder OneSystem Integration

Læs mere

Installation og Drift. Aplanner for Windows Systemer Version 8.15

Installation og Drift. Aplanner for Windows Systemer Version 8.15 Installation og Drift Aplanner for Windows Systemer Version 8.15 Aplanner for Windows løsninger Tekniske forudsætninger Krav vedr. SQL Server SQL Server: SQL Server 2008 Express, SQL Server 2008 R2 eller

Læs mere

B 103 - Bilag 6 Offentligt

B 103 - Bilag 6 Offentligt Udvalget for Videnskab og Teknologi B 103 - Bilag 6 Offentligt Ministeren for videnskab, teknologi og udvikling Udvalget for Videnskab og Teknologi Folketinget Christiansborg 1240 København K Hermed fremsendes

Læs mere

Bilag 2A: IT-status i Ikast-Brande Kommune. Januar 2014

Bilag 2A: IT-status i Ikast-Brande Kommune. Januar 2014 Bilag 2A: Januar 2014 Side 1 af 5 1. Indledning... 3 2. Statusbeskrivelse... 3 3. IT infrastruktur og arkitektur... 4 3.1. Netværk - infrastruktur... 4 3.2. Servere og storage... 4 3.3. Sikkerhed... 4

Læs mere

Indledning Dokumentet indeholder et oplæg til fastlæggelse af scope for realisering af forretningsservicen Partskontakt.

Indledning Dokumentet indeholder et oplæg til fastlæggelse af scope for realisering af forretningsservicen Partskontakt. 8. april 2013 19-Partskontakt => Kontaktdata Indledning Dokumentet indeholder et oplæg til fastlæggelse af scope for realisering af forretningsservicen Partskontakt. I de oprindelige oplæg med visionen

Læs mere

360 Digital Styringsreol

360 Digital Styringsreol 360 Digital Styringsreol OPNÅ BEDRE STYRING, OPFØLGNING, OVERBLIK SAMT DOKUMENTATION AF ORGANISATIONENS PROCESSER Mange organisationer oplever et voksende pres for på samme tid at skulle levere højere

Læs mere

Projektleder : Jacob-Steen Madsen (jsm), Syddansk Universitet (SDU)

Projektleder : Jacob-Steen Madsen (jsm), Syddansk Universitet (SDU) Foranalyse Projekt: PDM-kerne Projektleder : Jacob-Steen Madsen (jsm), Syddansk Universitet (SDU) Projektdeltagere: 1. Indledning og baggrund Mogens Sandfær (MS), Danmarks Tekniske Universitet (DTU) Jørgen

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

Kravspecification IdP løsning

Kravspecification IdP løsning Kravspecification IdP løsning Resume IT-Forsyningen, som varetager IT-drift for Ballerup, Egedal og Furesø Kommuner, ønsker at anskaffe en IdP/Føderationsserverløsning, der kan understøtte en række forretningsmæssige

Læs mere

Arkitekturrapport: KITOS - Kommunens It-Overbliks System

Arkitekturrapport: KITOS - Kommunens It-Overbliks System Arkitekturrapport: KITOS - Kommunens It-Overbliks System Denne orienteringsrapport udarbejdes for it-projekter i henhold til brug af den fælleskommunale rammearkitektur. Rapport ejes af projektets it-arkitekt.

Læs mere

Effektiv digitalisering. - Digitaliseringsstyrelsens strategi 2012-2015. April 2012

Effektiv digitalisering. - Digitaliseringsstyrelsens strategi 2012-2015. April 2012 April 2012 Effektiv digitalisering - Digitaliseringsstyrelsens strategi 2012-2015 Baggrund Danmark står med væsentlige økonomiske udfordringer og en demografi, der betyder færre på arbejdsmarkedet til

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

Bilag til standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter

Bilag til standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter Bilag til standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter Servicebeskrivelse Økonomistyrelsen Marts 2011 Side 1 af

Læs mere

Brønderslev-Dronninglund Kommune

Brønderslev-Dronninglund Kommune Brønderslev-Dronninglund Kommune Brønderslev Rådhus, Ny Rådhusplads 1, 9700 Brønderslev. Tlf. 9945 4545 - Fax 9945 4500 Dronninglund Rådhus, Rådhusgade 5, 9330 Dronninglund. Tlf. 9947 1111 - Fax 99 47

Læs mere

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet.

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet. MOX og APOS2 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

Tjekliste. Til brug ved anskaffelse af nye systemer og/eller programmer

Tjekliste. Til brug ved anskaffelse af nye systemer og/eller programmer Tjekliste Til brug ved anskaffelse af nye systemer og/eller programmer I forbindelse med påtænkt anskaffelse af nyt program eller system udfyldes tjeklisten af leverandør. Team Digitalisering og Driftscenter

Læs mere

DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME

DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME 1 Indholdsfortegnelse B.1. INTRODUKTION... 3 B.1.1. HENVISNINGER... 3 B.1.2. INTEGRATION MED EKSISTERENDE SIKKER E-POSTLØSNING... 3 B.1.3.

Læs mere

Bibliotek.dk som lokal grænseflade notat

Bibliotek.dk som lokal grænseflade notat Bibliotek.dk som lokal grænseflade notat Dette notat skal beskrive løsningsmodeller for bibliotek.dk som lokal grænseflade som opfølgning på det notat som blev lavet i 2007 1 og på den workshop som blev

Læs mere

Undervisningsbeskrivelse

Undervisningsbeskrivelse Undervisningsbeskrivelse Stamoplysninger til brug ved prøver til gymnasiale uddannelser Termin Maj-juni 12/15 Institution Uddannelse Fag og niveau Lærer(e) Hold Campus Vejle HHX Informationsteknologi niveau

Læs mere

Håndbog Til CPR services. Bilag 8 GCTP-standard m.m. CPR-kontoret

Håndbog Til CPR services. Bilag 8 GCTP-standard m.m. CPR-kontoret Håndbog Til CPR services Bilag 8 GCTP-standard m.m. CPR-kontoret Datavej 20, Postboks 269, 3460 Birkerød E-post: cpr@cpr.dk. Telefax 45 82 51 10. Hjemmeside: www.cpr.dk Side 2 af 14 Indholdsfortegnelse

Læs mere

Opsætning af MobilePBX med Kalenderdatabase

Opsætning af MobilePBX med Kalenderdatabase Opsætning af MobilePBX med Kalenderdatabase Dette dokument beskriver hvorledes der installeres Symprex Exchange Connector og SQL Server Express for at MobilePBX kan benytte kalenderadadgang via database

Læs mere

GIS-strategiplan 2008. Helsingør Kommune. GIS-strategiplan 2008

GIS-strategiplan 2008. Helsingør Kommune. GIS-strategiplan 2008 Helsingør Kommune 1. Baggrund og projektgruppe 2. Rapporten 3. Behov og ønsker 4. Muligheder og standarder 5. Principper for GIS 6. Organisation og Økonomi 7. Efterfølgende 8. (Anvendelses eksempler) 1

Læs mere

Postnummerkort.dk, version 1.0 officielt postnummerkort

Postnummerkort.dk, version 1.0 officielt postnummerkort Postnummerkort.dk, version 1.0 officielt postnummerkort 1. december 2006 Sag D-4236-6 /mli Version 1.0a 1. Indledning I forbindelse med forberedelsen af kommunalreformen vedtog folketinget i juni 2005

Læs mere

LUDUS WEB. Installations- og konfigurations-vejledning. Den 7. april 2009. J.nr.: 4004 V0624 09

LUDUS WEB. Installations- og konfigurations-vejledning. Den 7. april 2009. J.nr.: 4004 V0624 09 LUDUS WEB Installations- og konfigurations-vejledning Den 7. april 2009 J.nr.: 4004 V0624 09 CSC Scandihealth A/S, P.O. Pedersens Vej 2, DK-8200 Århus N Tlf. +45 3614 4000, fax +45 3614 7324, www.scandihealth.dk,

Læs mere

24-03-2009. Problemstilling ved DBK integration i BIM Software Hvad skal der til. Nicolai Karved, Betech Data A/S

24-03-2009. Problemstilling ved DBK integration i BIM Software Hvad skal der til. Nicolai Karved, Betech Data A/S 24-03-2009 Problemstilling ved DBK integration i BIM Software Hvad skal der til. Nicolai Karved, Betech Data A/S Problemstilling ved DBK integration i BIM Software Domæner og aspekter Det domæne, der primært

Læs mere

UDKAST v.2. Til interessenter i ehandel (udsendes i bred offentlig høring)

UDKAST v.2. Til interessenter i ehandel (udsendes i bred offentlig høring) Sektorstandardiseringsudvalget for ehandel Til interessenter i ehandel (udsendes i bred offentlig høring) UDKAST v.2. Høring over vision, pejlemærker og forretningskrav til ehandel mellem den offentlige

Læs mere

UC Effektiviseringsprogrammet. Projektgrundlag. Business Intelligence. version 1.2

UC Effektiviseringsprogrammet. Projektgrundlag. Business Intelligence. version 1.2 UC Effektiviseringsprogrammet Projektgrundlag Business Intelligence version 1.2 9. september 2014 1 Stamdata Stamdata Projektnavn (forventet): Projektejer: Projekttype: Business Intelligence It-chef Hans-Henrik

Læs mere

Sammenhængende log-in - SSO til applikationer i et andet sikkerhedsdomæne

Sammenhængende log-in - SSO til applikationer i et andet sikkerhedsdomæne > Sammenhængende log-in - SSO til applikationer i et andet sikkerhedsdomæne IT- & Telestyrelsen, Kontor It-infrastruktur og Implementering februar 2010 Indhold > 1 Introduktion 4 1.1 Føderationsfordele

Læs mere

Side 1. Databaser og SQL. Dagens gang. Databasebegreber. Introduktion til SQL Kap 1-5

Side 1. Databaser og SQL. Dagens gang. Databasebegreber. Introduktion til SQL Kap 1-5 Databaser og SQL Introduktion til SQL Kap 1-5 1 Dagens gang Databaser Database begreber Mapning af klasser til relationel model Normalisering Opgaver til næste gang 2 Databasebegreber A database is a:

Læs mere

Kommunernes it-arkitekturråd

Kommunernes it-arkitekturråd FØDERATIVE SIKKERHEDSMODELLER TIL SÅRJOURNALEN (OG ANDRE NATIONALE IT-LØSNINGER PÅ SUNDHEDSOMRÅDET) Kommunernes it-arkitekturråd 18. december 2014 HVEM HAR DELTAGET I ARBEJDET? Arbejdsgruppe: Lars Nico

Læs mere

Kulturministeriets it-arkitekturpolitik

Kulturministeriets it-arkitekturpolitik Kulturministeriets Kulturministeriets Januar 2012 Udgivet af Kulturministeriet Udarbejdet af Kulturstyrelsen H.C. Andersens Boulevard 2 1553 København V www.kulturstyrelsen.dk post@kulturstyrelsen.dk Kulturministeriets

Læs mere

SOSI Gateway Komponenten (SOSI GW)

SOSI Gateway Komponenten (SOSI GW) SOSI Gateway Komponenten (SOSI GW) - en security domain gateway Version 1.2 1/8 Indledning Region Syddanmark er udvalgt som pilotregion for projektet Det Fælles Medicingrundlag, og i den forbindelse arbejdes

Læs mere

Projektet er en del af den fælles kommunale digitaliseringsstrategi.

Projektet er en del af den fælles kommunale digitaliseringsstrategi. N OTAT Den 7. november 2013 Business case for projekt vedr. digital byggesagsbehandling Sags ID: 1728511 Dok.ID: 1728511 AKP@kl.dk Direkte 3370 3241 Mobil 2215 8678 1. Ledelsesresumé Projektet om digital

Læs mere

7. Forslag om optagelse af standarden OVF i OIO Kataloget (B)

7. Forslag om optagelse af standarden OVF i OIO Kataloget (B) Et emne, som allerede har affødt en del debat, er den obligatoriske brug af elektronisk kommuni kation, som blandt andet sidestiller en e mailhenvendelse med en henvendelse modtaget med pa pirpost, hvilket

Læs mere

Guide til integration med NemLog-in / Signering

Guide til integration med NemLog-in / Signering Guide til integration med NemLog-in / Signering Side 1 af 6 14. november 2013 TG Denne guide indeholder en kort beskrivelse af, hvorledes man som itsystemudbyder (myndighed eller it-leverandør) kan integrere

Læs mere

Kontraktbilag 4 Kundens IT-miljø

Kontraktbilag 4 Kundens IT-miljø Kontraktbilag 4 Kundens IT-miljø [Vejledning til Leverandøren i forbindelse med afgivelse af tilbud Dette bilag indeholder Kundens krav til at systemet skal kunne afvikles i nedenstående IT-miljø. Leverandøren

Læs mere

Bilag 12 - Fælles arkitekturramme for GD1-GD2-GD7. OIO Serviceprincipper

Bilag 12 - Fælles arkitekturramme for GD1-GD2-GD7. OIO Serviceprincipper Bilag 12 - Fælles arkitekturramme for GD1-GD2-GD7 OIO Serviceprincipper Version: 1.1 Status: i høring i PF for GD1 og GD2 Oprettet: 4. juni 2014 Dato: 4. juni 2014 Dokument historie Version Dato Beskrivelse

Læs mere

Kommentar fra KMS til Specifikation af Serviceinterface for Person

Kommentar fra KMS til Specifikation af Serviceinterface for Person Kommentar fra KMS til Specifikation af Serviceinterface for Person Organisation Side Kapitel Afsnit/figur/tabel /note Type af kommentar (generel (G), redaktionel (R), teknisk (T)) Kommentar KMS-1 G Godt

Læs mere

Database kursus Forår 2013

Database kursus Forår 2013 Database kursus Forår 2013 Jacob Aae Mikkelsen Database design og programmering/databaser fra Organisationsorienteret softwareudvikling 1 Praktisk info Lærebog Database Systems: The Complete Book Skema

Læs mere

Tilslutning til ecomone Basis (OIO Faktura)

Tilslutning til ecomone Basis (OIO Faktura) Tilslutning til ecomone Basis (OIO Faktura) 1. november 2009, Version 1.1 1. POST DANMARKS ECOMONE BASIS (OIO FAKTURA)... 3 1.1 BEGREBER... 3 2 KANALER... 3 3 MODEL FOR DATAUDVEKSLING... 4 4 KOMMUNIKATION...

Læs mere

IDENTITY SECURITY MANAGER INTEGRATION MELLEM MENNESKER OG SIKKERHED

IDENTITY SECURITY MANAGER INTEGRATION MELLEM MENNESKER OG SIKKERHED INTEGRATION MELLEM MENNESKER OG SIKKERHED SIDE 2/6 INTRODUKTION AVIOR Identity Security Manager (ISM) er en omfattende løsning og koncept til håndtering af identiteter og integration til eksisterende bruger-

Læs mere

(Af forside skal det fremgå, om standarden er i høring, har været i høring eller er godkendt) Begrebsmodel til brugerstyring

(Af forside skal det fremgå, om standarden er i høring, har været i høring eller er godkendt) Begrebsmodel til brugerstyring (Af forside skal det fremgå, om standarden er i høring, har været i høring eller er godkendt) Begrebsmodel til brugerstyring Version 1.1 Godkendt 21. januar 2010 1 2 > Begrebsmodel til brugerstyring Denne

Læs mere

Scope dokument for Advisservice

Scope dokument for Advisservice 18. marts 2013 AHI Scope dokument for Advisservice Indhold 1. Advisservice... 2 2. Advis håndtering i KMD Sag... 2 3. Hændelse og Advis... 3 4. Advis løsningsmodel... 4 5. Abonnementsopsætning... 5 6.

Læs mere

Vejledning vedrørende niveauer af autenticitetssikring

Vejledning vedrørende niveauer af autenticitetssikring Vejledning vedrørende niveauer af autenticitetssikring Kolofon: OIO Referencemodel for tværgående brugerstyring Denne anbefaling kan frit anvendes af alle. Citeres fra anbefalingen i andre publikationer

Læs mere

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB Det er Web Services, der rejser sig fra støvet efter Dot Com boblens brag. INTRODUKTION Dette dokument beskriver forslag til fire moduler, hvis formål

Læs mere

Udbudsplan og betingelser

Udbudsplan og betingelser Projektnavn ESDH Sidst redigeret af Tina Malene Ørsted Sidst redigeret den 6. april 2010 Udbudsplan og betingelser SKI miniudbud i tre trin ESDH- system I dette materiale præsenteres de konkrete tildelingskriterier

Læs mere

Integration for forretningen - værdien af fælles retningslinjer for portalintegration

Integration for forretningen - værdien af fælles retningslinjer for portalintegration 1. april 2009 Integration for forretningen - værdien af fælles retningslinjer for portalintegration Kristian Hjort-Madsen Den Digitale Taskforce Integration for forretningen Integration skaber bedre digital

Læs mere

Obligatorisk opgave i objektorienteret analyse og design

Obligatorisk opgave i objektorienteret analyse og design Obligatorisk SD-opgave s. Obligatorisk opgave i objektorienteret analyse og design Løs følgende, som en indviduel opgave. I må gerne samarbejde i grupper, men alle har ansvar for at udfærdige sin egen

Læs mere

Begrænsninger i SQL. Databaser, efterår 2002. Troels Andreasen

Begrænsninger i SQL. Databaser, efterår 2002. Troels Andreasen Databaser, efterår 2002 Begrænsninger i SQL Troels Andreasen Datalogiafdelingen, hus 42.1 Roskilde Universitetscenter Universitetsvej 1 Postboks 260 4000 Roskilde Telefon: 4674 2000 Fax: 4674 3072 www.dat.ruc.dk

Læs mere

Forord. Versioner. APOS2 Bulk data import / export. APOS2 Security. APOS2 Installation, Operation and Monitoring. APOS2 Service Catalogue

Forord. Versioner. APOS2 Bulk data import / export. APOS2 Security. APOS2 Installation, Operation and Monitoring. APOS2 Service Catalogue APOS2 Datamodel 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

OIOUBL Guideline. OIOUBL Profiler. UBL 2.0 Profiles (UTS) Appendiks til G26. Version 1.3

OIOUBL Guideline. OIOUBL Profiler. UBL 2.0 Profiles (UTS) Appendiks til G26. Version 1.3 OIOUBL Guideline OIOUBL Profiler UBL 2.0 Profiles (UTS) Appendiks til G26 Version 1.3 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Profiler (UTS) Version 1.3 Side 2 Kolofon

Læs mere

WHITEPAPER DokumentBroker

WHITEPAPER DokumentBroker WHITEPAPER DokumentBroker Copyright 2013 DokumentBrokeren er en selvstændig arkitekturkomponent, som uafhængigt af forretningsapplikation og kontorpakke, genererer dokumenter af forskellige typer og formater,

Læs mere

Vejledning til Teknisk opsætning

Vejledning til Teknisk opsætning Vejledning til Teknisk opsætning v. 1.0 Adm4you, 2010. Indhold Kort om denne vejledning... 3 Generelt om easyourtime... 3 Installation af databasen... 3 Sikkerhed og rettigheder... 4 SQL Login... 4 Rettigheder

Læs mere