Implementering af Identity Management i Miljøministeriet

Implementering af Identity Management i Miljøministeriet Anders Johansen Kongens Lyngby 2008 IMM-B.Eng-2008-27

Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone +45 45253351, Fax +45 45882673 reception@imm.dtu.dk www.imm.dtu.dk

i Summary Most companies have for many years integrated a lot of different IT-systems independently of each other. Commonly these systems don t have interfaces to connect to each other, they use separate databases and are generally incompatible. The systems often have department specific functions; Human Resource management for the personnel department, Incident tracking for the IT department and so on. The same data is often stored across these systems, typically user identities and rights. These doublets of identities make proper management tiresome, because they often need to be manually changed in each system. There is a big chance of having a forgotten, ill-maintained system with expired user with full rights on it. Not only do these aspects pose a significant security risk, but also weighs down the IT-department, which probably can spend its time better on other tasks. The mentioned problems are very relevant in the Danish Department of the Environments (DOE) IT-department, the so called Center for Koncernforvaltning, Informatik department (CFK-I). The department uses a lot of time with simple user administration, not to mention the extra work that comes with wrongly created users, due to most of it being manually maintained. When changes to the organizational structure happens somewhere in the DOE, there is suddenly placed a lot of work on the people working with user administration. These people often are integral to other IT projects in the department, which in turn have to be postponed. To solve these problems the DOE s IT-department has chosen to start an Identity Management (idm) project based on Microsofts Identity Lifecycle Management Server (ILM). The goal of the project will be to make a connection between systems that share data, reduce redundant users accounts and free up resources in the IT-department for development of other technologies. The core of the project, the ILM server, will synchronize between the main user database Active Directory (AD) and a process tool called Omada Enterprise (OE). The OE system will be the entry point for the creation of new users or changes to existing accounts. The ILM server will make this possible. With time the plan is to integrate ILM with a larger set of systems used in the DOE. To facilitate this, the project will run over several phases, to ensure compatibility and minimize loss of work hours. The solution has to be future proof and module based, so extensions to the system can be added with relative ease. To this end a large part of the project will be classifying data and flow of data across the different systems.

ii Analysis o Analysis of work processes when changes happen to a user. o Analysis of data and data owners across the systems. Design o Defining of dataflow through ILM. o Defining of datachanges through the ILM metaverse. o Future-proofing of the system. Implementation o Proper installation of ILM server. o Implementing attribute flow on the ILM server. o Implementering rules extensions on ILM in C#.NET. In the project I ll try to design and implement a part of the functionality needed when creating a user. The current datamodel needs to be analyzed to see which attributes are relevant. Furthermore I need to determine if some of the attributes not currently used can be of use later and as such should be prepared for ILM synchronization. On the ILM server the management agents needs to be set-up and ekstended with extra functionality in the form of rules extensions, made in C#.NET. To facilitate the creation outside of AD, I will develop a web service. The webservice will check if the user is actually created before trying to create the external necessities for a new user. The Webservice will contain follow functions. Creation of Distributed File System links. Creation of a Personal network folder. Creation of Exchange mailbox. Enrolment in security groups. Adding Institution and department specific Active Directory attributes. Since the ILM license doesn t come cheap, it s important for CFK-I to get a solution developed that is easily reused or extended. In the report I will try to document if the ILM system is flexible enough for to develop a generic solution, that can easily be extended. The code needs to be properly documented, since CFK-I does very little development. A external contractor should be able to pick up where, I left.

