Bilag 2 Kundens IT-miljø

Bilag 2 Kundens IT-miljø

Indholdsfortegnelse 1. GENERELT... 2. KU S SYSTEMLANDSKAB OG INTEGRATIONEN TIL DETTE... 3. DATATILGANG... 4. SSO... 5. ADMINISTRATION AF BRUGERE OG BRUGERRETTIGHEDER... Side 2/5

[Vejledning til tilbudsgiver i forbindelse med udarbejdelse af tilbud Formålet med dette bilag er at give et overblik over den IT-infrastruktur, der anvendes hos Kunden. Dette skal bidrage til at sikre at tilbudsgiver er tilstrækkeligt orienteret omkring hvordan den tilbudte løsning skal integreres med Kundens IT-arkitektur. Bilaget skal ikke udfyldes af tilbudsgiver Bilaget udgør et mindstekrav (MK), som tilbudsgiver ikke kan tage forbehold over for, jf. udbudsbetingelsernes punkt 3.2.3.2. Afsnit med kursiv slettes inden tilbudsafgivelse.] 1. GENERELT Dette er en beskrivelse af KU s it-miljø. Systemet skal driftes uden for KU s driftsmiljø. Der er derfor en række elementer i KU's arkitektur, som det derfor ikke er relevant at beskrive. Systemet skal dog integrere med flere af KU s systemer og skal derfor kunne passe ind i KU s målarkitektur for integrationer, jf. nedenfor. 2. KU S SYSTEMLANDSKAB OG INTEGRATIONEN TIL DETTE KU s systemarkitektur er baseret på en service- og hændelsesorienteret arkitektur. For at opnå separation of concerns samt løskobling mellem software-applikationer har KU valgt et Service Orienteret Arkitektur paradigme (SOA). Løskoblingen skal her tænkes teknologisk og temporalt såvel som organisatorisk. På KU tager forståelsen af SOA udgangspunkt i at gøre kildesystemerne (Providers) løskoblet fra andre systemer (Consumers). Med løskoblet menes, således at Consumers hverken tilgår kildesystemernes API er direkte eller på anden måde kender til kildesystemernes interne objekter og forretningslogik. Målarkitekturen på KU tilskriver, at alle integrationer behandles løskoblet, og at data udveksles gennem en fælles datamodel. Derudover lægges der vægt på, at de services, der udstilles, er forretningsorienterede frem for dataorienteret (simple CRUD). Den praktiske udfordring i SOA er grundlæggende at lukke gabet mellem de servicespecifikationer, der findes i organisationens kildesystemer, og de servicespecifikationer, der er behov for i en Service Orienteret Arkitektur. På KU er SOA-paradigmet implementeret med en SOAsuite, som er en samling af teknologier og services, der tilsammen udgør det middleware, der kan lukke dette gab. Service-bussen er et centralt arkitektonisk komponent i forhold til at levere de ønskede servicespecifikationer. Side 3/5

Alle integrationer skal så vidt muligt udstilles som Webservices (enten SOAP eller REST) med interface beskrevet med WSDL. Hændelsesorienteret arkitektur løses vha. SOAP-/WSDL- eller REST-webservices og JMS-topic og/eller -køer eller lignende teknologi. Københavns Universitet benytter Oracle Business Intelligence Suite som datavarehus. Data hentes fra CSV-filer ved natlig kørsel. Systemlandskabet er præget af en række forskellige platforme, teknologier og leverandører. Det er derfor vigtigt, at der benyttes gængse standarder. Hvad angår teknologier er det afgørende, at systemet er klientneutralt. Det skal kunne afvikles på gængse browsere og på tværs af forskellige operativsystemer (Windows, Apple, Linux), gerne med evt. selvbetjeningsbrugerflader tilgængelige på tablets og smartphones (Android, Windows 8, IOS) 3. DATATILGANG Integrationer kan implementeres, så Systemet henter data fra en KU-service, når der er behov herfor. Alternativt kan Systemet indeholde kopi af data, men dette er ikke den fortrukne model. Det kræver så, at systemet rummer mekanismer til løbende at sikre datas kvalitet. Når der er behov for, at Systemet udstiller data for KU, skal dette ske via et API, både hvor der er behov for enkeltopslag, og hvor der er behov for større batches. 4. SSO Da KU har behov for centralt at kunne sikre og kontrollere, at kun de brugere, som er berettiget til at få adgang, har den nødvendige adgang, skal der benyttes SSO (se mindstekrav 3.1 & 3.2 i Kontraktbilag 4), der i sammenhæng med KU s identitetsstyringssystem (IDM/IAM), sikrer en centraliseret styring, hvilke brugere der skal have adgang til systemet, samt hvilken rolle (med tilhørende rettigheder) en given bruger skal have i systemet. I nogle situationer, fx ved personalesager, skal det være muligt med kort varsel at sikre, at en bruger fratages retten til at tilgå alle de systemer, som denne tidligere havde adgang til, fx for at sikre integriteten af data. I dag anvender KU s arkitektur SUN IDM (p.t. Der er et nyt system på vej) til styring af brugergrupper og rettigheder i AD. KU understøtter SSO gennem følgende tre komponenter: Active Directory Federation Services (ADFS) Active Directory (AD) Azure Active Directory (AAD) Side 4/5

Det foretrukne paradigme på KU er claims-basseret SSO. Ved claims-baseret SSO stilles der følgende krav til it-løsningen; It-løsningen skal kunne validerer og parse de attributter (claims), der er indeholdt i den udstedte security token, som KU s IDP udveksler. Følgende standarder kan benyttes i prioriteret rækkefølge: 1. SAML 2.0 2. WS-Federation 3. OAuth 4. OpenID Connect 5. OpenID 2.0 5. ADMINISTRATION AF BRUGERE OG BRUGERRETTIGHEDER Identiteter og roller til rettighedsstyring af identiteter i Systemet skal komme fra KU s fælles identitetsstyringssystem. Brugernavnet tilknyttet til hver identitet med det tilhørende password, skal ligeledes komme fra KU s fælles identitetsstyringssystem. Side 5/5