Ifd:addUser
From dev.ifd-library.org
public IfdUser addUser (
IfdUser user,
String password,
String session_id)
throws IfdServerException
Function to add a new user to the IFD Library.
Input:
- user - The new user (must include organization!)
- password - Password of new user
- session_id - The session id for the active user
Returns:
- IfdUser - The new user
Comments: Talk:Ifd:addUser
[edit] Notes on access rights:
Hvordan settes roller og forskjellige rettigheter?
En bruker JOHAN som kobler seg opp med gruppe QA kan få tilgang til et beskyttet objekt på flere nivåer. Hvilken rolle JOHAN/QA spiller i forhold til objektet er avhengig av eierskapet som er satt på objektet. JOHAN/QA skal ha rolle som eier, gruppeeier eller public. Hvordan dette avgjøres kommer jeg tilbake til senere.
Rettigheter settes på beskyttede objekter i databasen. Et beskyttet objekt kan f.eks være en instans av typen repository, modell eller et metodeskjema (rule skjema, mapping skjema . . .).
I supervisoren kan du se hvilke objekter som kan beskyttes ved å liste ut express_data_manager skjemaet;
Schemata>Show>Schemata>
Se på entiteten edm_xml_configuration
ENTITY edm_xml_configuration;
name : SIMPLEID;
xml_configuration_id : UNIQUE_INDEX;
created : TIME_STAMP;
owner : edm_user;
group : edm_group;
administrators : SET OF USER_OR_GROUP;
protection : INTEGER;
access_rights_for : SET OF access_rights;
xml_configuration_for : edm_schema;
xml_configuration : xml_configuration;
description : OPTIONAL STRING;
options : OPTIONAL INTEGER;
END_ENTITY;
Alle beskyttede objekter har de fem attributtene owner, group, administrators, protection og access_rights_for. XML konfigurasjoner er altså beskyttede objekter. Det betyr at vi gjennom å sette eierskap og tilgangskode på objektet kan sette fem ulike tilganger på objektet. Disse er Delete, Execute, Create, Write og Read. For XML konfigurasjoner er Create og Execute ikke relevant.
- Med Delete rettigheter kan man slette det beskyttede objektet.
- Med Execute rettigheter kan man utføre en metode, f.eks validere en modell med globale regler som er definert i et beskyttet rule skjema.
- Med Create rettigheter kan man skape objekter i det beskyttede objektet. F.eks må man ha Create rettigheter til et repository for å kunne lage en modell i dette repositoriet.
- Med Write rettigheter kan man endre på det beskyttede objektet.
- Med kun Read rettigheter kan man ikke enre på det beskyttede objektet.
Protection attributten setter tilgangskode for det beskyttede objektet. Tilgangskoden er tredelt på en måte som minner om den man finner i filsystemet på UNIX operativsystemer. Det høyeste tilgangsnivået er EIER. Deretter kommer GRUPPE og til sist PUBLIC. De tre nivåene er som følger:
- For å få tilgang som eier må man enten ha sin bruker id i Owner attributten på det beskyttede objektet, eller den må ligge i aggregatet av administratorer (administrators attributten). Er ingen av disse kriteriene oppfyldt kan man ikke få tilgang som eier.
- Neste lag av tilgangssjekken er om man kan få tilgang som gruppeeier i kraft av sin innloggingsgruppe. Dersom gruppe Id’en ligger i Group attributten vil graden av tilgang tilmåles i henhold til objektets Gruppe-tilgangskode. Ligger den der ikke, kan man fremdeles få gruppetilgang dersom gruppe Id’en ligger i aggregatet av administratorer (administrators attributten). Ligger ikke innloggingsgruppeiden der heller kan man ikke få tilgang til objektet som ’gruppeeier’.
- Det som da gjenstår Public tilgang. Alle som ikke slipper til som eier eller gruppeeier vil få sitt tilgangsnivå satt i henhold til Public delen av tilgangskoden (protection attributten) til det beskyttede objektet. (Dette er ikke helt sant, ettersom det via attributten access_rights_for er mulig å sette spesielle tilgangskoder for brukere og grupper som ellers ville ha fått public tilgang, men det beskriver jeg ikke her)
Her kommer et eksempel på en tilgangssjekk;
Sett at en modell har følgende beskyttelse i express_data_manager modellen. owner = Håvard group = QA administrators = {Håvard, Ivar, Supervisor} protection = D-CWR|---WR|----R
Her får vi følgende tilgang;
Innlogget Bruker Innlogget Gruppe Tilgang ------------------------------------------------------------------------- Håvard - Eier = D-CWR Ivar - Eier = D-CWR Knut QA Gruppe = ---WR Hans Supervisor Gruppe = ---WR Tore - Public = ----R
Dette tilgangssystemet er antagelig enklest å forstå for brukere som kommer fra UNIX baserte miljø. Det kan gi noen litt overraskende effekter, som f.eks dersom du har satt default tilgangskode for modellen ove til --C-R|D--WR|----R. Hvis Håvard/QA nå oppretter en modell, vil han kun få lesetilgang til denne fordi han får sin tilgang som eier. Når Knut serene logger inn med gruppe QA, vil han få tilgang i kraft av sin innloggingsgruppe QA, og følgelig få rett til å endre så vel som å slette modellen. Håvard kan derimot ikke slette sin egen modell. Dette kan nok være en utfordring for brukere uten mye erfaring fra UNIX baserte filsystem. Noe av nøklen til å forstå konseptet ligger i at:
Dersom du både har tilgang som eier og gruppe, så tilmåles ikke rettighetene til objektet som en union av rettighetene for eier og gruppe. Eierrettigheter har høyere prioritet enn grupperettigheter.
Det er flere måter å sette eierskap og tilgangskode på et beskyttet objekt.
Som superuser kan du fra supervisoren gå inn i System Adm > Set Config Parameter. Der har du mulighet til å legge inne default tilgangskode for alle typer beskyttede objekter. Tilgangskoden er en 15-bit tilgangsmaske konvertert til et heltall.
Owner|Group|Public HSB> decwr|decwr|decwr <LSB
Tilgangskoden i eksemplet over blir følgelig 23649. Det er denne verdien du legger inn som protection attributten.
Hvilke rettigheter har en default bruker når han er laget med xpfCreateUser?
Når vi vet at rettigheter ikke settes på brukeren, men på objektene, så blir det litt vanskelig å svare på dette spørsmålet. Generelt kan man si at rettighetene som en nyopprettet bruker får på beskyttede objekter vil være gitt av objektets Public tilgangskode.
Objektet i eksemplet over hadde tilgangskode D-CWR|---WR|----R. Public delen av tilgangskoden er altså ----R, som vil gi denne nye brukeren lesetilgang, men dette gjelder bare for dette objektet. Andre objekt kan ha andre tilgangskoder og kan dermed gi en annen tilgang.
Til slutt; Jeg tror ikke det lar seg gjøre å opprette verken grupper eller brukere som noe annet enn superuser. Dette må jeg imidlertid sjekke nærmere med utviklerene. Jeg kommer tilbake med et svar noe senere.
Vennlig hilsen Ivar Nor EPM Support