Direktoratet for IKT og fellestjenester i høyere utdanning og forskning

Transkript

1 Direktoratet for IKT og fellestjenester i høyere utdanning og forskning

2 Brukerhåndtering i Alma Et smertens kapittel Er det utsikter til forbedring? Per Hovde, strategirådgiver Unit

3 Litt bakgrunn for problemstillingen (brukerimport) Alma er basert på at autorisasjonsdata (roller som styrer hvilke oppgaver brukeren kan utføre) må lagres i Alma (en brukerprofil i tjenesten) til forskjell fra en mer moderne måte å håndtere autorisering på, hvor autoriseringsdata lagres kun i primærkilden (i brukerprofilen i institusjonen hvor brukeren har sin tilhørighet) og hentes som en del av innloggingen og knyttes til innloggings-sesjonen Tjenesten trenger da ikke å lagre noen autorisasjonsdata om brukeren eller trenger i prinsippet ikke å ha noen kjennskap til brukeren i det hele tatt Men hva med lånehistorikk?

4 Autentisering og autorisering i Alma/Oria Brukernavn og passord Bruker Påloggingslenke Innlogget Alma / Oria edupersonprincipalname matches mot University ID for å kople til riktig brukerprofil Feide

5 Autorisering som ikke forutsetter lagring av autorisasjonsdata i tjenesten Tilgangsbeskyttede tjenester Bruker Innlogget Innloggingslenke (sesjonsdata) Service Service Service Provider Provider Provider (SP) (SP) (SP) Identity Provider (IdP)

6 Kryssføderert identitetshåndtering Bruker Innloggingsforespørsel Service Service Service Provider Provider Provider (SP) (SP) (SP) Tilgangsbeskyttede tjenester Identity Provider (IdP) Identity Store Kryssføderering Oauth 2.0 SAML 2.0 FEIDE

7 BIBSYS Id Management (etablert ved innføring av Alma) BIM ble opprinnelig designet for å holde orden på: 1. Identifikatorer for person-entiteter. 2. Hvilket register som lagrer master-data for en person? 3. Hvilke systemer som skal bruke data om en person? 4. Forhindre duplisering av personer (basert på kjennskap til fødselsnummer ) BIM skulle fungere som en nøkkelring som samler de ulike identifikatorene for en person. Nøklene skulle brukes for å formidle persondata fra et register til en tjeneste. BIM skulle ikke selv lagre persondata eller brukes for å registrere data. Det skulle de utenforliggende systemene ta seg av. Oppgaven til BIM skulle kun være å formidle data.

8 BIBSYS-Feide Etablert for å kunne tilby Feide-innlogging for brukere fra institusjoner som ikke er Feide-vertsorganisasjoner, og for walk-in-users («private» brukere) Dvs. disse ble definert som Feide-brukere med BIBSYS som vertsorganisasjon (BIBSYS ble Feide-hotell for disse brukerne) Autentisering gjøres mot oppslag i BIBSYS-Feide sin LDAP-katalog

9 Dagens arkitektur

10 Arbeidsgruppen for brukerhåndtering Problemstillingene rundt brukerhåndtering medførte at Rådgivende gruppe i samarbeid med BIBSYS etablerte en arbeidsgruppe høsten 2016 som skulle se på problemstillingene knyttet til BIM og se på mulighetene for å løse problemene Arbeidsgruppen leverte en rapport fra sitt arbeid i februar 2017 Arbeidsgruppen avdekket betydelige utfordringer knyttet til gode, alternative innloggingsalternativer i Alma/Oria som erstatning for Feide (BIBSYS-Feide) Social login via Google, Facebook og Twitter var allerede tilgjengelig som et enkelt, velfungerende alternativ, men lite vilje fra RG til å ta dette i bruk. Bruk av Dataporten og ID-porten ble vurdert, men umulig å bruke «rett ut av boksen» og krevde tilpasninger som krevde egne integrasjoner

11 Anbefalinger fra arbeidsgruppen (1) Provisjonering av brukere til Alma BIM (BIBSYS ID Management), inklusive BIBSYS-Feide, avvikles Det etableres en ny datatjeneste; BIBSYS User Provisioning Service, forkortet BUPS, som erstatter den delen av BIM som sørger for provisjonering av brukere inn i Alma. Dette blir en lettvekts-tjeneste sammenlignet med BIM, uten brukergrensesnitt eller persistering av brukerdata. Intensjonen var real-time provisjonering av brukere Kun brukere som er hjemmehørende i institusjoner som er Feide vertsorganisasjon gis tilgang til Feide for innlogging i Alma/Oria. For øvrige brukere må det eksistere et alternativt innloggingsalternativ

12 Anbefalinger fra arbeidsgruppen (2) Autentisering av brukere for Alma/Oria Rapporten beskrev 3 ulike, mulige hoved-løsningsalternativer for autentisering av brukere i Alma/Oria: 1. Bruk av føderert identitetshåndtering gjennom innføring av Dataporten fra UNINETT som Identity Provider (IdP). Beskrevet som løsningsalternativ A og A i rapporten. Krever spesialtilpasset integrasjon for mapping av ID er 2. Hybrid løsning med direkte kobling mot Feide som IdP for Feide-tilknyttede brukere, LDAP/ADFS (Institutional IdP) for brukere fra institusjoner som ikke er tilknyttet Feide, og sosial nettverkstjeneste (Google, Facebook, eller Twitter) som IdP for walk-in-users. Beskrevet som løsningsalternativ B i rapporten 3. Bruk av kommersiell sky-tjeneste (IDaaS ) som IdP, med Azure Active Directory som konkret eksempel. Løsningsalternativ C i rapporten. Det ble gjennomført en RFI for dette alternativet, men i påvente av et arbeid med felles IAM-løsning, ble dette alternativet ikke realisert.