iii Resumé De fleste virksomheder har i mange år parallelt implementeret en række forskellige It systemer uafhængigt af hinanden. Fælles for disse systemer er at de oftest ikke har interfaces til hinanden, de bruger hver deres database og har generelt ikke meget til fælles. Systemerne har vidt forskellig funktion da de yder en service knyttet til en afdeling; HR system til personale, Opgave tracking til It og etc. Disse systemer indeholder oftest de samme data, typisk i relation med brugeridentiteter og rettigheder. Dubletter af data over mange forskellige systemer gør administration besværlig da ændringer ofte skal indskrives manuelt. Chancen for at have åbne brugerkonti med arbitrære rettigheder på et system der ikke nødvendigvis er udbredt know-how om er således stor. Foruden det sikkerhedsmæssige aspekt, ser vi at almen brugeradministration tager en stor del af It afdelingens tid. De nævnte problemer er især aktuelle i Miljøministeriets It organisation Center For Koncernforvaltning - Informatik (CFK-I). I CFK-I bruges der lang tid på almindelig brugeradministration, udover de brandsluknings opgaver der følger med når meget af arbejdet er manuelt. Sker der organisatoriske ændringer i styrelserne kommer der en stor arbejdsbyrde på de medarbejdere der står for brugeradministration og forretningsudviklende It projekter må nedprioriteres. For at komme disse problemer til livs, har Miljøministeriets It og personale organisation Center for Koncernforvaltning besluttet at igangsætte et Identity Mangement (idm) projekt baseret på Microsofts produkt " Identity Lifecycle Management Server " (ILM). Formålet med projektet vil være at sikre sammenhæng mellem systemer der deler samme data, mindske redundans derimellem og dermed frigøre ressourcer i CFK-I til forretningsudvikling. Kernen af dette projekt bliver en ILM server der skal synkronisere mellem et Active Directory (AD) og processværktøjet Omada Enterprise (OE). OE systemet kommer til at være entry point for bruger-oprettelser/ændringer og nedlæggelser hvilket ILM skal gøre teknisk muligt. Med tiden skal ILM integreres i en stor del af de systemer der bliver brugt i Miljøministeriet, dette vil ske over flere faser og det er derfor vigtigt at fremtidssikre løsningen således at nye "moduler" kan integreres forholdsvist let. Der ligger således en stor del analyse i projektet med henblik på klassificering af data og data flows på tværs af systemer.

iv Analyse o Analyse af arbejdsprocesser ved ændring af en bruger o Analyse af data og data ejere på tværs af systemer Design o Definering af dataflow gennem ILM o Definering af dataændringer gennem ILMs metaverse o Fremtidssikring af systemet - Undgå at dette bliver endnu et sort hul Implementering o Opsætning af ILM o Implementering af regler for data flow på ILM o Implementering af extensions til regler på ILM i C#.NET I projektet vil jeg forsøge at designe og implementere en del af funktionaliteten som der skal bruges ved oprettelsen af en bruger. Nuværende datamodeller skal analyseres og det skal analyseres hvilke attributter der er relevante. Der er ydermere et arbejde i at identificere om visse attributter senere hen skal synkroniseres. På ILM serveren skal der opsættes management agenter og disse skal udvides med ekstra funktionalitet i form af rule extensions kodet i C#.NET. For at udføre oprettelsen uden for AD skal der udvikles der en web service. I web servicen kan der testes på om brugeren rent faktisk er oprettet i Active Directory, før det forsøges at udføre jobs der kræver en færdig AD konti. Web Servicen skal indeholde følgende funktioner. Oprettelse af Distributed File System links Oprettelse af Personlig mappe på filserver Oprettelse af Exchange Postkasse Indmelding i sikkerhedsgrupper Tildeling af institution og enhedsspecifikke AD attributter Da licensen til ILM ikke er billig, er det vigtigt for CFK-I at få udviklet komponenter der er let genbrugelige. Web servicen eller ILM koden, skal kunne udvides med yderlig funktionalitet når CFK-I vil koble flere systemer på - uden at man skal til at skrive det hele om. Jeg vil med rapporten forsøge at dokumentere om ILM systemet er fleksibelt nok til at man kan udvikle generelle løsninger, der senere kan udbygges. CFK Informatik er hovedsageligt en driftsafdeling og der er ikke nogen der aktivt laver udvikling. Derfor skal koden til systemerne være velbeskrevet, så udvidelser af systemet let kan overtages af konsulenter.

