1 Bakgrunn
Med "entitlement" menes her attributtet eduPersonEntitlement som er definert i norEdu*-standarden og som kan brukes i Feide for å tildele rettigheter og roller. Se mer informasjon om bruken av eduPersonEntitlement i Feide sin dokumentasjon om attributtene de bruker.
Entitlement-attributtet er generelt definert og kan brukes til mange formål. Et eksempel på bruk av denne funksjonaliteten er Flyt-prosjektet med oppretting av gjestekontoer hos andre Feide-instanser ved pålogging gjennom Feide. Når en student eller ansatt i en institusjon skal ha midlertidig opphold i annen institusjon, kan personen tildeles en spesiell entitlement i sin hjemmeinstitusjon. Gjesteinstitusjonen henter opplysningen til besøkende via Feide og gjennom verdier i eduPersonEntitlement blir det klart hvilken konto skal lages (student med tilgang til enkelte kurs, gjesteforsker med tilgang til relevante servere, osv.).
Cerebrum har implementert en generell støtte for å kunne sette entitlements gjennom bofh, som da fører til at personen får entitlements i Feide-LDAP. Løsningen er basert på grupper, som blir tildelt et entitlement-trait. Alle medlemmer av gruppa som også er primærbrukere vil da bli tildelt eduPersonEntitlement i eksporten, med gruppa sin trait sin strval som verdi for attributtet.
2 Tildeling av entitlement
En gruppetrait entitlement er tilgjengelig i Bofh. Eksempel på tildeling av traiten:
bofh> trait set group:ex_group entitlement strval=urn:mace:feide.no:uninett.no:fas:ephorte
Ok, set trait entitlement for group:ex_group
bofh_tests>trait info group:ex_group
Entity: ex_group (group)
Trait: entitlement
String: urn:mace:feide.no:uninett.no:fas:ephorte
Alle personer som har sine primærkontoer i denne gruppa vil få med seg strval oversatt til eduPersonEntitlement når den blir publisert i LDAP. Eksempelet over vil publiseres i LDAP for hver person som:
eduPersonEntitlement: urn:mace:feide.no:uninett.no:fas:ephorte
Det er forutsatt at det er brukerkontoer som legges inn i grupper med trait. Dvs. at hvis man vil tildele entitlement til en person, må man melde personens primære brukerkonto til gruppa med ønsket trait.
2.1 Begrensninger
Funksjonaliteten har noen begrensninger:
- Om en person bytter primærbruker må den nye brukeren meldes inn i gruppen, hvis ikke vil personen miste sin entitlement fra gruppern. Dette skjer ikke automatisk.
- Det er bare mulig å sette ett entitlement per gruppe. Ønsker man at en bruker har f.eks. to forskjellige entitlementer -- må man legge brukerkontoen inn i to grupper med ønskede traiter.
- Cerebrum sjekker ikke om entitlement er unik for en gruppe. De som forvalter dette må derfor ha oversikt over hva de legger til, for å unngå uhensiktmessig eskalering av tilganger.
- Funksjonaliteten er ikke skalert for å gi alle grupper entitlements. Da trenger vi en enklere løsning, for eksempel en standardisert URN som slutter på gruppenavnet, og ikke friekst-muligheten i denne løsningen.
2.2 Hva du kan/bør sette for entitlements
Obs: Selv om instansen kan fritt legge inn hva som helst som entitlement, anbefales det å følge Feide sine retningslinjer for attributtene, som sier at entitlements bør vere URN-formatert. Dette for å gjøre verdiene globalt unike og identifiserbare. MACE brukes gjerne i sammenheng med URN for å reservere institusjoner sine lokale URN-navnerom. Feide har reservert alt under urn:mace:feide.no og vil kunne tildele institusjoner egne navnerom under denne adressen - se https://www.feide.no/urn for mer informasjon om dette og hvordan søke om reservasjon for din egen institusjon.
Eksempler på URN-formatet:
- For FAS: urn:mace:feide.no:uninett.no:fas:public360 (se https://www.feide.no/urn-uninett.no for mer informasjon om FAS sine attributter).
- Lokalt definert for UiO: urn:mace:feide.no:uio.no:ephorte:role:admin
- Eksempel fra Feide: urn:mace:feide.no:stillingskode:stat:1011
- Lokalt definert for UiA: urn:mace:feide.no:uia.no:access:fs
3 Hjelp til feilsøking
Det er ingen funksjonalitet i bofh for å enkelt se hva entitlements en person eller bruker eventuelt har. Enkleste måten å se dette på er å gjøre et LDAP-søk på personen, brukeren eller gruppen, men merk at det er en forsinking før endringer blir oppdatert fra Cerebrum til LDAP.
Feilsøking ved bruk av bofh:
For grupper kan du se et eventuelt definert entitlement med kommandoen:
trait info group:GRUPPENAMN
som gir deg lista over alle "traits" eller tagger på gruppa. Se etter traitet av typen "entitlement".
For å se hvilke grupper som har et entitlement definert kan du bruke:
trait list entitlement
men du må bruke trait info for å se selve verdien for hver enkelt gruppe.
For personar får du dessverre ikke sett entitlements med en enkelt kommando, men du må i steden for feilsøke gjennom flere sjekker/kommandoer:
Se hvilken bruker som er primærbrukeren til personen med:
person list_user_priorities USERNAME
Den øverste aktive brukeren, med lavest verdi, er primærbrukeren.
Hent ut alle gruppemedlemskap til primærbrukaren til personen for å se at brukaren er med i riktig gruppe, med:
group memberships account USERNAME
Se om gruppa er satt opp med et entitlememt, med:
trait info
4 Cerebrum-teknisk
Denne delen inneholder teknisk informasjon som er relevant for de som drifter Cerebrum, og kan ignoreres av andre.
4.1 Konfigurasjon
entitlements_pickle_file-parameter i LDAP_PERSON i cereconf.py både utløser publisering av entitlementer under eduPersonEntitlement og viser veien til pickle-filen laget av pickle-skripten, der entitlementer per personer er publisert. Hvis parameteret er tomt (default) -- er publiseringen i LDAP av.
Eksempel på konfigurasjon for bruk av entitlement:
LDAP_PERSON.update({
'entitlements_pickle_file' : LDAP['dump_dir'] +
'person2entitlements.pickle',
})
Dette parameteret brukes også av pickle-skripten for å lage filen med dette navnet. Dette er for å forenkle ting: det er ikke nødvendig å spesifisere --picklefile-parameter i cron-jobben til skripten hvis entitlements_pickle_file er med i konfigurasjonen.
4.2 Tekniske krav til oppsett av instansen
For løsningen å fungere, må Cerebrums oppsett for instansen oppfylle noen krav.
trait-kommandoer i bofh må være tilgjengelig.
Constanten trait_group_entitlement må være med i databasen.
Riktig klasseoppsett i Cerebrum i cereconf.py. Group-klasse må ha list_traits()-metoden med seg. Et enkelt eksempel på konfigurasjonen:
CLASS_GROUP = ('Cerebrum.Group/Group', 'Cerebrum.modules.EntityTrait/EntityTrait',)men mest sannsynligvis må instansene ha mer komplisert oppsett for klassen. Man må sørge for riktig konfigurasjon i hver tilfelle.
Noen av instansene oppfyller ikke alle disse kravene per i dag. Nødvendige endringer i produksjonsoppsett må gjøres før entitlementer blir tilgjengelige for disse instansene.
4.3 Oppsett for LDAP
Før Cerebrum kan begynne å publisere attributtet, må det avklares med katalog-drift at eduPersonEntitlement kan legges i LDIF-filene for publisering. LDAP må settes opp til å håndtere attributtet på riktig måte.
Vanligvis ønsker en at entitlements er skjult for verden og blir gjort synlig bare for tjenester som trenger det, f.eks. Feide. Dette er likevel opp til hva instansen ønsker og har behov for.
Det at eduPersonEntitlement blir synlig impliserer også at DN til personen blir synlig (og dermed brukernavnet i DN), ellers kunne man jo ikke sett objektet med eduPersonEntitlement.
Hvis det ikke er akseptabelt å vise denne informasjonen til Feide, er et alternativ å bare tillate en "compare"-operasjon som går direkte på objektet. Dvs Feide får TRUE/FALSE på å spørre "har olenordmann sitt objekt eduPersonEntitlement=heisann"? Da kan man oppdage at olenordmann har et objekt, men ikke søke fram objektet dens.
4.4 Oversettelse av gruppetraiter til persons attributter
contrib/no/generate_entitlements_per_person_pickle.py script lager en pickle fil, som brukes for publiseringen. Skripten henter alle personer, som har sine primære brukerkontoer i grupper med entitlement-trait og bygger en list av entitlementene per person. Filen som lages av skripten må være tilstedet før publiseringen av attributten kan skje. For å teste kan skripten kjøres manuelt med veien til filen spesifisert med --picklefile parameter, men for produksjonen anbefales det å lage en jobb som kjører skripten regelmessig og skrive veien til filen i cereconf.py (se konfigurasjon). Jobben bør kjøres før generate_org_ldif.
4.5 Publisering
Hvis veien til pickle-filen i konfigurasjonen ikke er tom, vil LDAP-modulene til Cerebrum hente informasjonen fra filen og publisere i LDAP-dumpen. Dette gjøres vanligvis når contrib/generate_org_ldif.py-skript kjøres, som regel som org_ldif.
4.6 eduPersonEntitlement bruk for andre formål
Noen av instansene bruker eduPersonEntitlement for å publisere informasjon som ikke er entitlement. For eksempel, UiO bruker attributten for å publisere hvilke kurs en student tar, og NMH publiserer ekstra informasjon om sine ansatte i attributten. Dette er greit så lenge institusjonene legger informasjon i tillegg og ikke overskriver attributten. Hvis institusjonen har behov for å publisere noe spesielt i attributten, må dens OrgLDIF.py endres slik at den lager informasjonen i tillegg til den som er kanskje der allerede fra øvre LDAP-moduler. For eksempel, for UiO ser koden slik ut:
if entry.has_key('eduPersonEntitlement'):
entry['eduPersonEntitlement'].extend(self.ownerid2urnlist[p_id])
else:
entry['eduPersonEntitlement'] = self.ownerid2urnlist[p_id]
I den resulterende filen blir det da publisert flere eduPersonEntitlement-attributter, både med entitlementer og ekstra informasjonen fra instansen.
Dette vil kreve utvikling, som i så fall må bestilles av Cerebrum utvikling.
4.7 Mulig videreutvikling
Hvis noen av kunder får behov for det, kan funksjonaliteten videreutvikles. Mest sannsylige endringer er:
- Publisere entitlementer for indirekte medlemmer av gruppa sammen med direkte medlemmer.
- Unngå navnekollisjoner.
- Automatisk melding i gruppe med trait ved bytte av primærbrukerkonto. Nå ved bytte av primærbruker vil ikke entitlement bli med, med mindre den nye primærkontoen er medlem av samme gruppa som den gamle. I sånn tilfelle må man manuelt melde den nye primærbruker i grupper med ønskede traiter på nytt. Det kan kanskje utvikles mekanikk som automatisk melder den nye kontoen i alle grupper med trait som den gamle kontoen var medlem i.