Innhold
1 Om dokumentet
Status: Under utarbeiding
| Dato | Status |
|---|---|
| 2014-12-19 | Laga user stories etter intern gjennomgang hos USIT. Trengde å få meir klarhet i kva dei faktiske behova var. Laga også utkast til løysingsforslag på systemnivå, etter kva USIT ser for seg, og døme på API for dette. |
| 2015-01-13 | La til alternativt løysingsforslag, med powershell-kommandoar som API |
2 Behova til UiA for Office 365
Vi har laga nokre user stories for å dekke behova UiA har:
Som UiA-IT vil eg at Office365 skal få vite frå Cerebrum om endringar for entitetar som er relevante for Exchange og Office365. Dette så Office365 kan oppdaterast riktig for desse entitetane.
Substories:
- Som UiA-IT vil eg at Office365 skal få vite om ein brukar skal ha tilgang til Office365 (lisens). (Dette er uavhengig av kor postboksen er plassert).
- Som UiA-IT vil eg at Office365 skal få vite om ein brukar skal miste tilgangen sin til Office365 (lisens). (Dette er uavhengig av kor postboksen er plassert).
- Som brukar må eg få mine e-postdata oppdatert i Cerebrum med hensyn til plasseringa av min postboks. Dette gjeld nytt MailTarget, nye e-postadresser og nytt server-namn.
- Som UiA-IT vil eg at Office365 skal få beskjed når ein brukarkonto/person får oppdatert/endra sine metadata i Cerebrum. Med metadata meinast her endringar i e-postadresser, namn, vidaresendingar, kvoter og anna.
- Som UiA-IT vil eg at MX skal få informasjon om at brukarar som har fått flytta postboksen sin. Dette så UiA kan rute e-post til riktig stad.
- Som UiA-IT vil eg at Office365 skal få vite om brukarar som skal ha postboks i Office365. Dette så UiA-IT kan opprette ein postboks i Office365.
- Som UiA-IT vil eg at Office365 skal få vite om brukarar som får endra postboksen sin frå Exchange til Office365. Dette så UiA-IT kan migrere postboksen til skya.
- Som UiA-IT vil eg at Office365 skal få vite om brukarar som får endra postboksen sin frå Office365 til Exchange. Dette så UiA-IT kan migrere postboksen til on premise.
- Som UiA-IT treng eg å vite om brukarar som vert avvikla, så eg kan rydde opp i postboksar og anna relatert til kontoen.
Som studentbrukar skal eg automatisk bli markert for Office365 når eg vert registrert som aktiv student.
TODO: UiA må svare på om det er andre brukarar som skal automatiserast?
Som brukar skal eg ikkje få tilgang til Office365 utan at eg allereie eksisterer i AD.
Som UiA-admin skal eg kunne administrere brukarar manuelt i Cerebrum for relevante endringar for Office365/Azure.
Substories:
- Som UiA-admin skal eg kunne manuelt markere at brukarkontoar skal få postboksen sin oppretta eller migrert til Office365. (Brukargrensesnitt? Manuelle registreringar i Cerebrum?)
- Som UiA-admin skal eg kunne styre lisensar i Cerebrum. TODO: UiA må bekrefte/avkrefte om dette er eit behov.
2.1 Eventuelt/framtidig
Som brukarkonto skal eg også kunne bli markert for tilgang til å kunne laste ned Office-pakken og installere denne lokalt. Dette vil vere tilgjengeleg i Azure i 2015.
TODO: UiA må bekrefte/avkrefte om dette er ønskeleg å ha funksjonalitet for.
3 Løysingsforslag
Vi er ikkje komne langt nok til å utarbeide eit løysingsforslag, men vi ser for oss systemoversikten:
Endringsforslaget er markert i raudt.
USIT ønsker ikkje å blande seg for mykje inn i Powershell og AD/Azure-tekniske detaljar i integrasjonen. Cerebrum tar ansvar for å automatisk varsle UiA om endringar for brukarkontoar og andre entitetar, og så tek UiA seg av å oppdatere Office365, og evt. Exchange, basert på denne informasjonen.
USIT ser for seg at UiA har ein REST-webservice ståande på si side som kan motta oppdatert informasjon og oppdatere alle UiA sine system. Det viktigaste her, er at det går eit skille mellom kva Cerebrum utfører og kva systema i UiA sitt miljø gjer.
Fordelar med ei slik løysing:
- Bedre og reinare arkitektur, i henhold til DIFI sine arkitektur-prinsipp.
- Skillet gjer at UiA vert mindre avhengig av USIT, og står fritt til å gjere endringar i PS-kommandoar og oppsett på si side, utan å måtte gå via USIT og vente på svar. Dette vil føre til raskare utvikling, både hos UiA og USIT.
- For Cerebrum vil det bli ei mindre kompleks løysing. Cerebrum fokuserer på det Cerebrum kan og er bygd for, og blander seg ikkje i detaljane i AD, som UiA er gode på.
- Løysinga kan gjenbrukast av andre Cerebrum-instansar, sidan integrasjonen vert lik. Kommandoane som webservicen utfører er riktignok ulik per instans, men API-et og oppdateringane vil vere dei samme.
Framtidig arbeid etter ein overgang til nytt løysingsforslag:
- Flytte eksisterande Exchange-integrasjon over på ny webservice
- Flytte eksisterande AD-integrasjon over på ny webservice
3.1 Alternativt løysingsforslag
Etter tilbakemeldingar frå UiA har vi eit alternativt løysingsforslag:
Endringsforslaget er markert i raudt.
Her er webservicen på AD-sida bytta ut med eit sett av powershell-kommandoar. Namn og parameter til powershell-kommandoane skal vere veldefinerte, og kan då tolkast som eit grensesnitt mellom USIT og AD, eit API. Vi vert saman enige om API-et, Cerebrum har ansvar går fram til å starte kommandoane, og UiA har ansvar for innholdet i kommandoane.
Definisjonen av API-et vert det samme, uavhengig av om det implementerast gjennom ein WS eller i Powershell.
Dette er ein noko meir komplisert integrasjon, då powershell-skript ikkje er så veldefinerte og strikte som i ein Webservice, spesielt rundt feilhandtering. Skript kan til dømes avsluttast grunna feil, utan å gje tilbakemelding til Cerebrum om at det feila.
3.2 API
Dette er eit veldig tidleg og ufullstendig utkast til API-funksjonalitet som trengs for integrasjonen, og er meint å hjelpe med forståinga av korleis det er tenkt frå USIT si side. Det er ikkje meininga å diskutere detaljane i dette før det overordna er spesifisert.
Cerebrum definerer API-et til webservicen, og UiA definerer kva webservicen deretter skal gjere med denne informasjonen, i sitt miljø.
API-et inneheld kommandoar som Cerebrum kaller på for kvar hending:
- Brukar oppretta: Cerebrum fortel WS at ein gitt brukar er blitt oppretta, og sender med brukardata. Det er opp til UiA å definere kva som skal gjerast basert på denne hendinga.
- Brukar avvikla: Cerebrum fortel WS at ein gitt brukar er blitt avvikla, og sender med brukardata. Det er opp til UiA å definere kva som skal gjerast basert på denne hendinga - til dømes kan postboksen arkiverast og slettast frå systemet.
- Brukar har fått oppdatert tilgangsstyringa si (spread): Cerebrum fortel WS at ein gitt brukar har fått oppdatert sine tilgangar for andre IT-system. Cerebrum sender med brukardata, og kva IT-system det er snakk om. IT-systemet kan til dømes vere Office365, Exchange eller AD. Det er opp til UiA å definere kva som skal gjerast med brukaren - til dømes kan ein postboks opprettast i Office365 (eller Exchange), avhengig av kva IT-system hendinga gjeld.
- Brukar har fått fjerna ei tilgangsstyring (spread): Cerebrum fortel WS at ein gitt brukar har mista ein tilgang til eit gitt IT-system. UiA definerer kva som skal gjerast for Office365.
- Person har fått oppdatert sine namn: Cerebrum fortel WS at ein person har fått oppdatert eit av namna sine, og legg med relevante namn. UiA kan bruke dette til å eventuelt oppdatere andre system.
- Brukar har fått oppdatert sine e-postadresser: Cerebrum fortel WS at ein gitt brukar har fått lagt til eller fjerna ei e-postadresse, og sender med adressa. Det er opp til UiA å definere kva som skal gjerast med informasjonen, og korleis oppdatere Office365 med endringa.
Det vil vere behov for meir funksjonalitet enn dette.
3.2.1 Endringar frå Cerebrum
Ein oversikt over nokon av endringane i Cerebrum, som kan brukast for å trigge kall frå Cerebrum mot API-et.
Standard endringstypar (frå CLConstants.py:
- account_create
- account_delete
- account_home_added
- account_home_removed
- account_home_updated
- account_mod
- account_password
- account_password_token
- account_type_add
- account_type_del
- account_type_mod
- disk_add
- disk_del
- disk_mod
- entity_add
- entity_addr_add
- entity_addr_del
- entity_cinfo_add
- entity_cinfo_del
- entity_del
- entity_ext_id_add
- entity_ext_id_del
- entity_ext_id_mod
- entity_name_add
- entity_name_del
- entity_name_mod
- entity_note_add
- entity_note_del
- group_add
- group_create
- group_destroy
- group_mod
- group_rem
- guest_create
- homedir_add
- homedir_remove
- homedir_update
- host_add
- host_del
- host_mod
- ou_create
- ou_del
- ou_mod
- ou_set_parent
- ou_unset_parent
- person_aff_add
- person_aff_del
- person_aff_mod
- person_aff_src_add
- person_aff_src_del
- person_aff_src_mod
- person_create
- person_name_add
- person_name_del
- person_name_mod
- person_update
- posix_demote
- posix_group_demote
- posix_group_promote
- posix_promote
- quarantine_add
- quarantine_del
- quarantine_mod
- quarantine_refresh
- spread_add
- spread_del
E-postrelaterte endringstypar (frå Email.py):
- email_dom_add - Add domain
- email_dom_rem - Remove domain
- email_dom_mod - Modify domain
- email_dom_addcat - Add category in email domain
- email_dom_remcat - Remove category in email domain
- email_target_add - Add email target
- email_target_rem - Remove email target
- email_target_mod - Modify email target
- email_address_add - Add email address
- email_address_rem - Remove email address
- email_entity_dom_add - Add domain aff
- email_entity_dom_rem - Remove domain aff
- email_entity_dom_mod - Modify domain aff
- email_quota_add - Add quota
- email_quota_rem - Remove quota
- email_quota_mod - Modify quota
- email_tfilter_add - Add target filter
- email_tfilter_rem - Remove target filter
- email_sfilter_add - Add spam filter
- email_sfilter_mod - Modify spam filter
- email_scan_add - Add virus scan
- email_scan_mod - Modify virus scan
- email_forward_add
- email_forward_rem
- email_forward_enable
- email_forward_disable
- email_vacation_add
- email_vacation_rem
- email_vacation_enable
- email_vacation_disable
- email_primary_address_add
- email_primary_address_rem
- email_primary_address_mod
- email_server_add
- email_server_rem
- email_server_mod