Administrasjon av kontoer og autorisasjoner¶
Kontoadministrasjon omfatter oppretting, endring og sletting av brukerkontoer for de ulike applikasjonene som administreres i organisasjonen. Dette innebærer å tilordne unike identifikatorer til brukerne (for eksempel brukernavn eller ansattnummer) og å administrere informasjonen som er knyttet til disse kontoene.
Administrasjon av tillatelser består i å gi hver identitet spesifikke tilgangsrettigheter og autorisasjoner ut fra rollen, ansvarsområdene, organisasjonen og behovene identiteten har i organisasjonen. Disse autorisasjonene kan omfatte tilgang til applikasjoner, data, nettverk, systemer, fysiske ressurser osv.
Administrasjon av rollene og tillatelsene til en identitet omfatter beregning og tilordning av tillatelser til identiteter i ulike applikasjoner, for å bygge opp et teoretisk repository over identitetene og tillatelsene deres. Det betyr at alle beregnede kontoer, roller og autorisasjoner kan provisjoneres automatisk eller manuelt i de ulike målapplikasjonene.
CyberElements Identity gir mulighet til å administrere roller og autorisasjoner enten automatisk, via autorisasjonsregler, eller diskresjonært, via manuelle tillegg av rettigheter eller skjemaforespørsler (workflow).
Administrasjon av kontotyper¶
En kontotype består av flere elementer:
- En påloggingspolicy (obligatorisk),
- En passordpolicy (valgfritt),
- Kontoattributter (valgfritt),
- Kontostatuser definert ut fra identitetsstatusene
En kontotype må være knyttet til et repository og til en rolle for at kontoer skal kunne genereres. Det er derfor mulig å ha flere kontoer i samme repository for samme identitet, hvis denne identiteten har flere ulike roller.
Opprette/endre/slette en kontotype for et repository¶
Se siden Administrasjon av objekttyper for administrasjon av kontotyper, konfigurasjon av de ulike skjemaene osv.
Opprette/endre/slette en påloggingspolicy¶
For å få tilgang til administrasjonen av påloggingspolicyer går du til menyen ”Access Management/Account Rules”.
Du kommer direkte til listen over eksisterende påloggingspolicyer, som er forhåndslastet i en tabell uten at det er brukt filtre.
Paginering er satt opp slik at det bare vises 10 påloggingspolicyer.
Et søkefelt er tilgjengelig øverst til høyre i tabellen. Søket gjelder attributtene ”code” og ”name” i påloggingspolicyene.
For å opprette en ny påloggingspolicy klikker du på knappen ”
”.
Angi parameterne for en påloggingspolicy:
-
Code: koden til påloggingspolicyen. Må være unik, uten mellomrom og uten spesialtegn. Obligatorisk.
-
Name: navnet på påloggingspolicyen. Betegnelsen som vises i de ulike skjemaene i applikasjonen. Obligatorisk.
-
Description: felt for å angi en beskrivelse av påloggingspolicyen. Valgfritt.
-
Formula (primary): beregningsformel for å definere påloggingsnavnet
-
Duplicate policy:
- Automatic increment: påloggingsnavnet beregnes med den primære formelen og suppleres med en duplikatindeks. Duplikatindeksen har et format med 3 sifre.
- Eksempel: Login_Calc002
- Formula (duplicate): egendefinert beregningsformel for tilfellet der det oppdages et duplikat når påloggingsnavnet beregnes med den primære formelen. Du kan bruke nøkkelordet §INDEX_DOUBLON§ for å håndtere den automatiske økningen, men plassere det på et bestemt sted. Fra Identity 7.0 SP3 starter nøkkelordet §INDEX_DOUBLON§ på 1 og har ingen grense. For tidligere versjoner har duplikatindeksen et format med 3 sifre.
- Eksempel: Formula (duplicate) Login2_Calc
Advarsel: for å teste formelen med dette nøkkelordet må du erstatte §INDEX_DOUBLON§ med en verdi. Dette nøkkelordet kan ikke tolkes i formeltesteren, men det fungerer ved beregning av påloggingsnavn.
- Automatic increment: påloggingsnavnet beregnes med den primære formelen og suppleres med en duplikatindeks. Duplikatindeksen har et format med 3 sifre.
-
Action to take if a real account exists:
- Use and reconcile with the real account
- Generate a login with duplicate policy
- Do not generate an account
-
Actions to take if a theoretical account exists:
- Generate a login with duplicate policy
- Do not generate an account
For å vise og endre en påloggingspolicy klikker du på ikonet ”
” til høyre i den aktuelle tabellraden:
Det er mulig å bytte til redigeringsmodus direkte fra visningssiden for påloggingspolicyen.
I redigeringsmodus kan alle felt endres.
Handlinger for knappene i redigerings- eller opprettingsmodus:
- Cancel: avbryter den pågående registreringen og setter siden i visningsmodus
- Save: bekrefter skjemaet og setter siden i visningsmodus
- Save and quit: bekrefter skjemaet og går tilbake til listesiden for påloggingspolicyer
For å slette en påloggingspolicy klikker du på ikonet ”
” til høyre i den aktuelle tabellraden:
Det vises en bekreftelsesmelding før påloggingspolicyen slettes.
Advarsel: det er ikke mulig å slette en påloggingspolicy så lenge den er knyttet til ett eller flere repositoryer.
Opprette/endre/slette en passordpolicy¶
For å få tilgang til administrasjonen av passordpolicyer går du til menyen ”Access management/Password rules”.
Du kommer direkte til listen over eksisterende passordpolicyer, som er forhåndslastet i en tabell uten at det er brukt filtre.
Paginering er satt opp slik at det bare vises 10 passordpolicyer.
Et søkefelt er tilgjengelig øverst til høyre i tabellen. Søket gjelder attributtene ”code” og ”name” i passordpolicyene.
For å opprette en ny passordpolicy klikker du på knappen ”
”:
Angi parameterne for en passordpolicy:
- Code: koden til påloggingspolicyen. Må være unik, uten mellomrom og uten spesialtegn. Obligatorisk.
- Name: navnet på påloggingspolicyen. Betegnelsen som vises i de ulike skjemaene i applikasjonen. Obligatorisk.
- Description: felt for å angi en beskrivelse av passordpolicyen. Valgfritt.
- Formula: beregningsformel for å definere passordet
For å vise og endre en passordpolicy klikker du på ikonet ”
” til høyre i den aktuelle tabellraden:
Du kan bytte til redigeringsmodus direkte fra visningssiden for passordpolicyen.
I redigeringsmodus kan alle felt endres.
Handlinger for knappene i redigerings- eller opprettingsmodus:
- Cancel: avbryter den pågående registreringen og setter siden i visningsmodus
- Save: bekrefter skjemaet og setter siden i visningsmodus
- Save and quit: bekrefter skjemaet og går tilbake til listesiden for passordpolicyer
For å slette en passordpolicy klikker du på ikonet ”
” til høyre for den aktuelle tabellraden:
Det vises en bekreftelsesmelding før passordpolicyen slettes.
Advarsel: du kan ikke slette en passordpolicy hvis den er knyttet til ett eller flere repositoryer.
Vise kontoene i et repository¶
For å søke etter en konto går du til menyen ”Accounts”.
Du kommer direkte til søkesiden for kontoer i et valgt repository (det første i listen), forhåndslastet uten at det er brukt filtre, men med hensyn til tillatelsene som er knyttet til profilen til den påloggede brukeren.
Siden kontoene er knyttet til et repository, må du velge ønsket repository, enten via fanene eller via nedtrekkslisten, for å vise listen over tilknyttede kontoer.
Visningsmodusen fastsettes ut fra antall repositoryer. Enten er det 10 eller færre repositoryer, og de vises i egne faner, eller de listes opp i en nedtrekksliste.
Paginering er satt opp slik at det bare vises 10 kontoer.
Et søkefelt er tilgjengelig øverst til høyre i tabellen. Søket gjelder påloggingsnavnene til kontoene og tar hensyn til det valgte repositoryet.
Konfigurere tabellen med søkeresultater for kontoer¶
For å konfigurere attributtene som skal inngå i tabellen med søkeresultater for kontoer, går du til siden for attributtkonfigurasjon, velger fanen ”Account”, åpner ønsket attributt i redigeringsmodus og merker av for alternativet ”Display in results table”.
Avstemme / oppheve avstemming av en teoretisk konto mot en reell konto¶
For å gå til siden for administrasjon av kontoavstemming går du til menyen ”Accounts” og aktiverer alternativet ”Reconciliation”:
Det vises to nye tabeller i vinduet:
Den andre tabellen lister opp de foreldreløse kontoene i det valgte repositoryet. Til påminnelse: foreldreløse kontoer er kontoer som er hentet fra mål-repositoryet, men som ikke er knyttet til noen identitet i CyberElements Identity.
Den tredje tabellen lister opp identitetene som ikke er knyttet til noen konto i det valgte repositoryet.
I denne tabellen kan du gjøre følgende for hver identitet uten konto:
- Knytte til en eksisterende teoretisk konto. Klikk på knappen
til høyre for ønsket identitet, og søk deretter etter den ønskede eksisterende teoretiske kontoen. - Opprette en teoretisk konto. Klikk på knappen
til høyre for ønsket identitet, og opprett deretter den teoretiske kontoen ved å velge ønsket kontotype.
Viktig merknad
Funksjonen er fjernet fra de eldre grensesnittene fordi det ikke er mulig å beholde begge modusene.
Diskresjonær administrasjon av roller og autorisasjoner¶
For å endre rolletilordningene og autorisasjonene for en identitet manuelt åpner du den ønskede identitetsposten i visningsmodus og går til fanen ”Roles and Authorizations”.
Det vises en tabell med rollene som er tilordnet identiteten. For hver rolle inneholder en nestet tabell autorisasjonene som er knyttet til identiteten og tilordnet rollen. En autorisasjon må være knyttet til et par Identity/Role.
Hvis flere identiteter er avstemt, vises en fane for hver identitet, slik at du kan velge ønsket identitet. Roller og autorisasjoner er knyttet til en identitet og ikke til en avstemmingskjede. Det er derfor nødvendig å velge ønsket identitet før du utfører manuelle oppdateringer.
Paginering er satt opp slik at det bare vises 10 roller.
I tabellen som er innebygd under en rolle, er pagineringen satt opp slik at det bare vises 5 autorisasjoner.
Et søkefelt er tilgjengelig øverst til høyre i rolletabellen. Søket baserer seg på navnene på rollene.
I tabellen som er innebygd under en rolle, er det et søkefelt øverst i autorisasjonstabellen. Søket dekker attributtene ”Category”, ”Code” og ”Name” i autorisasjonene.
Du finner følgende informasjon i autorisasjonstabellen:
- Statusen:
- ”Valid”: autorisasjonen er synlig uten spesiell merking
- ”Blocked”: autorisasjonen er synlig, men overstrøket i grensesnittet
- Tilordningsmodus. De mulige verdiene er
: manuell, med UID-en til identiteten som utførte tilordningen
: autorisasjonsregel, med navnet på regelen eller reglene
: autorisasjon gitt ved rollearv
: det første ikonet viser at rettigheten er lagt til manuelt (via en workflow), og det andre gir tilgang til workflowen (lenke til betjeningsgrensesnittet for workflowen).
For å legge til én eller flere roller, eller for å legge til én eller flere autorisasjoner til flere roller for samme identitet, klikker du på knappen ”
” øverst til høyre i rolletabellen.
Velg den eller de ønskede rollene, og klikk deretter på ”Confirm” for å legge til rollene og gå videre til neste trinn, eller på ”Cancel” for å avbryte operasjonen.
For å legge til én eller flere autorisasjoner til en rolle som allerede er knyttet til identiteten, klikker du på knappen ”
” til høyre i den aktuelle raden i rolletabellen.
Velg den eller de ønskede autorisasjonene, og klikk deretter på knappen ”Confirm” for å knytte dem til rollen, eller på knappen ”Cancel” for å avbryte operasjonen. Det er mulig å angi en start- og sluttdato som brukes på alle de valgte autorisasjonene.
-
Handlingsknapper for autorisasjonene:
: gjør det mulig å blokkere autorisasjonen.
: gjør det mulig å oppheve blokkeringen av autorisasjonen.
: gjør det mulig å sertifisere autorisasjonen.
: gjør det mulig å slette sertifiseringen av autorisasjonen.
: gjør det mulig å endre gyldighetsdatoene. Knappen er bare tilgjengelig for manuelle rettigheter.
Advarsel: knappen for å slette en autorisasjon finnes bare hvis autorisasjonen utelukkende er tilordnet diskresjonært. Autorisasjonen kan fortsatt være synlig med statusen ”pending deletion” hvis provisjoneringsstatusen er ”provisioned”.
For å oppheve koblingen mellom en rolle og en identitet klikker du på ikonet ”
” til høyre for den aktuelle raden i rolletabellen.
Det vises en bekreftelsesmelding før rollen slettes.
Advarsel: knappen for å slette en rolle finnes bare hvis rollen er tilordnet diskresjonært. Alle autorisasjoner som er knyttet til paret identitet/rolle, kobles også fra og deprovisjoneres ved neste synkronisering hvis provisjoneringen er automatisk.
Administrasjon av autorisasjonsregler¶
Autorisasjonsregler gjør det mulig å konfigurere tilgangspolicyer og automatisk tilordne rettigheter til identitetene som regelen finner.
En autorisasjonsregel består i å knytte sammen:
- på den ene siden en populasjon av brukere, definert ved filtrering på roller (RBAC), organisasjoner (OrBAC) og/eller attributtverdier (ABAC),
- på den andre siden roller og applikasjonsrettigheter.
For å få tilgang til administrasjonen av autorisasjonsregler går du til menyen ”Access Management / Authorization Rules”.
Du kommer direkte til siden som lister opp de eksisterende autorisasjonsreglene, forhåndslastet uten at det er brukt filtre, men med hensyn til autorisasjonene som er knyttet til profilen til den påloggede personen.
Paginering er satt opp slik at det bare vises 10 regler.
Et søkefelt er tilgjengelig øverst til høyre i regeltabellen. Søket baserer seg på navnene på reglene.
For å opprette en ny autorisasjonsregel klikker du på knappen ”
”.
Opprettingen av en regel består av tre deler:
-
Generelle innstillinger
- Name: navnet på autorisasjonsregelen. Obligatorisk.
- Description: felt for å angi en beskrivelse av autorisasjonsregelen. Valgfritt.
- Context: velg én eller flere kontekster fra nedtrekkslisten med kontekstene som er opprettet tidligere.
-
Liste over kriterier: klikk på knappene ” ” eller ” ” for å legge til en filterregel for identitetene som skal inngå i autorisasjonsregelen. En filterregel består i å definere et attributt som et filter skal brukes på, sammenligningsoperatoren og verdiene som skal sammenlignes.
- Knappen ”
” gjør det mulig å legge til et nytt filter på samme nivå som det forrige filteret. - Knappen ”
” gjør det mulig å legge til en filtergruppe på samme nivå som det forrige filteret. Det er obligatorisk å legge til filtre eller filtergrupper i en gruppe ved hjelp av knappene ”
” eller ”
” i gruppen. - På hvert filternivå må du angi operatoren som skal brukes mellom hver filterregel.
- Et objekt som du vil utføre en sammenligning på. Det kan være:
- En rolle
- Et personattributt
- Et strukturattributt
- Et ressursattributt
- Sammenligningsoperator. Listen over sammenligningsoperatorer er dynamisk og avhenger av typen objekt som er valgt.
- En verdi som skal sammenlignes: angis eller velges fra en nedtrekksliste, avhengig av typen objekt som er valgt og av sammenligningsoperatoren.
- Knappen ”
Du kan legge til så mange filterkriterier du vil. Mellom hver filterregel må det fastsettes operatorer som ”AND” eller ”OR”. Det kan opprettes undergrupper for å øke antallet muligheter.
Eksempel: slik oppretter du følgende filterregel:
(Person type = ”Medical agent or External medical agent” AND attributtet ”Job” = ”Biological unit manager”) OR (Person type = ”Non-medical agent” AND attributtet ”Job” = ”Environmental specialist”)
Filterkriteriene konfigureres slik:
- Roller og autorisasjoner som skal tilordnes i autorisasjonsregelen: det finnes to faner for å vise rollene og autorisasjonene som skal inngå i autorisasjonsregelen. Fanen ”Role” viser listen over roller og angir kort de tilhørende autorisasjonene, hvis det finnes noen. Det er også fanen der roller og autorisasjoner kan legges til eller fjernes. Fanen ”Authorizations” viser listen over autorisasjonene som er lagt til regelen, med den eller de tilknyttede rollene for hver av dem. Denne fanen gir bare en annen visning.
Listen over autorisasjoner filtreres etter de valgte rollene (en rolle er knyttet til ett eller flere repositoryer).
For å vise og endre en autorisasjonsregel klikker du på ikonet ”
” til høyre i den aktuelle tabellraden:
Visningsmodus gjør det mulig å se detaljene i en autorisasjonsregel og også listen over identiteter som berøres av regelen.
Du kan søke etter en person ved hjelp av søkefeltet øverst til høyre i tabellen.
Du kan bytte til redigeringsmodus ved å klikke på knappen ”Edit”.
I redigeringsmodus kan alle felt endres.
Merk: listen over personer som berøres av regelen, oppdateres ikke i sanntid når en regel endres. Den oppdateres når regelen er bekreftet og beregningene er fullført.
Handlinger for knappene i opprettings- og redigeringsmodus:
- Cancel: avbryter den pågående registreringen og setter siden i visningsmodus
- Save: bekrefter skjemaet og setter siden i visningsmodus. Beregningene utføres automatisk.
- See Impact: viser virkningene av å opprette eller oppdatere regelen. Virkningene vises i to tabeller:
- Den første tabellen lister opp virkningene regelen har på rettighetene, der det bare tas hensyn til autorisasjonsregelen som er opprettet eller endret. Alle identiteter som samsvarer med kriteriene, vises, også de som allerede har fått tillatelsen tilordnet på annen måte. Hvis personen faktisk mister rettighetene sine som følge av endringen i autorisasjonsregelen, kan personen likevel beholde dem på andre måter.
- Den andre tabellen lister opp de samlede virkningene regelen har på rettighetene. Denne delen tar hensyn til alle reglene i CyberElements Identity, de diskresjonære tilordningene av rettigheter og rettighetene som er blokkert av en regel for arbeidsdeling. Hvis en identitet allerede har fått tillatelsen tilordnet på annen måte, tas kontoen ikke med på denne listen. Det vises de rettighetene som faktisk blir berørt/slettet når endringen bekreftes.
I denne andre tabellen er det mulig å bruke en frist før rettigheten faktisk slettes (bruk av en overgangs- eller overlappingsperiode).
For å slette en autorisasjonsregel klikker du på ikonet ”
” til høyre i den aktuelle tabellraden:
Det vises en bekreftelsesmelding før en autorisasjonsregel slettes.
Ikonet ”
” kjennetegner en autorisasjonsregel som er under beregning. Hvis det er nedtonet, betyr det at beregningene er fullført.
Administrasjon av regler for arbeidsdeling (SoD)¶
Arbeidsdeling (SoD): er et grunnleggende sikkerhetsprinsipp som består i å fordele ansvar og privilegier innenfor en organisasjon eller et system for å minimere risiko og forebygge interessekonflikter. Det innføres for å sikre ansvarlig og trygg bruk av IT-systemene og selskapets ressurser.
En regel for arbeidsdeling består i:
- Å definere en prioritetsgruppe
- Å legge roller eller autorisasjoner til prioritetsgruppen med en prioritetsvekt
For å få tilgang til administrasjonen av regler for arbeidsdeling går du til menyen ”Access Management / SoD Rules”. Fra og med versjon 7.1 har denne menyen to undermenyer: Identities og Accounts.
Fra og med versjon 7.1 gjør modulen for arbeidsdeling det mulig å opprette regler som gjelder enten autorisasjoner eller roller, og å legge til filtre rettet mot identiteter eller kontoer for å begrense omfanget av en regel.
De to undermenyene tilsvarer de to nivåene som en regel kan gjelde på:
- Identities: for én og samme identitet som har rettigheter som er uforenlige med hverandre;
- Accounts: når en person har flere identiteter som deler den samme kontoen (sammenslåing av kontoer), og de samlede rettighetene til disse identitetene faller inn under en regel for arbeidsdeling.
Hver av disse to undermenyene inneholder to faner, Roles og Rights. Fanen Roles definerer prioriteter for rollene i en gruppe, fanen Rights for autorisasjonene i en gruppe. Fremgangsmåten som er beskrevet nedenfor, er den samme i begge fanene, der objektet som legges til i prioritetsgruppen, er enten en rolle eller en autorisasjon, avhengig av tilfellet.
Under koden, navnet og beskrivelsen viser detaljsiden for en regel tre blokker: listen over kriterier (filtrene rettet mot identiteter eller kontoer), listen over tilknyttede autorisasjoner — eller roller — og listen over identiteter som berøres av regelen.
Når en regel låser eller låser opp en rolle eller en autorisasjon for en bruker, registreres operasjonen i auditene med navnet på regelen som utløste den. Disse registreringene gjør det mulig å finne regelen som må gjennomgås, ved uønsket låsing.
Visning og endring av regler styres av rettighetene ”220_001 - View a segregation of duties rule” og ”220_002 - Modify a segregation of duties rule” i CyberElements Identity-repositoryet.
Du kommer direkte til siden som lister opp de eksisterende reglene for arbeidsdeling, forhåndslastet uten at det er brukt filtre, men med hensyn til autorisasjonene som er knyttet til profilen til den påloggede personen.
Paginering er satt opp slik at det bare vises 10 regler.
Et søkefelt er tilgjengelig øverst til høyre i regeltabellen. Søket baserer seg på navnet på prioritetsgruppene (= navnet på regelen for arbeidsdeling).
For å opprette en ny regel for arbeidsdeling klikker du på knappen ”
”:
Opprettingen av en regel for arbeidsdeling skjer i to trinn.
Angi først de generelle parameterne:
- Code: koden til regelen for arbeidsdeling. Obligatorisk.
- Name: navnet på tillatelsesregelen. Obligatorisk.
- Description: felt for å angi en beskrivelse av regelen for arbeidsdeling. Valgfritt.
Lagre opprettingsskjemaet for å gå videre til det andre trinnet, som er å legge til autorisasjoner.
For å legge til en autorisasjon i SoD-regelen klikker du på knappen ”
” i tabellen ”List of associated rights”.
Velg ønsket autorisasjon og angi en vekt for å definere prioriteten. Jo lavere verdien er, desto høyere er prioriteten.
For å endre en autorisasjon i SoD-regelen klikker du på knappen ”
” til høyre i den aktuelle tabellraden.
Du kan endre autorisasjonen og/eller prioritetsvekten.
For å slette en autorisasjon i SoD-regelen klikker du på knappen ”
” til høyre i den aktuelle tabellraden.
For å vise og endre en regel for arbeidsdeling klikker du på ikonet ”
” til høyre i den aktuelle tabellraden.
Du kan bytte til redigeringsmodus ved å klikke på knappen ”Edit”.
I redigeringsmodus kan bare navnet og beskrivelsen endres
For å slette en regel for arbeidsdeling klikker du på ikonet ”
” på høyre side av den aktuelle tabellraden.
Det vises en bekreftelsesmelding før en autorisasjonsregel slettes.
Sende rettighetsforespørsler via skjemaer¶
Sende en rettighetsforespørsel¶
Forespørsler om autorisasjoner for en person (eller for deg selv) sendes i det gamle driftskonsollet via menyen ”Run an ‘On demand’ workflow”.
Klikk på knappen ”Refresh” for å vise listen over tilgjengelige workflower.
Klikk på workflowen du ønsker, for å sende en autorisasjonsforespørsel.
Velg én eller flere identiteter som forespørselen gjelder.
Velg de ønskede autorisasjonene fra den tilgjengelige listen. Angi start- og sluttdato om nødvendig.
Klikk på knappen ”Add”.
Du kan legge til eller fjerne autorisasjoner som du vil. Hvis du vil legge til gyldighetsdatoer for en autorisasjon som allerede er valgt, må du slette den og deretter legge den til på nytt med datoene angitt på forhånd.
Klikk på knappen ”Start” og bekreft i popup-vinduet.
Når du har bekreftet kjøringen av workflowen, blir du automatisk omdirigert til siden der du kan se de pågående forespørslene.
Sende en forespørsel om manuell provisjonering (eller deprovisjonering) av en autorisasjon¶
Forespørsler om manuell provisjonering (eller deprovisjonering) sendes i det gamle driftskonsollet via menyen ”Run an ‘On demand’ workflow”.
Klikk på knappen ”Refresh” for å vise listen over tilgjengelige workflower.
Klikk på workflowen du ønsker, for å sende en provisjoneringsforespørsel.
Velg én eller flere identiteter som forespørselen gjelder.
Velg de ønskede autorisasjonene fra den tilgjengelige listen. Angi start- og sluttdato om nødvendig.
Klikk på knappen ”Add”.
Du kan legge til eller fjerne autorisasjoner som du vil. Hvis du vil legge til gyldighetsdatoer for en autorisasjon som allerede er valgt, må du slette den og deretter legge den til på nytt med datoene angitt på forhånd.
Klikk på knappen ”Start” og bekreft i popup-vinduet.
Når du har bekreftet kjøringen av workflowen, blir du automatisk omdirigert til siden der du kan se de pågående forespørslene.
Delegere autorisasjoner¶
Delegering av autorisasjoner gjør det mulig å overføre rettigheter fra én person (delegerer) til en annen (delegat), vanligvis for en begrenset periode.
Denne funksjonen er tilgjengelig for delegererne (avhengig av tillatelsene til den påloggede personen), men fra versjon 7.0 kan også en tredjepart (avhengig av tillatelsene til den påloggede personen) delegere rettigheter til en annen identitet (for eksempel en administrator).
For å få tilgang til funksjonen for delegering av autorisasjoner åpner du den ønskede identitetsposten i visningsmodus og går til fanen ”Delegations”.
Paginering er satt opp slik at det bare vises 10 delegeringsregler.
For å legge til en delegering klikker du på knappen ”
” øverst til høyre i delegeringstabellen.
Angi følgende informasjon for å opprette en delegering:
- Delegaten: personen som mottar de delegerte rollene og/eller autorisasjonene (påkrevd)
- Den delegerte rollen eller de delegerte rollene (påkrevd)
- Den delegerte autorisasjonen eller de delegerte autorisasjonene (valgfritt)
- Start- og sluttdato for delegeringen (valgfritt)
For å endre delegeringer klikker du på ikonet ”
” til høyre i den aktuelle raden i tabellen.
Du kan endre alle parameterne.
For å slette en delegering klikker du på ikonet ”
” til høyre i den aktuelle raden i tabellen.
Det vises en bekreftelsesmelding før delegeringen slettes.
Vise kontoene og autorisasjonene til en identitet¶
Kontoene i de ulike applikasjonsrepositoryene beregnes ut fra de definerte administrasjonsreglene og de rollene og autorisasjonene som er tilordnet identitetene.
Administrasjonsreglene for kontoer er:
- Definisjon av en kontostatus ut fra en identitetsstatus,
- Definisjon av regler for sammenslåing av kontoer ved flere identiteter,
- Definisjon av regler for kontooppretting som utelukkende baserer seg på rolletilordningen.
For å vise kontoene og autorisasjonene som er knyttet til en identitet, åpner du den ønskede identitetsposten i visningsmodus og går til fanen ”Accounts”.
Denne fanen er bare tilgjengelig i visningsmodus og viser resultatene av beregningene av kontoer og autorisasjoner som er utført på identiteten, eller på alle identitetene ved identitetsavstemming. I det siste tilfellet er fanen felles for alle identitetene i avstemmingskjeden.
Det vises en tabell med de beregnede kontoene. For hver konto inneholder en nestet tabell autorisasjonene som er knyttet til kontoen. En konto kan genereres uten tilhørende autorisasjoner.
Hvis flere identiteter er avstemt og en konto er felles for flere identiteter (funksjonen for sammenslåing av kontoer er aktivert), kjennetegnes kontoen av ikonet ”
”.
Paginering er satt opp slik at det bare vises 10 kontoer.
I tabellen som er innebygd under en konto, er pagineringen satt opp slik at det bare vises 5 autorisasjoner.
Et søkefelt er tilgjengelig øverst til høyre i kontotabellen. Søket dekker påloggingsnavnene til kontoene eller navnene på repositoryene.
Den teoretiske statusen og provisjoneringsstatusen til kontoene er synlig på hver rad i tabellen.
I tabellen som er innebygd under en konto, er det et søkefelt øverst i autorisasjonstabellen. Søket dekker navnene på applikasjonene eller autorisasjonene.
Den teoretiske statusen og provisjoneringsstatusen til autorisasjonene er synlig på hver rad i tabellen.
En forklaring som beskriver de ulike teoretiske statusene og provisjoneringsstatusene, hjelper brukerne med å forstå de forskjellige statusene.
Kontotilstanden ”Archived”¶
Fra og med versjon 7.1 finnes det en ny teoretisk kontotilstand: tilstanden ”Archived”.
I noen tilfeller er det helt nødvendig å beholde en historikk over kontoene i bestemte repositoryer. Det viktigste brukstilfellet er å aldri generere et påloggingsnavn som kan ha eksistert tidligere.
Denne tilstanden gjelder kontoer som ikke lenger finnes i mål-repositoryet og ikke lenger er knyttet til noen identitet i CyberElements Identity. Disse kontoene beholdes i Identity-databasen, men synkroniseres aldri. De telles heller ikke med i lisensadministrasjonen.
Tilstanden ”Archived” har koden 3, etter de fire eksisterende tilstandene:
| Kode | Teoretisk kontostatus |
|---|---|
-1 |
No account |
0 |
Theoretical account only |
1 |
Account enabled |
2 |
Account disabled |
3 |
Account archived |
Når en konto er knyttet til flere identiteter, beregnes tilstanden etter følgende prioritetsrekkefølge: Enabled, deretter Disabled, deretter Archived, deretter Theoretical og til slutt No account. En konto er derfor bare arkivert hvis ingen av de tilknyttede identitetene gir den en aktivert, deaktivert eller teoretisk tilstand. En person telles bare med i lisensene hvis vedkommende har minst én konto som ikke er arkivert.
Modellen for en arkivert konto kan ikke lenger endres: endringen avvises med en feilmelding.
Det finnes to måter å tilordne tilstanden ”Archived” til en konto på:
- via provisjoneringsmotoren SIP: i en Identity-import av typen ACCOUNT eller av typen STATUS setter et alternativ tilstanden ”Archived” på kontoene som er identifisert i sletteoperasjonene. Se siden Opprette/endre importregler.
- via grensesnittet, ved å endre den teoretiske tilstanden manuelt og én konto om gangen, forutsatt at den er kvalifisert både i endringsskjemaet og i Identity-rettighetene.
Kvalifiseringen i skjemaet angis på attributtet ”Theoretical account status” (account_state), i ”Configuration / Attribute templates”, fanen ”Account”: i delen ”Display” må feltet ”Display in edit” gjøre attributtet synlig. Det er satt til ”Hide” som standard, og den teoretiske tilstanden vises da ikke i skjemaet for endring av kontoen.
Når det gjelder Identity-rettighetene, styres endring av dataene til en konto av rettigheten ”140_550_002 - Modify account details” i CyberElements Identity-repositoryet.
Advarsel
Siden disse kontoene ikke eksporteres av provisjoneringsmotoren, kan en tilbakeføring fra arkivert tilstand bare gjøres manuelt og én konto om gangen i grensesnittet, på de samme kvalifiseringsvilkårene.
Tilbakestille passordet til en konto¶
Fra og med versjon 7.1 finnes det et nytt boolsk systemattributt på kontoer: account_password_reset.
Det har form av en knapp på kontosidene. Som standard er verdien usann og etiketten ”Reset password”. Når du klikker på den, blir verdien sann, og etiketten endres til ”Password reset”.
Knappen vises i høyre panel på detaljsiden for kontoen, under kontonavnet. I ”Configuration / Attribute templates”, fanen ”Account”, vises attributtet med etiketten ”Password reset state”, av typen ”Boolean”. Det opprettes automatisk ved oppgradering til 7.1, både på en SQL Server- og en PostgreSQL-database.
Advarsel
Denne verdien er bare teoretisk. For at den skal ha noen effekt, må du bruke enten en provisjoneringskonnektor eller en workflow for manuell provisjonering. Endringen av verdien fra sann til usann, når passordet er endret i målapplikasjonen, må også håndteres av en konnektor eller av workflowen for manuell provisjonering.
Bruk i en provisjoneringskonnektor:
Bruk av dette systemattributtet til å håndtere passordendringer i konnektorer for automatisk provisjonering må gjøres med konnektorer som er beregnet på dette formålet. Målapplikasjonen må også tillate passordendringer, noe som ikke alltid er tilfellet.
Utfør følgende operasjoner i synkroniseringsregelen:
- en konverteringsoperasjon, for å oppdage passordendringer;
- i sammenligningsregelen sammenligner du for hver person attributtet
account_password_resetmed verdien usann (det vil si0), for å oppdage en passordendring; - i endringsregelen tvinger du sending av passordet i målattributtet, med systemattributtet
password.
Opprett deretter en oppstrøms provisjoneringskonnektor for å sette den boolske verdien account_password_reset tilbake til usann.
Provisjonering/deprovisjonering av kontoer og autorisasjoner¶
Prosessen der kontoene og autorisasjonene som CyberElements Identity har beregnet, overføres til de ulike applikasjonsrepositoryene, kalles downstream-provisjonering. CyberElements Identity har dermed autoritet over applikasjonene som er definert for å administrere kontoer og autorisasjoner.
Det finnes to måter å administrere provisjonering på:
- Enten kan det opprettes en automatisk konnektor (via API, database, katalog eller automatisert utveksling av flate filer); i det tilfellet snakker vi om automatisk provisjonering.
- Eller det er ikke mulig å opprette en automatisk konnektor; i det tilfellet snakker vi om halvautomatisk provisjonering.
Automatisk provisjonering/deprovisjonering¶
For å provisjonere kontoer og autorisasjoner i applikasjonsrepositoryer må du bruke motoren Systancia Identity Provisioning (SIP) for å opprette en konnektor for downstream-provisjonering: fra CyberElements Identity, som er den autoritative kilden, og med hensyn til de konfigurerte synkroniseringsreglene, opprettes, oppdateres eller slettes kontoer og autorisasjoner i applikasjonsrepositoryene i henhold til reglene som er definert i importreglene.
En sekvens for downstream-provisjonering må minst bestå av følgende elementer:
- En eksport av Identity-repositoryet (autoritativt) av typen ”USER + ACCESS” eller ”ACCOUNT + ACCESS”
- En eksport av mål-applikasjonsrepositoryet
- En synkroniseringsregel
- En importregel i mål-applikasjonsrepositoryet
Se siden ”Administrasjon av automatiske provisjoneringskonnektorer” for å opprette en konnektor.
Halvautomatisk provisjonering/deprovisjonering¶
En halvautomatisk provisjoneringskonnektor opprettes med en workflow av typen ”User request” eller ”Event” med minst én manuell provisjonerings- eller deprovisjoneringsoppgave.
I den manuelle provisjoneringsoppgaven listes provisjoneringshandlingene som skal utføres, opp i en varsling som sendes til operatøren. Når operatøren har fullført oppgaven, kan operatøren klikke på knappen ”Task validated” for å angi at provisjoneringen er fullført. Provisjoneringsstatusen til kontoen og/eller autorisasjonene oppdateres i CyberElements Identity. Dette gjør at administratorene kan kontrollere statusen til rettighetene til en identitet.





















































