v Fordord Denne rapport er udarbejdet som afslutningen af min udannelse som IT diplom ingeniør på DTU. Opgaven er lavet med vejledning fra Klaus Theisen i samarbejde med Miljøministeriet / Center for Koncernforvaltning Informatik afdelingen. Hos Center for Koncernforvaltning har Jesper Nilsson været min kontaktperson. Projektet omhandler hvordan man implementere en Identity Management løsning baseret på Microsofts Identity Lifecycle Management Server.

vi Indholdsfortegnelse SUMMARY RESUMÉ FORDORD INDHOLDSFORTEGNELSE I III V VI 1. PROJEKT PLANLÆGNING 2 MILJØMINISTERIETS IT LEVERANDØR CENTER FOR KONCERNFORVALTNING 3 PROBLEMSTILLING 3 CASE EKSEMPEL 3 PROJEKTAFGRÆNSNING 4 TIDSPLAN 5 UDVIKLINGSMETODE 6 UNIFIED PROCESS 6 UML 7 2. ANALYSE OG DESIGN 8 KRAVSPECIFIKATION 9 OVERORDNET KRAVSPECIFIKATION 9 TEKNOLOGIER OG BEGREBER 10 ACTIVE DIRECTORY (AD) 10 IDENTITY LIFECYCLE MANAGEMENT SERVER (ILM) 12 OMADA ENTERPRISE (OE) 15 USE CASES OG SEKVENSDIAGRAMMER 19 AKTØRER 19 USE CASE 1 BESTILLINGEN I OMADA ENTERPRISE 21 USE CASE 2 IMPORT OG SYNKRONISERINGS SCHEDULERING 23 USE CASE 3 - IMPORT FRA OMADA ENTERPRISE 24 USE CASE 4 SYNKRONISERING AF OMADA ENTERPRISES CONNECTOR SPACE 25 USE CASE 5 EKSPORT TIL SOA MANAGEMENT AGENTENS WEBSERVICE. 26 DATAUDVEKSLINGSMODEL FOR ATTRIBUT FLOW 27 3. IMPLEMENTERING 29 UTILLITY CLASS - ILMUTILS 30 MATOOLS KLASSE 30 XML KLASSE 31

vii MANAGEMENT AGENTER OG EKSTENSIONS 33 REGEL EKSTENSION - IMASYNCHRONISATION OG IMVSYNCHRONISATION 33 EXSTENSIBLE EXPORT MANAGEMENT AGENTER 34 OMADA ENTERPRISE MANAGEMENT AGENT 34 ACTIVE DIRECTORY MANAGEMENT AGENT 42 METAVERSE REGEL EKSTENSION 43 WEBSERVICE MANAGEMENT AGENT 47 WEBSERVICES 50 SOA MANAGEMENT AGENT EXPORT WEBSERVICE 50 WORKER WEBSERVICE 52 4. TEST OG OPSÆTNING 55 TEST OG UDVIKLINGSMILJØ 56 RES OG ESDHROOT EKSPORT / IMPORT 57 AD TIL XML (CREATEXMLFROMENVIRONMENT.WSF) 57 XML TIL AD (CREATEENVIRONMENTFROMXML.WSF) 58 DFS 58 TESTPLAN 59 UDTRÆK FRA TEST 59 5. KONKLUSION 61 FORMÅL 62 RESUMÉ 62 EVALUERING 62 6. APPENDIKS 64 INTERFACE IMASYNCHRONISATION 65 INTERFACE IMVSYNCHRONISATION 66 INTERFACE - IMAEXTENSIBLECALLEXPORT 66 OMADA ENTERPRISE NY BRUGER I MIM PROCESS DIAGRAM 67 OMADA ATTRIBUT FLOW 67 DATAUDVEKSLINGSMODEL FOR ATTRIBUT FLOW 73 ILM STANDARD MANAGEMENT AGENTER 70 LISTE AF FIGURER 71 KODE MVROUTER.DLL METAVERSE ROUTING DLL 72

Kapitel 1 1. Projekt Planlægning

