Ifd:addUser

API version 2
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

API version 3
public IfdUser addUser (                       IfdUser user,                       String password,                       String session_id) throws IfdServerException

EXPRESS heading QUERY_FUNCTION addUser(                      user : IfdUser;                        password : STRING) : IfdUser;

The function adds new IFD user to target population and (optionally) registers the user in database engine.

Input: user - fully specified IFD user to be added to target population, with the following attributes for every element: password - (optional) user’s password to log on in database engine,
 * session_id - The session id for the active user
 * guid – (optional) unique IFD user id - login to database, if the attribute is unset or empty new unique IFD user login will be generated (from user e-mail);
 * name – user name;
 * email – user e-mail address (shall be unique over IFD users);
 * created_date – ignore in input;
 * role - name of the stored in target IFD role to be assigned to the newly created user;
 * member_of – (optional) user’s organization specified by guid, name or url – shall be specified for any users with access rights different from R/O
 * if the attribute unset or empty newly created IFD user will not be registered in database (database administrator shall do it before or after the call);
 * if the attribute is specified newly created IFD user will be registered in database

Returns:
 * IfdUser - Fully specified newly created user structure with the same attributes as in input (value of empty guid will be changed to generated one, created_date will be set to current date/time stamp).

Difference against v.2.00
 * (59)	The function can add very first user (it shall be assigned to role with user management rights). The function in v.2.00 could not add the very first user (because calling user shall be IFD user with user management rights);
 * (60)	The function allows assigning existing or desired db login for the user (guid) and can generate it from user e-mail (like ‘alex123_hotmail_com’). The function in v.2.00 could only generate the login like the following: ‘u36K5y0oTCHsm00051Mm008';
 * (61)	The function can assign to newly created IFD user existing database login. The function in v.2.00 enforce creating new database login

Comments:

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