FEIDE, autorisasjon og informasjonstilgang Seniorrådgiver IKT-arkitektur Carl-Fredrik Sørensen

1. FEIDE,  autorisasjon og informasjonstilgangSeniorrådgiver IKT-arkitekturCarl-Fredrik Sørensen Bruk av en tjenesteorientert arkitektur for å etablere EduPerson-informasjon.Muligheter og utfordringer.

2. Agenda • NTNU, Feide og autorisasjon • Katalogtjenester, sikkerhet og personvern • Kontekst og tjenester, kilder til kontekst • Feide og EduPerson • Tjenesteorientert Informasjonsarkitektur (TIA) • Feide, katalogtjeneste og TIA • Muligheter • Utfordringer

4. Feide og NTNU • Feide • Primær påloggingsløsning siden Innsida 2.0 ble lansert • Benyttes i dag til autentisering: brukernavn@institusjon.no og passord • LDAP/AD-integrasjon for lokal autentisering ved institusjon • Mulighet for å kommunisere mer data gjennom Feide/SAML, lite brukt • Fordeler: • Standardløsning for UH-sektoren • Føderasjon • Hindrer duplisering av brukerinformasjon til tjenester • Lett å integrere mot for tjenesteleverandører • Ulemper • Integrasjon mot «statiske» katalogtjenester

5. Katalogtjenester, sikkerhet og personvern • LDAP og AD: • Autentisering + autorisasjon • Samler og katalogiserer informasjon om personer/brukere, utstyr og tjenester, inkludert koblinger mellom disse (autorisasjon) • Omfattende og komplekst å modellere, utvikle, vedlikeholde og provisjonere til. Hvert system har gjerne sin variant • Katalogtjenestene er «åpne» og søkbare • Mulighet for å få komplette brukerdatabaser med tilhørende informasjon knyttet til basis personinformasjon (inkludert personnr.), roller og rettigheter. • Kan være en sikkerhetsrisiko • Vanskelig/umulig å håndtere personvernet • Ikke ønskelig å åpne for omverdenen.

6. Kontekst og tjenester • Skytjenester og Intranett-tjenester: • Behov for autentisering • Behov for autorisering • Behov for brukertilpasning • Hvem er du? • Hva gjør du vanligvis? • Hva gjør du nå? • Hva er relevant informasjon og tjenester for deg? • Hvilken informasjon og tjenester har du tilgang til?

7. Kontekst og tjenester • Hvordan tilby aktuell informasjon og tjenester, og håndtere autorisasjon knyttet til bruker? • I dag: • Integrasjon med LDAP, AD eller interne autorisasjonsregistre • Gjerne personbasert, rollebasert eller organisasjonsbasert • Blir LDAP og AD for UH en kopi av HR/FS? • I morgen • Lokasjonsbasert • Tids- og planbasert • Prosessbasert • Høyere granularitetifht. rolle? • FEIDE og EduPerson? • Aktuell kontekst: Tilhørighet, lokasjon, rolle, tid, plan (kalender), interesser, etc.

8. Kilder til kontekst • Plan/kalender: Timeplansystem, gruppevare • Tid: Klokke • Organisasjon og roller: HR, FS, IAM + andre fagsystemer • Lokasjon: GPS, innendørs posisjonering • Grunndata: • HR: Person, tilknytning, rolle, stilling • FS: Person, tilknytning, rolle, aktivitet/relasjon (emner, studieprogrammer)

9. Feide og EduPerson • eduPersonAffiliation • eduPersonEntitlement urn:mace:feide.no:ntnu.no:service:tjenestenavn:"tjenestespesifikk entitlement" IMSGlobalRoleog emnekoder for å knytte personer med studieprogram og emner: urn:mace:feide.no:ntnu.no:IMSGlobalRole:student:[emnekode]: ”URL eller URN til en WebService for hente informasjon om emne”

10. Tjenesteorientert Informasjonarkitektur

11. Tjenestebuss: Alternativ til AD/LDAP? • Implementere et LDAP-grensesnitt som tjeneste • Benytte informasjon fra persontjeneste for å gi roller, tilknytninger i EduPerson • RBAC-gjennom persontjeneste? • IAM/BAS potensiell kilde til autorisasjonsinformasjon?

12. Katalog-proxy FEIDE FEIDE Bind/Search Autentiser Brukernavn og passord Brukernavn og passord Katalog-proxy Katalog Bind/ Autentiser Search Entitlements TIA Katalog

13. Fordeler • Bedre brukeropplevelse • Mindre kompleks design av katalogtjeneste (LDAP/AD) • Unngår at katalogtjenester må populeres med all mulig informasjon koblet til person • Katalogtjeneste benyttes for passordsjekk, all annen informasjon gis gjennom tjeneste • Sporbarhet ifht bruk, katalogtjenester gjøres mindre tilgjengelig • Dynamisk kontekst, oppdatering i grunndata reflekteres direkte gjennom tjeneste -> ikke behov for provisjonering

14. Utfordringer • Applikasjoner som ikke benytter Feide eller AD/LDAP • Spesifikasjon av nødvendig informasjon og bruk av standardmodeller • Behov for web services for å hente andre grunndata • Brukeraksept for at informasjon benyttes i tjenester • Leverandøraksept for bruk av EduPerson • Ytelse ved autentisering? • Ytelse knyttet til oppslag på grunndata? • Integrasjoner • Databehandleravtale

15. Relevante tjenester • Informasjon om emner og roller: Multimediasenter, bibliotek, LMS, LOR, bokhandel • Informasjon om stilling/rolle og organisatorisk enhet: Systemer som krever autorisasjon: Arkiv, Lønnssystem, HR-system, bestillingssystem, LMS, etc.

16. Spørsmål • Takk for oppmerksomheten!