3 Projektplanlægning Miljøministeriets IT leverandør Center for Koncernforvaltning Problemstilling Dette enorme bagland af parallelle, ukompatible service systemer gør brugeradministration meget tung og gør en fælles sikkerhedsløsning og politik umulig. For at få gennemført en oprettelse, ændring eller deaktivering af en bruger skal bestillingen igennem en række vidt forskellige systemer. Til tider hvor administratoren har overtaget rollen fra specialisten der satte det op for 4 år siden, og ved meget lidt om systemet. I tilfælde af en fratrædelse bliver arbejdsgangen kun initieret, hvis den afgivende chef husker at få meldt det til IT afdelingen. I en større virksomhed giver denne samling af parallelle systemer en meget stor angrebsflade, hvor der let kan være ghost accounts i ikke vedligeholdte systemer. Fra udgangen af 2006 skal alle statens institutioner følge It-sikkerhedsstandarden DS-484 fra 2005. Denne standard er en baseline for statens IT sikkerhed og stiller nogle konkrete krav til institutionens sikkerhedsforanstaltninger, samt styring af It-sikkerhedsindsatsen. I standarden stilles der bl.a. krav til etableringen af et sikkerhedssystem udspecificeret således: " Sikkerhedsstyringssystemet er det centrale i sikkerhedsimplementeringen og indebærer bl.a., at ansvarsplacering, tildeling af privilegier, anskaffelser og samarbejde med andre organisationer sker efter It-sikkerhedspolitikkens overordnede retningslinjer. Systemet skal være dokumenteret skriftligt. " Dette nødvendiggør en fælles struktureret måde at administrere disse systemer, hvor man med sikkerhed kan placere et ansvar og hvor en ændring af en bruger er metodisk beskrevet og implementeret i både arbejdsgang og teknik. Case Eksempel Dette er en typisk bestilling på oprettelse af en bruger i Miljøstyrelsen. Bestillingen ville tidligere komme igennem fejlmeldingssystem IT afdelingen bruger. " Brugeren "Anders Johansen" skal oprettes - Han skal oprettes som en standard bruger med adgang til Navision (Økonomi), TAS (Jagttegn), GISdata (Fileshare). Derudover skal han have adgang til at installere MapInfo Pro, Adobe Elements 4.0 og have en VPN forbindelse. " Selvom dette er en typisk bestilling berører den mange forskellige mennesker og systemer. Når hver rettighedsgiver har udført deres job bliver den givet videre til næste i rækken. Første hegn er korrektheden af information; Har bestilleren ret til at bestille dette? Er informationen korrekt ("Standard" bruger, Navn)? Selve brugeroprettelsen sker gennem et værktøj udviklet eksternt; værktøjet har nogle bugs og der er derfor en del manuelt arbejde alligevel. Det giver spildt tid hos IT afdelingen med administration, som består i at taste fra et system fra et andet. Hvis der er travlhed med andre opgaver risikere man fejl, og der kan opstå sikkerhedshuller i forbindelse med fileshares og

4 Projektplanlægning sikkerhedsrettigheder. Navision og TAS adgang bliver givet i IT for derefter at gå videre til folk i andre afdelinger der herefter giver individuelle rettigheder. Projektafgrænsning Jeg vil i projektperioden benytte mig af iterative udviklingsmetoder, ved konstant at gå igennem Design, Implementering og Test faser. Dermed sikre jeg den bedst mulige løsning, der stemmer overens med et sikkert design. Da projektet favner om mange forskellige mindre dele, vil jeg dog nok ikke kunne nå det hele. Derfor har opsat denne liste af prioriterede moduler der skal virke ved projektets slutning. Disse er udvalgt specifikt efter hvad der skal til for at få et minimums scenarie op at køre. Under projektet, blev vi enige om at droppe indmeldingen i sikkerhedsgrupper selvom det havde været et krav fra starten. Jeg havde ikke tid til at implementere det og CFK-I mente ikke de kunne understøtte det. Høj Prioritet o Import af brugere fra Omada Enterprise o Eksport af brugere til AD o Oprettelse af file shares o Oprettelse af exchange mailbox Mellem / Lav Prioritet o Indmelding i Captia sikkerhedsgrupper