13 Kategorier av brukere i Alma/Oria 1. Brukere med Feide-ident (tilknyttet en Feide vertsorganisasjon i konsortiet) 2. Brukere uten Feide-ident (tilknyttet en institusjon som ikke er Feide vertsorganisasjon) Felles for disse er at brukerne er registrert som ansatt eller student i et ansatt/studentregister i en (evt. flere) institusjon(er) i konsortiet. Gjelder flere av universitetssykehusene. 3. Walk-in-users Kjennetegnes ved at de ikke er registrert som bruker ved noen av institusjonene i konsortiet. 4. Lib-brukere Representerer biblioteker som inngår i fjernlåns-samarbeid. En lib-bruker benyttes for å logge seg inn i et eksternt bibliotek for å gjennomføre et fjernlån.

14 Alternative autentiserings-metoder i Alma/Oria i dag LDAP Benyttes for Feide innlogging. Alma/Oria henvender seg til Feide som IdP for å få brukernavn og passord Ex Libris Identity Service Alle brukere som defineres som internal blir autentisert i en ekstern IdP leverandør som Ex Libris benytter. Disse brukernes passord lagres i IdP en. Interne brukere lå tidligere med brukernavn og passord i Alma og autentisering ble håndtert av Alma. E-post innlogging Brukeren får ved innlogging beskjed om å oppgi sin e-post adresse hvor det sendes en innloggingslenke som brukeren benytter for å komme inn i Alma/Oria. E-post adressen som oppgis må stemme overens med brukerens lagrede e-post adresse i Alma ADFS (Microsoft AD / Azure AD) Autentisering gjøres mot institusjonens Active Directory (AD) katalog. Social login (Facebook, Google, Twitter) Brukeren autentiseres mot sin bruker i disse tjenestene

15 Brukerimport med BUPS-1, BUPS-2 og BUPS-3 BUPS-1 Benytter SIS-Import Brukerdata overføres i BIBSYS lineær-format (tagget, tekstlig format) til BUPS-1 som konverterer til Ex Libris XML-format før SIS-Import BUPS-2 Som BUPS-1, men brukerdata overføres i Ex Libris XML-format og BUPS-2 gjør ingen konvertering av data for SIS-Import BUPS-3 Basert på at BUPS kan fange opp når en bruker endres i institusjonenes brukeradministrasjons-systemer (CRUD). FS tilbyr i dag en slik tjeneste BUPS-3 benytter API-grensesnittet i Alma for oppdatering av brukere i Alma

16 BUPS-1 og BUPS-2

17 Brukerimport med BUPS-1 eller BUPS-2 Metode Migreringsprosess Motta Konvertere Klargjøre Importere (Alma) BUPS-1 Motta brukerdata på BIBSYS lineær-format (tagget, tekstlig format) Konvertere fra lineærformat til Ex Libris XMLformat for SIS-import Generere SIS-import fil og lagre på filområde Hente opp SIS-import fil fra filområde og importere brukerdata definert i filen BUPS-2 Motta data på Ex Libris XML-format Ingen konvertering nødvendig (*) BUPS: BIBSYS User Provisioning Service

18 Forutsetninger for avvikling av BIM og BIBSYS-Feide 1. Import av brukere i Alma/Oria Håndteres ved innføring av BUPS-1 eller BUPS-2 Institusjoner som ønsker å håndtere dette selv kan selv ta ansvar for dette vha. SIS-Import Krever eksport av brukere fra institusjonens tjenester for brukeradministrasjon (BAS), f. eks. FS, Banner, Microsoft AD, etc., over i en av formatene som støttes av BUPS-1 og BUPS-2 BUPS har ingen lagring av brukerdata. Alle data slettes når en import er gjennomført. Sletting/deaktivering av brukere i Alma må gjøres direkte i Alma 2. Brukere som ikke eksisterer i institusjonens egne brukeradministrasjonssystemer, defineres direkte i Alma. Det samme gjelder for institusjoner som ikke har eksportfunksjonalitet fra sine brukeradministrasjons-systemer 3. Innføre alternativ autentiserings-metode for brukere som ikke tilhører en Feide-vertsorganisasjon For institusjoner som har brukere både med og uten Feide-identitet må det tilbys mer enn én autentiseringsmetode. Brukeren må velge den aktuelle metoden ved innlogging For institusjoner som kun har ikke-feide brukere, er det tilstrekkelig med én av de alternative autentiseringsmetodene

19 Prosess for avvikling av BIM og BIBSYS-Feide (2 spor) Ca. 8 måneder ~2 måneder 1 Autentisering Overføre BIBSYS-FEIDE brukere over til en annen autentiseringsløsning Spor 1 kjøres før Spor 2 for hver institusjon Flere institusjoner kan kjøres i parallell avhengig av kapasitet 2 Brukerimport Overføre import av institusjonens brukere fra BIM til BUPS. Fjerne brukere fra BIBSYS-Feide etter hvert som de overføres til BUPS Nedstengning av BIM og BIBSYS- Feide kan først realiseres når ingen institusjoner lenger benytter BIM for brukerimport, og alle brukerne i BIBSYS-Feide er fjernet. Fremdrift i kalendertid er avhengig av tilgjengelig interneog eksterne ressurser

20 Demo - alternative innloggings-metoder Oria Alma login Alma Ex Libris Identity Service (brukernavn og passord)

21

22

23

24

25

26