5 Projektplanlægning Tidsplan Min tidsplan er vedlagt i Appendiks under Tidsplan for projektet.

6 Projektplanlægning Udviklingsmetode Unified Process Jeg har i projektet benyttet mig af Unified Process (UP) som arbejdsform. Unified process var velegnet til dette projekt, da det indeholder små separate artefakter som kan fungere og testes adskilt. Foruden det har jeg arbejdet med metoden før og skulle derfor ikke til at lære nye arbejdsgange, der kunne tage tid væk fra projektet. UP som metode bygger på at man har små iterative udviklingsfaser, og en relativ kort indledende design fase. Man begynder derfor relativt tidligt med at have små testbare stykker software. Dette giver mulighed for at ændre specifikationen hvis kunden eller en selv opdager at det der blev lavet ikke lige var det man ledte efter. Det var vigtigt for mig at kunne gå tilbage og ændre hvis der var noget der ikke var tilfredsstillende, uden at det betød at en stor del af designet skulle lave om. Unified process giver også en del frihed til hvordan man vil strukturere projektet, man behøver ikke bruge alle dets metoder eller faser, så længe den overordnede idé om iterativ analyse, design og implementering bliver overholdt. Især i forbindelse med et eksamensprojekt hvor der er en fast deadline giver det en bedre idé om hvor meget man er nået. Diagrammet herunder viser en guideline for hvordan tiden skal forbruges i et UP projekt. Min egen tidsplan har jeg også forsøgt at indele efter UP principperne, således at jeg vidste ca. hvor lang tid jeg havde til hver del. Figur 1 - Unified Process Tidsline

7 Projektplanlægning UML I forbindelse med min analyse har jeg brugt UML, som er standarden de fleste steder for at repræsentere objekt orienterede designs. UML giver ligesom UP stor frihed inden for hvordan man laver siden diagrammer, så længe de overordnede principper er overholdt. Jeg har i projektet benyttet System Sekvens Diagrammer for at beskrive mine Use cases visuelt. Disse hjælper en del til at vise hvordan systemerne interagere med hinanden. Der er brugt Klassediagrammer til at eksponere klassehiraki og indeholdte metoder. Sidst men ikke mindst bruger jeg Sekvens Diagrammer til at vise hvordan klasserne kalder hinanden.

Kapitel 2 2. Analyse og Design

9 Analyse og design Kravspecifikation CFK-Informatik har et ønske om at automatisere deres del af Miljøministeriets brugeroprettelsesprocess. På nuværende tidspunkt startes processen på intranet siden Omada Enterprise, hvorefter opgaver uddelegeres af systemet og løses manuelt. Det ønskes at en del af det der på nuværende tidspunkt bliver løst manuelt i AD nu er integreret i opretttelsen. En in-depth beskrivelse af Omada Enterprise og dets funktion kan ses på side 15. Overordnet Kravspecifikation Dette afsnit er en punktliste CFK-I ønsker at der som basis er undestøttet af systemet, indelt efter kategori. Tekniske krav og forbehold o Systemet skal være på Microsoft platform. o Systemet skal have gode logning faciliteter så fejlfinding er let. o Oprettelse af brugere i AD som det forgår nu, skal være muligt. Funktionelle krav o Oprettelse af personligt drev. Indebærer oprettelse af 2 nestede mapper. o Rettigheder skal sættes på rod mappen. o Mappen bliver oprettet på en server nær brugerens lokation 1 Tildeling af standard (for styrelse enhed) netværksmapper. o Indmelding i sikkerhedsgruppe(r). o Oprettelse af DFS links. o Oprettelse af email addresse / mailbox. o Der skal generes en adgangskode i henhold til DS-484. o Hvis brugeren oprettes med en udløbsdato skal denne propagere til AD m.v. o Brugeren bliver indplaceret korrekt i AD efter styrelse. 1 Vælges i Omada Enterprise ved bestillingen

10 Analyse og design Teknologier og begreber Active Directory (AD) Active Directory er et Microsoft udviklet directory service produkt baseret på LDAP. Det er grundstenen for Microsofts infrastruktur produkter og integrere med de fleste, hvis ikke alle, deres produkter. LDAP betyder Lightweight Directory Access Protocol, som bliver brugt I en del forskellige applikationer til søgning og modifikation af directory (hierarkisk) ordnet data. Active Directory stiller en række services tilgængelig for domænet, bl.a. Kerberos baseret autencitet, DNS og gruppepolitikker. Et AD inddeler objekter i undergrupper, kaldet Organisational Units (OU). Disse strukturer kan ordnes hierarkisk som et normalt mappebaseret filsystem. Der er visse standard grupper og strukturer i et domæne, men ellers kan man frit opbygge det efter ens organisationsstruktur. Miljøministeriets infrastruktur bygger på Active Directory og bruges til logon på computerne, adgangskontrol på filer, intranet m.v. De fleste af Miljøministeriets systemer er single sign-on integreret via AD. Objekter De objekter som AD holder styr på har 3 forskellige kategorier: Ressourcer såsom printere og computere. Services som email og dfs. Brugerobjekter og sikkerhedsgrupper til brugerstyring. AD holder på data om disse objekter via det der kaldes et Schema. Schemaet definere objekttyper og hvilke attributter hvert objekt har tilgængeligt. Dette kan udvides efter behov for at give plads til nye attributter. Typiske objekter som brugere, sikkerhedsgrupper, computere m.v. har dog i forvejen en meget stor portefølje af brugbare attributter fra starten af. Der er også, af Microsoft, givet en række best practice eksempler på hvordan man udnytter disse objekter og deres attributter bedst og mest standardiseret. Derfor bruges skemaudvidelser ofte sjældent og først efter en stor del planlægning, da udvidelserne ikke kan fjernes igen og påvirker alt i domænet. Via den hierarkiske struktur kan adgangskontrol og gruppepolitikker specificeres, således at brugerobjekter i en OU bliver mødt med et baggrundsbillede, eller andre indstillinger der er specifikt til dem.

11 Analyse og design Forrests, træer og domæner En forrest er den termen for hele strukturen af domæner og underdomæner. En forrest indeholder en eller flere top level domæner, med sub-domæner længere nede i strukturen. Disse domæner deler det samme Schema, og fungere som endnu en måde hierarkisk at strukturere ens infrastruktur på. Domænerne er linket sammen i et netværk er af trust, som definerer hvordan domænerne må interagere med hinanden. I Miljøministeriet er der defineret en forrest med to domæner i, et top level domæne som indeholder administrative brugerkonti, DNS, og andre services der holdes adskilt fra resten af ressourcerne. Dette domæne har trust til og fra andre eksterne domæner fra andre offentlige instanser, som er løst affilierede med Miljøministeriet, men alligevel kræver integration med nogle af deres services. Under dette domæne ligger ressource domænet, som indeholder alle computere, brugere, email accounts m.v. Disse er ordnet hierarkisk i OU der tilsvarer miljøministeriets organisatoriske struktur. Via denne struktur bliver brugere og computere tildelt de indstillinger, der er nødvendige for dem i deres relevante styrelse eller enhed. Begge disse domæner har hver deres set af domæne controllere (DC). Domæne Controllerne indeholder en kopi af det Active Directory som er tilhører domænet, og replikeres rundt mellem dem for at sprede belastningen. Foruden at indeholde AD databasen bliver FSMO (Flexible Single Master Operations) oftes delt ud på flere af domæne controllerne. Tabel 1 - Active Directory FSMO roller Navn Beskrivelse Schema Master Holder Schemaet for forrest en og sørger for opdateringer og ændringer af det. Der er kun en Schema master for hele forrest en. Domain Naming Styrer tilføjelser af nye domæner og nedlæggelser af gamle for hele forrest en. Der er Master PDC Emulator RID Master Infrastructure Master kun en DN master for hele forrest en. Er tids server for domænet og indeholder også funktioner til bagud kompatibilitet med NT4 klienter. Der er en pr. domæne som er synkroniseret med top level domænets PDC Emulator. Står for generering af AD objekters unik ID disse kaldes GUID (Globally Unique Identifier). Der er én pr. domæne. Står for at synkronisere gruppemedlemskaber på tværs af domænerne. Der er én pr. domæne.

12 Analyse og design Identity Lifecycle Management server (ILM) Identity Lifecycle Mangement Server eller ILM, er et Microsoft udviklet identity management produkt. Identity Management (idm) er vedligeholdelsen af digitale identiteter i IT-systemer, såsom oprettelse af en identitet, opdatering og nedlæggelse. ILM serveren er et stykke teknologi der forsøger at samle alle IT-systemers digitale identiter til en samlet identitet, hvorfra ILM så kan holde alle systemer tilsluttet opdateret med ændringer. Diagrammet herunder viser et eksempel på hvilke systemer der kan tilsluttes en ILM server. Figur 2 - Diagram af ILM centreret infrastruktur 2 Selve ILM serveren fungerer ikke som interface til ændringer af brugerobjekter, men man opsætter i stedet regler for hvilke data-udbydere 3 der opretter brugerne, ændrer attributter eller nedlægger dem. Dermed kan en data-udbyder fungere som administrativt interface for disse objekter, selvom de bliver oprettet i et andet system og derefter er provisioneret ud til resten. Fordelen ved ILM som løsning er at den ikke kræver andet end selve serveren kørende, der skal ikke installeres andre drivere eller plugins på de systemer den integrere med. Den skal bare have adgang til at importere data de tilsluttede systemers databaser. Rent teknisk kræver ILM 2007 en Windows 2003 Extended Edition server og databasen bliver gemt i MS SQL server 2003 el. 2005. 2 Taget fra http://www.microsoft.com/windowsserver2003/technologies/idm/ilm.mspx (c) Microsoft. 3 Kaldet Connected Datasource eller Connected Directory i ILM termer.

13 Analyse og design Connector Space og Metaverse I ILM serveren har hver data-udbyder det eget databaseområde kaldet et Connector Space (CS). I Connector Space bliver dataobjekter fra udbyderne importeret, før de bliver introduceret ind i ILM serverens hoveddatabase. Ved en synkronisering af den pågældene data-udbyders management agent, sammenlignes (Joines) et objekt i CS 4 med Metaverse objekterne ud fra en unik nøgle valgt i management agenten. Dermed registrerer ILM serveren at dette objekt er sammenligneligt med et Metaverse objekt, og opretter hvad der kaldes en connector. Metaverse objektet kan have connectors til objekter på mange forskellige systemer og er koblingen mellem dem. Hvis ikke der findes en kandidat til en Join, bliver der under synkroniseringen projekteret det nye objekt, til de andre systemers Connector Space og til Metaverse. Under synkroniseringen er der samtidigt mulighed for at attributter i CS bliver ændret, via Rules Extensions 5. I visse tilfælde ønsker man ikke et system tillader Joins eller Projekteringer, det kan man selv sætte op i det pågældende systems Management Agent. Metaverset tillader at man kan opbygge sine egne objekttyper og selv definere attributter de indeholder. Man bruger Metaverse objektet til at aggregere de informationer der skal deles mellem de forskellige systemer. Der er derfor en del redundant data pr. bruger, men til gengæld har man meget bedre kontrol over sine brugere. Tesen er at når der skal nedlægges en bruger, kan man fjerne dem fra alle systemer på en gang et problem firmaer med stor infrastruktur kæmper meget med. 4 Kaldes CSEntry i ILM termer. 5 På dansk Regel Ekstensions.

14 Analyse og design Management Agenter En Management Agent facilitere forbindelsen fra ILM serveren til data-udbyderen. I praksis er det et sæt indstillinger om hvorledes der importeres, eksporteres og modificeres objekterne. I brugerfladen for identity manageren 6 har man mulighed for at opsætte agenterne. Med serveren følger der management agenter til 27 af de mest typisk brugte systemer 7. Microsoft har dog stillet interfaces til rådighed, således at man selv kan udvikle Management Agenter til systemer der ikke er support for som standard. Der kan endda eksporteres Visual Studio 2005 projekter fra serverens management software, klar til at udvikle på. ILM serveren understøtter call baserede forbindelser til at kalde data-udbyderne. Dog kan den også skrive og læse fra filer på en server, hvis ens data-udbyder ikke understøtter import / eksport kald. Extensible Connectivity Management Agenter I hvis man har behov for at koble en Management Agent på et system der ikke er understøttet af standard agenterne, kan man udvikle sin egen connector. Der er stillet interfaces til rådighed som man skal implementere for både fil og call baserede systemer. Når man har implementeret interfacet compiles det til en DLL som vedhæftes management agenten. I forbindelse med eksport til denne data-udbyder, vil denne DLL benyttes. For at vide hvilke attributter der er til rådighed skal der ved oprettelsen af denne MA gives en fil med data-udbyderens skema. For Extensible Connectivity MA tillader ILM kun fil baseret import. Regel ekstensions I mange tilfælde er det nødvendigt at en objektattribut fra en data-udbyder skal ændres, før denne bliver gemt på Metaverse objektet. Et eksempel kunne være et brugerobjekt fra en dataudbyder holder to adskilte attributter; telefonnummer og land. I Metaverse kan man anse det for nødvendigt have et telefonnummer med en foranstillet landekode. I forbindelse med attribut flow fra Connector Space til Metaverse, kan man med en Regel Ekstension lave et opslag på landenavnet til en telefonkode og pre-fikse dette til telefon attributten. Dette gemmes så i Metaverse som brugerens telefonnummer. På samme måde som Extensible Connectivity MAer er der et interface man skal implementere, hvor man selv kan lave de transformationer man vil mellem Connector Space og Metaverse attributterne. Den handling hvor attributter bliver flyder fra CS MV CS kalder man attribut flow. 6 Applikation til at administrerer ILMs Management agenter, Metaverse, m.v. 7 Se Appendix ILM Standard Management Agenter.

15 Analyse og design Metaverse Ekstensions Man kan ligesom Managment Agenterne også udvide sit Metaverse med en ekstension. Igen skal man implementere sin egen version af et interface. Denne ekstension giver mulighed for styre hvordan objekter bliver provisioneret til de forskellige connector spaces. I visse tilfælde kan man have en meget stor ILM løsning hvor gerne vil splitte denne provisionerings kode op i flere mindre ekstensions. Dette kan også lade sig gøre ved at implementere en routing DLL der sekventielt, eller efter et regelsæt, kalder de implementerede ekstensions. Omada Enterprise (OE) Omada Enterprise er et danskudviklet processtyrings system. Det bliver i miljøministeriet brugt til brugerhåndtering, hovedsageligt IT, men ved oprettelser også brugt til bestilling af skriveborde m.v. Systemet er webbaseret og alle medarbejdere har adgang til at gå ind og se hvilke processer der er tilgængelige. Det er meget fleksibelt system og bliver andre steder brugt til helpdesk og service request bestillinger, baseret på ITIL principper. De første processer bliver typisk lavet i samarbejde med konsulenter fra Omada, men derefter er det meningen man selv skal kunne vedligeholde dem. Man kan også selv oprette nye processer, der ikke nødvendigvis har noget med de gamle at gøre. Omada har lavet nedenstående diagram der beskriver hvordan de ser en arkitektur baseret på Omada Enterprise ser ud. I Miljøministeriets løsning er der dog kun Omada Workflow designer modulet. Figur 3 - Omada Enterprise Modul Diagram