Administration af konti og autorisationer¶
Kontoadministration omfatter oprettelse, ændring og sletning af brugerkonti for de forskellige applikationer, der administreres i organisationen. Det indebærer, at brugerne tildeles unikke identifikatorer (såsom brugernavne eller medarbejdernumre), og at de oplysninger, der er knyttet til disse konti, administreres.
Administration af tilladelser består i at give hver identitet specifikke adgangsrettigheder og autorisationer ud fra dens rolle, ansvarsområder, organisation og behov i organisationen. Disse autorisationer kan omfatte adgang til applikationer, data, netværk, systemer, fysiske ressourcer osv.
Administration af en identitets roller og tilladelser omfatter beregning og tildeling af tilladelser til identiteter i forskellige applikationer med henblik på at opbygge et teoretisk repository over identiteterne og deres tilladelser. Det betyder, at alle beregnede konti, roller og autorisationer kan provisioneres automatisk eller manuelt i de forskellige målapplikationer.
CyberElements Identity giver mulighed for at administrere roller og autorisationer enten automatisk via autorisationsregler eller diskretionært via manuelle tilføjelser af rettigheder eller formularanmodninger (workflow).
Administration af kontotyper¶
En kontotype består af flere elementer:
- En login-politik (obligatorisk),
- En adgangskodepolitik (valgfri),
- Kontoattributter (valgfri),
- Kontostatusser, der defineres ud fra identitetsstatusserne
En kontotype skal være knyttet til et repository og til en rolle for at kunne generere konti. Det er derfor muligt at have flere konti i samme repository for den samme identitet, hvis denne identitet har flere forskellige roller.
Opret/ændr/slet en kontotype for et repository¶
Se siden Administration af objekttyper for administration af kontotyper, konfiguration af de forskellige formularer osv.
Opret/ændr/slet en login-politik¶
For at få adgang til administration af login-politikker skal du åbne menuen ”Access Management/Account Rules”.
Du føres direkte til listen over eksisterende login-politikker, der er forudindlæst i en tabel uden anvendte filtre.
Sideinddelingen er sat op til kun at vise 10 login-politikker.
Der er et søgefelt øverst til højre i tabellen. Søgningen omfatter attributterne ”code” og ”name” for login-politikker.
For at oprette en ny login-politik skal du klikke på knappen ”
”.
Indtast parametrene for en login-politik:
-
Code: kode for login-politikken. Skal være unik, uden mellemrum og uden specialtegn. Obligatorisk.
-
Name: navn på login-politikken. Den betegnelse, der vises i applikationens forskellige formularer. Obligatorisk.
-
Description: felt til indtastning af en beskrivelse af login-politikken. Valgfri.
-
Formula (primary): beregningsformel til at definere login
-
Duplicate policy:
- Automatic increment: login beregnes ved hjælp af den primære formel og suppleres med et duplikatindeks. Duplikatindekset har et format med 3 cifre.
- Eksempel: Login_Calc002
- Formula (duplicate): brugerdefineret beregningsformel, hvis der registreres et duplikat ved beregning af login med den primære formel. Du kan bruge nøgleordet §INDEX_DOUBLON§ til at styre den automatiske optælling, men placér det på et bestemt sted. Siden Identity 7.0 SP3 starter nøgleordet §INDEX_DOUBLON§ ved 1 og har ingen øvre grænse. For tidligere versioner har duplikatindekset et format med 3 cifre.
- Eksempel: Formula (duplicate) Login2_Calc
Advarsel: for at teste formlen med dette nøgleord skal du erstatte §INDEX_DOUBLON§ med en værdi. Dette nøgleord kan ikke fortolkes i formeltesteren, men det virker ved beregning af login.
- Automatic increment: login beregnes ved hjælp af den primære formel og suppleres med et duplikatindeks. Duplikatindekset har et format med 3 cifre.
-
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 at se og ændre en login-politik skal du klikke på ikonet ”
” til højre i den tilsvarende tabelrække:
Det er muligt at skifte til redigeringstilstand direkte fra visningssiden for login-politikken.
I redigeringstilstand kan alle felter ændres.
Handlinger for knapperne i redigerings- eller oprettelsestilstand:
- Cancel: annullerer den aktuelle indtastning og skifter siden til visningstilstand
- Save: bekræfter formularen og skifter siden til visningstilstand
- Save and quit: bekræfter formularen og vender tilbage til listesiden for login-politikker
For at slette en login-politik skal du klikke på ikonet ”
” til højre i den tilsvarende tabelrække:
Der vises en bekræftelsesmeddelelse, før login-politikken slettes.
Advarsel: det er ikke muligt at slette en login-politik, så længe den er knyttet til et eller flere repositories.
Opret/ændr/slet en adgangskodepolitik¶
For at få adgang til administration af adgangskodepolitikker skal du åbne menuen ”Access management/Password rules”.
Du føres direkte til listen over eksisterende adgangskodepolitikker, der er forudindlæst i en tabel uden anvendte filtre.
Sideinddelingen er sat op til kun at vise 10 adgangskodepolitikker.
Der er et søgefelt øverst til højre i tabellen. Søgningen omfatter attributterne ”code” og ”name” for adgangskodepolitikker.
For at oprette en ny adgangskodepolitik skal du klikke på knappen ”
”:
Indtast parametrene for en adgangskodepolitik:
- Code: kode for login-politikken. Skal være unik, uden mellemrum og uden specialtegn. Obligatorisk.
- Name: navn på login-politikken. Den betegnelse, der vises i applikationens forskellige formularer. Obligatorisk.
- Description: felt til indtastning af en beskrivelse af adgangskodepolitikken. Valgfri.
- Formula: beregningsformel til at definere adgangskoden
For at se og ændre en adgangskodepolitik skal du klikke på ikonet ”
” til højre i den tilsvarende tabelrække:
Du kan skifte til redigeringstilstand direkte fra visningssiden for adgangskodepolitikken.
I redigeringstilstand kan alle felter ændres.
Handlinger for knapperne i redigerings- eller oprettelsestilstand:
- Cancel: annullerer den aktuelle indtastning og skifter siden til visningstilstand
- Save: bekræfter formularen og skifter siden til visningstilstand
- Save and quit: bekræfter formularen og vender tilbage til listesiden for adgangskodepolitikker
For at slette en adgangskodepolitik skal du klikke på ikonet ”
” til højre for den tilsvarende tabelrække:
Der vises en bekræftelsesmeddelelse, før adgangskodepolitikken slettes.
Advarsel: du kan ikke slette en adgangskodepolitik, hvis den er knyttet til et eller flere repositories.
Visning af konti i et repository¶
For at søge efter en konto skal du åbne menuen ”Accounts”.
Du føres direkte til søgesiden for konti i et valgt repository (det første på listen), forudindlæst uden anvendte filtre, men under overholdelse af de tilladelser, der er knyttet til den tilsluttede brugers profil.
Da konti er knyttet til et repository, skal du vælge det ønskede repository enten via fanerne eller via rullelisten for at få vist listen over de tilknyttede konti.
Visningstilstanden defineres ud fra antallet af repositories. Enten er der 10 eller færre repositories, og de vises i separate faner, eller de vises på en rulleliste.
Sideinddelingen er sat op til kun at vise 10 konti.
Der er et søgefelt øverst til højre i tabellen. Søgningen omfatter kontienes login og tager hensyn til det valgte repository.
Konfigurér tabellen med søgeresultater for konti¶
For at konfigurere de attributter, der skal med i tabellen med søgeresultater for konti, skal du åbne siden til konfiguration af attributter, vælge fanen ”Account”, åbne det ønskede attribut i redigeringstilstand og markere indstillingen ”Display in results table”.
Afstem/ophæv afstemning af en teoretisk konto med en reel konto¶
For at komme til siden for administration af kontoafstemning skal du åbne menuen ”Accounts” og aktivere indstillingen ”Reconciliation”:
Der vises to nye tabeller i vinduet:
Den anden tabel viser de forældreløse konti i det valgte repository. Til påmindelse: forældreløse konti er konti, der er hentet fra mål-repository, men som ikke er knyttet til nogen identitet i CyberElements Identity.
Den tredje tabel viser de identiteter, der ikke er knyttet til nogen konto i det valgte repository.
I denne tabel kan du for hver identitet uden konto:
- Knytte en eksisterende teoretisk konto. Klik på knappen
til højre for den ønskede identitet, og søg derefter efter den ønskede eksisterende teoretiske konto. - Oprette en teoretisk konto. Klik på knappen
til højre for den ønskede identitet, og opret derefter den teoretiske konto ved at vælge den ønskede kontotype.
Vigtig bemærkning
Funktionen er fjernet i de ældre grænseflader, fordi det ikke er muligt at bevare begge tilstande.
Diskretionær administration af roller og autorisationer¶
For manuelt at ændre rolletildelinger og autorisationer for en identitet skal du åbne den ønskede identitetspost i visningstilstand og gå til fanen ”Roles and Authorizations”.
Der vises en tabel med de roller, der er tildelt identiteten. For hver rolle indeholder en indlejret tabel de autorisationer, der er knyttet til identiteten og tildelt rollen. En autorisation skal være knyttet til et par Identity/Role.
Hvis flere identiteter er afstemt, vises der en fane for hver identitet, så du kan vælge den ønskede identitet. Roller/autorisationer er knyttet til en identitet og ikke til en afstemningskæde. Det er derfor nødvendigt at vælge den ønskede identitet, før du foretager manuelle opdateringer.
Sideinddelingen er sat op til kun at vise 10 roller.
I tabellen, der er indlejret under en rolle, er sideinddelingen sat op til kun at vise 5 autorisationer.
Der er et søgefelt øverst til højre i rolletabellen. Søgningen er baseret på rollernes navne.
I tabellen, der er indlejret under en rolle, er der et søgefelt øverst i autorisationstabellen. Søgningen omfatter attributterne ”Category”, ”Code” og ”Name” for autorisationer.
Du finder følgende oplysninger i autorisationstabellen:
- Dens status:
- ”Valid”: autorisationen er synlig uden nogen særlig markering
- ”Blocked”: autorisationen er synlig, men gennemstreget i grænsefladen
- Tildelingstilstand. De mulige værdier er
: manuel, med UID for den identitet, der har foretaget tildelingen
: autorisationsregel, med navnet på reglen eller reglerne
: autorisation tildelt ved rollearv
: det første ikon angiver, at rettigheden er tilføjet manuelt (via et workflow), og det andet giver adgang til workflowet (link til workflowets betjeningsgrænseflade).
For at tilføje en eller flere roller eller for at tilføje en eller flere autorisationer til flere roller for den samme identitet skal du klikke på knappen ”
” øverst til højre i rolletabellen.
Vælg den eller de ønskede roller, og klik derefter på Confirm for at tilføje rollerne og gå videre til næste trin, eller på Cancel for at annullere operationen.
For at tilføje en eller flere autorisationer til en rolle, der allerede er knyttet til identiteten, skal du klikke på knappen ”
” til højre i den tilsvarende række i rolletabellen.
Vælg den eller de ønskede autorisationer, og klik derefter på knappen ”Confirm” for at knytte dem til rollen eller på knappen ”Cancel” for at annullere operationen. Det er muligt at angive en start- og en slutdato, som anvendes på alle de valgte autorisationer.
-
Handlingsknapper for autorisationer:
: gør det muligt at blokere autorisationen.
: gør det muligt at ophæve blokeringen af autorisationen.
: gør det muligt at certificere autorisationen.
: gør det muligt at slette certificeringen af autorisationen.
: gør det muligt at ændre gyldighedsdatoerne. Knappen er kun tilgængelig for manuelle rettigheder.
Advarsel: knappen til at slette en autorisation findes kun, hvis autorisationen udelukkende er tildelt diskretionært. Autorisationen kan fortsat være synlig med status ”pending deletion”, hvis dens provisioning-status er ”provisioned”.
For at ophæve en rolles tilknytning til en identitet skal du klikke på ikonet ”
” til højre for den tilsvarende række i rolletabellen.
Der vises en bekræftelsesmeddelelse, før rollen slettes.
Advarsel: knappen til at slette en rolle findes kun, hvis rollen er tildelt diskretionært. Alle autorisationer, der er knyttet til parret identitet/rolle, får også deres tilknytning ophævet og deprovisioneres ved næste synkronisering i tilfælde af automatisk provisioning.
Administration af autorisationsregler¶
Autorisationsregler gør det muligt at konfigurere adgangspolitikker og automatisk tildele rettigheder til de identiteter, som reglen udpeger.
En autorisationsregel består i at knytte:
- på den ene side en population af brugere, defineret ved filtrering på roller (RBAC), organisationer (OrBAC) og/eller attributværdier (ABAC),
- på den anden side roller og applikationsrettigheder.
For at få adgang til administration af autorisationsregler skal du åbne menuen ”Access Management / Authorization Rules”.
Du føres direkte til siden med listen over eksisterende autorisationsregler, forudindlæst uden anvendte filtre, men under overholdelse af de autorisationer, der er knyttet til den tilsluttede persons profil.
Sideinddelingen er sat op til kun at vise 10 regler.
Der er et søgefelt øverst til højre i regeltabellen. Søgningen er baseret på reglernes navne.
For at oprette en ny autorisationsregel skal du klikke på knappen ”
”.
Oprettelsen af en regel består af tre dele:
-
Generelle indstillinger
- Name: navn på autorisationsreglen. Obligatorisk.
- Description: felt til indtastning af en beskrivelse af autorisationsreglen. Valgfri.
- Context: vælg en eller flere kontekster på rullelisten med de tidligere oprettede kontekster.
-
Liste over kriterier: klik på knapperne ” ” eller ” ” for at tilføje en filtreringsregel for de identiteter, der skal medtages i autorisationsreglen. En filtreringsregel består i at definere et attribut, som et filter skal anvendes på, samt sammenligningsoperatoren og de værdier, der skal sammenlignes.
- Knappen ”
” gør det muligt at tilføje et nyt filter på samme niveau som det forrige filter. - Knappen ”
” gør det muligt at tilføje en gruppe af filtre på samme niveau som det forrige filter. Det er obligatorisk at tilføje filtre eller filtergrupper til en gruppe ved hjælp af knapperne ”
” eller ”
” i gruppen. - På hvert filterniveau skal du angive den operator, der skal anvendes mellem hver filterregel.
- Et objekt, som du vil udføre en sammenligning på. Det kan være:
- En rolle
- Et personattribut
- Et strukturattribut
- Et ressourceattribut
- Sammenligningsoperator. Listen over sammenligningsoperatorer er dynamisk og afhænger af typen af det valgte objekt.
- En værdi, der skal sammenlignes: indtastes eller vælges på en rulleliste, afhængigt af typen af det valgte objekt og af sammenligningsoperatoren.
- Knappen ”
Du kan tilføje så mange filterkriterier, som du ønsker. Operatorer som ”AND” eller ”OR” skal fastlægges mellem hver filterregel. Der kan oprettes undergrupper for at øge antallet af muligheder.
Eksempel: sådan opretter 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”)
Filterkriterierne konfigureres som følger:
- Roller og autorisationer, der skal tildeles i autorisationsreglen: der er to faner til visning af de roller og autorisationer, der skal medtages i autorisationsreglen. Fanen ”Role” viser listen over roller og angiver kort de tilhørende autorisationer, hvis der er nogen. Det er også fra denne fane, at roller og autorisationer kan tilføjes eller fjernes. Fanen ”Authorizations” viser listen over de autorisationer, der er tilføjet reglen, med den eller de tilknyttede roller for hver af dem. Denne fane giver blot en anden visning.
Listen over autorisationer filtreres efter de valgte roller (en rolle er knyttet til et eller flere repositories).
For at se og ændre en autorisationsregel skal du klikke på ikonet ”
” til højre i den tilsvarende tabelrække:
Visningstilstanden gør det muligt at se detaljerne for en autorisationsregel og også listen over de identiteter, der er berørt af reglen.
Du kan søge efter en person ved hjælp af søgefeltet øverst til højre i tabellen.
Du kan skifte til redigeringstilstand ved at klikke på knappen ”Edit”.
I redigeringstilstand kan alle felter ændres.
Bemærk: listen over de personer, der er berørt af reglen, opdateres ikke i realtid, når en regel ændres. Den opdateres, når reglen er bekræftet, og beregningerne er afsluttet.
Handlinger for knapperne i oprettelses- og redigeringstilstand:
- Cancel: annullerer den aktuelle indtastning og skifter siden til visningstilstand
- Save: bekræfter formularen og skifter siden til visningstilstand. Beregningerne udføres automatisk.
- See Impact: viser konsekvenserne af at oprette eller opdatere reglen. Konsekvenserne vises i to tabeller:
- Den første tabel viser reglens konsekvenser for rettighederne, hvor der kun tages hensyn til den autorisationsregel, der er oprettet eller ændret. Alle identiteter, der matcher kriterierne, vises, herunder de identiteter, som tilladelsen allerede er tildelt ad anden vej. Selv om personen faktisk mister sine rettigheder som følge af ændringen af autorisationsreglen, kan hun altså stadig bevare dem ad anden vej.
- Den anden tabel viser reglens samlede konsekvenser for rettighederne. Dette afsnit tager hensyn til alle regler i CyberElements Identity, de diskretionære tildelinger af rettigheder og de rettigheder, der er blokeret af en regel om adskillelse af rettigheder. Hvis en identitet allerede har fået tilladelsen tildelt ad anden vej, medtages kontoen ikke på denne liste. Der vises de rettigheder, der faktisk bliver berørt/slettet, når ændringen bekræftes.
I denne anden tabel er det muligt at anvende en frist, før rettigheden faktisk slettes (anvendelse af en overgangs- eller overlapsperiode).
For at slette en autorisationsregel skal du klikke på ikonet ”
” til højre i den tilsvarende tabelrække:
Der vises en bekræftelsesmeddelelse, før en autorisationsregel slettes.
Ikonet ”
” angiver en autorisationsregel, der er under beregning. Hvis det er grået ud, betyder det, at beregningerne er afsluttet.
Administration af regler for funktionsadskillelse (SoD)¶
Funktionsadskillelse (SoD): er et væsentligt sikkerhedsprincip, der består i at fordele ansvar og privilegier i en organisation eller et system for at minimere risici og forebygge interessekonflikter. Det indføres for at sikre en ansvarlig og sikker brug af it-systemerne og virksomhedens ressourcer.
En regel for funktionsadskillelse består i:
- At definere en prioritetsgruppe
- At tilføje roller eller autorisationer til prioritetsgruppen med en prioritetsvægt
For at få adgang til administration af regler for funktionsadskillelse skal du åbne menuen ”Access Management / SoD Rules”. Fra og med version 7.1 tilbyder denne menu to undermenuer: Identities og Accounts.
Fra og med version 7.1 giver modulet til funktionsadskillelse dig mulighed for at oprette regler, der gælder enten for autorisationer eller for roller, og at tilføje filtre, der er rettet mod identiteter eller konti, for at begrænse en regels rækkevidde.
De to undermenuer svarer til de to niveauer, som en regel kan gælde på:
- Identities: for en enkelt identitet, der ville have rettigheder, som er indbyrdes uforenelige;
- Accounts: når en person har flere identiteter, der deler den samme konto (sammenlægning af konti), og disse identiteters samlede rettigheder falder ind under en regel for funktionsadskillelse.
Hver af disse to undermenuer indeholder to faner, Roles og Rights. Fanen Roles definerer prioriteter for rollerne i en gruppe, fanen Rights for autorisationerne i en gruppe. Den fremgangsmåde, der er beskrevet nedenfor, er identisk på begge faner, idet det objekt, der føjes til prioritetsgruppen, alt efter tilfældet er en rolle eller en autorisation.
En regels detaljeside viser under reglens kode, navn og beskrivelse tre blokke: listen over kriterier (de filtre, der er rettet mod identiteter eller konti), listen over tilknyttede autorisationer — eller roller — og listen over de identiteter, der er berørt af reglen.
Når en regel låser eller låser en rolle eller en autorisation op for en bruger, registreres handlingen i audits med navnet på den regel, der udløste den. Disse registreringer gør det muligt at finde den regel, der skal gennemgås, i tilfælde af en uønsket låsning.
Visning og ændring af regler styres af rettighederne ”220_001 - View a segregation of duties rule” og ”220_002 - Modify a segregation of duties rule” i CyberElements Identity-repositoryet.
Du føres direkte til siden med listen over eksisterende regler for funktionsadskillelse, forudindlæst uden anvendte filtre, men under overholdelse af de autorisationer, der er knyttet til den tilsluttede persons profil.
Sideinddelingen er sat op til kun at vise 10 regler.
Der er et søgefelt øverst til højre i regeltabellen. Søgningen er baseret på prioritetsgruppernes navn (= navnet på reglen for funktionsadskillelse).
For at oprette en ny regel for funktionsadskillelse skal du klikke på knappen ”
”:
Oprettelsen af en regel for funktionsadskillelse foregår i to trin.
Indtast først de generelle parametre:
- Code: kode for reglen for funktionsadskillelse. Obligatorisk.
- Name: navn på tilladelsesreglen. Obligatorisk.
- Description: felt til indtastning af en beskrivelse af reglen for funktionsadskillelse. Valgfri.
Gem oprettelsesformularen for at gå videre til andet trin, tilføjelse af autorisationer.
For at tilføje en autorisation til SoD-reglen skal du klikke på knappen ”
” i tabellen ”List of associated rights”.
Vælg den ønskede autorisation, og indtast en vægt for at definere prioriteten. Jo lavere værdien er, jo højere er prioriteten.
For at ændre en autorisation i SoD-reglen skal du klikke på knappen ”
” til højre i den tilsvarende tabelrække.
Du kan ændre autorisationen og/eller prioritetsvægten.
For at slette en autorisation i SoD-reglen skal du klikke på knappen ”
” til højre i den tilsvarende tabelrække.
For at se og ændre en regel for funktionsadskillelse skal du klikke på ikonet ”
” til højre i den tilsvarende tabelrække.
Du kan skifte til redigeringstilstand ved at klikke på knappen ”Edit”.
I redigeringstilstand kan kun navnet og beskrivelsen ændres
For at slette en regel for funktionsadskillelse skal du klikke på ikonet ”
” i højre side af den tilsvarende tabelrække.
Der vises en bekræftelsesmeddelelse, før en autorisationsregel slettes.
Ansøg om rettigheder ved hjælp af formularer¶
Ansøg om rettigheder¶
Anmodninger om autorisationer til en person (eller til dig selv) foretages i den gamle betjeningskonsol via menuen ”Run an ‘On demand’ workflow”.
Klik på knappen ”Refresh” for at få vist listen over tilgængelige workflows.
Klik på det workflow, du ønsker, for at indsende en autorisationsanmodning.
Vælg en eller flere identiteter, som anmodningen vedrører.
Vælg de ønskede autorisationer på den tilgængelige liste. Angiv om nødvendigt start- og slutdatoer.
Klik på knappen ”Add”.
Du kan tilføje eller fjerne autorisationer efter ønske. Hvis du vil tilføje gyldighedsdatoer til en autorisation, der allerede er valgt, skal du slette den og derefter tilføje den igen med datoerne indtastet på forhånd.
Klik på knappen ”Start”, og bekræft i pop op-vinduet.
Når du har bekræftet udførelsen af workflowet, omdirigeres du automatisk til den side, hvor du kan se de igangværende anmodninger.
Indsend en anmodning om manuel provisionering (eller deprovisionering) af en autorisation¶
Anmodninger om manuel provisionering (eller deprovisionering) indsendes i den gamle betjeningskonsol via menuen ”Run an ‘On demand’ workflow”.
Klik på knappen ”Refresh” for at få vist listen over tilgængelige workflows.
Klik på det workflow, du ønsker, for at indsende en provisioneringsanmodning.
Vælg en eller flere identiteter, som anmodningen vedrører.
Vælg de ønskede autorisationer på den tilgængelige liste. Angiv om nødvendigt start- og slutdatoer.
Klik på knappen ”Add”.
Du kan tilføje eller fjerne autorisationer efter ønske. Hvis du vil tilføje gyldighedsdatoer til en autorisation, der allerede er valgt, skal du slette den og derefter tilføje den igen med datoerne indtastet på forhånd.
Klik på knappen ”Start”, og bekræft i pop op-vinduet.
Når du har bekræftet udførelsen af workflowet, omdirigeres du automatisk til den side, hvor du kan se de igangværende anmodninger.
Delegering af autorisationer¶
Delegering af autorisationer gør det muligt at overføre rettigheder fra en person (den delegerende) til en anden (den delegerede), generelt i en midlertidig periode.
Denne funktion er tilgængelig for de delegerende (afhængigt af den tilsluttede persons tilladelser), men fra og med version 7.0 kan en tredjepart (afhængigt af den tilsluttede persons tilladelser) også delegere rettigheder til en anden identitet (for eksempel en administrator).
For at få adgang til funktionen til delegering af autorisationer skal du åbne den ønskede identitetsfil i visningstilstand og gå til fanen ”Delegations”.
Sideinddelingen er sat op til kun at vise 10 delegeringsregler.
For at tilføje en delegering skal du klikke på knappen ”
” øverst til højre i delegeringstabellen.
Indtast følgende oplysninger for at oprette en delegering:
- Den delegerede: den person, der modtager de delegerede roller og/eller autorisationer (påkrævet)
- Den eller de delegerede roller (påkrævet)
- Den eller de delegerede autorisationer (valgfri)
- Start- og slutdato for delegeringen (valgfri)
For at ændre delegeringer skal du klikke på ikonet ”
” til højre i den tilsvarende række i tabellen.
Du kan ændre alle parametre.
For at slette en delegering skal du klikke på ikonet ”
” til højre i den tilsvarende række i tabellen.
Der vises en bekræftelsesmeddelelse, før delegeringen slettes.
Vis konti og autorisationer for en identitet¶
Konti i de forskellige applikationsrepositories beregnes ud fra de definerede administrationsregler og de roller og autorisationer, der er tildelt identiteterne.
Administrationsreglerne for konti er:
- Definition af en kontostatus ud fra en identitetsstatus,
- Definition af regler for sammenlægning af konti i tilfælde af flere identiteter,
- Definition af regler for oprettelse af konti, der udelukkende baseres på rolletildelingen.
For at se de konti og autorisationer, der er knyttet til en identitet, skal du åbne den ønskede identitetspost i visningstilstand og gå til fanen ”Accounts”.
Denne fane er kun tilgængelig i visningstilstand og viser resultaterne af de beregninger af konti og autorisationer, der er foretaget for identiteten eller – i tilfælde af identitetsafstemning – for alle identiteter. I sidstnævnte tilfælde er fanen fælles for alle identiteter i afstemningskæden.
Der vises en tabel med de beregnede konti. For hver konto indeholder en indlejret tabel de autorisationer, der er knyttet til kontoen. En konto kan genereres uden tilknyttede autorisationer.
Hvis flere identiteter er afstemt, og en konto er fælles for flere identiteter (funktionen til sammenlægning af konti er slået til), markeres kontoen med ikonet ”
”.
Sideinddelingen er sat op til kun at vise 10 konti.
I tabellen, der er indlejret under en konto, er sideinddelingen sat op til kun at vise 5 autorisationer.
Der er et søgefelt øverst til højre i kontotabellen. Søgningen omfatter kontienes login eller navnene på repositories.
Kontienes teoretiske status og provisioning-status er synlige i hver række i tabellen.
I tabellen, der er indlejret under en konto, er der et søgefelt øverst i autorisationstabellen. Søgningen omfatter navnene på applikationer eller autorisationer.
Autorisationernes teoretiske status og provisioning-status er synlige i hver række i tabellen.
En forklaring, der beskriver de forskellige teoretiske statusser og provisioning-statusser, hjælper brugerne med at forstå de forskellige statusser.
Kontotilstanden ”Archived”¶
Fra og med version 7.1 findes der en ny teoretisk kontotilstand: tilstanden ”Archived”.
I nogle tilfælde er det vigtigt at bevare en historik over konti i specifikke repositories. Det vigtigste brugsscenarie er aldrig at generere et login, der kan have eksisteret tidligere.
Denne tilstand vedrører konti, der ikke længere findes i mål-repositoryet og ikke længere er knyttet til nogen identitet i CyberElements Identity. Disse konti bevares i Identity-databasen, men synkroniseres aldrig. De tælles heller ikke med i licensadministrationen.
Tilstanden ”Archived” har koden 3 efter de fire eksisterende tilstande:
| 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 dens tilstand efter følgende prioritetsrækkefølge: Enabled, derefter Disabled, derefter Archived, derefter Theoretical og derefter No account. En konto arkiveres derfor kun, hvis ingen af de tilknyttede identiteter giver den en aktiveret, deaktiveret eller teoretisk tilstand. En person tælles kun med i licenserne, hvis vedkommende har mindst én ikke-arkiveret konto.
Modellen for en arkiveret konto kan ikke længere ændres: ændringen afvises med en fejlmeddelelse.
Der er to måder at tildele en konto tilstanden ”Archived” på:
- via SIP-provisioneringsmotoren: i en Identity-import af typen ACCOUNT eller af typen STATUS sætter en indstilling tilstanden ”Archived” på de konti, der er identificeret i sletningshandlingerne. Se siden Opret/ændr importregler.
- via grænsefladen ved at ændre den teoretiske tilstand manuelt og én konto ad gangen, forudsat at kontoen er berettiget både i ændringsformularen og i Identity-rettighederne.
Berettigelsen i formularen indstilles på attributtet ”Theoretical account status” (account_state) i ”Configuration / Attribute templates” på fanen ”Account”: i sektionen ”Display” skal feltet ”Display in edit” gøre attributtet synligt. Det er som standard sat til ”Hide”, og den teoretiske tilstand vises så ikke i formularen til ændring af kontoen.
Hvad angår Identity-rettighederne, styres ændring af en kontos data af rettigheden ”140_550_002 - Modify account details” i CyberElements Identity-repositoryet.
Advarsel
Da disse konti ikke eksporteres af provisioneringsmotoren, kan en tilbagevenden fra en arkiveret tilstand kun ske manuelt og én konto ad gangen i grænsefladen under de samme betingelser for berettigelse.
Nulstil adgangskoden til en konto¶
Fra og med version 7.1 findes der et nyt boolesk systemattribut på konti: account_password_reset.
Det har form af en knap på kontosiderne. Som standard er dets værdi falsk, og dets etiket er ”Reset password”. Når du klikker på den, bliver værdien sand, og etiketten skifter til ”Password reset”.
Knappen vises i panelet til højre på kontoens detaljeside under kontoens navn. I ”Configuration / Attribute templates” på fanen ”Account” vises attributtet under etiketten ”Password reset state” af typen ”Boolean”. Det oprettes automatisk ved opgradering til 7.1, både på en SQL Server- og en PostgreSQL-database.
Advarsel
Denne værdi er kun teoretisk. For at den skal have en virkning, skal du bruge enten en provisioneringskonnektor eller et manuelt provisionerings-workflow. Ændringen af værdien fra sand til falsk, når adgangskoden er ændret i målapplikationen, skal også håndteres af en konnektor eller af det manuelle provisionerings-workflow.
Brug i en provisioneringskonnektor:
Brugen af dette systemattribut til at håndtere ændringer af adgangskoder i automatiske provisioneringskonnektorer skal ske med konnektorer, der er dedikeret til dette formål. Destinationsapplikationen skal også tillade ændringer af adgangskoder, hvilket ikke altid er tilfældet.
Udfør følgende operationer i synkroniseringsreglen:
- en konverteringsoperation til at registrere ændringer af adgangskoder;
- i sammenligningsreglen skal du for hver person sammenligne attributtet
account_password_resetmed værdien falsk (dvs.0) for at registrere en ændring af adgangskoden; - i ændringsreglen skal du gennemtvinge afsendelsen af adgangskoden i destinationsattributtet med systemattributtet
password.
Opret derefter en opstrøms provisioneringskonnektor for at sætte den booleske værdi account_password_reset tilbage til falsk.
Provisionering/deprovisionering af konti og autorisationer¶
Den proces, hvor de konti og autorisationer, der er beregnet af CyberElements Identity, overføres til de forskellige applikationsrepositories, kaldes downstream-provisionering. CyberElements Identity har således autoritet over de applikationer, der er defineret til at administrere konti og autorisationer.
Der er to måder at administrere provisionering på:
- Enten kan der oprettes en automatisk konnektor (via API, database, katalog eller automatiseret udveksling af flade filer); i det tilfælde taler man om automatisk provisionering.
- Eller det er ikke muligt at oprette en automatisk konnektor; i det tilfælde taler man om halvautomatisk provisionering.
Automatisk provisionering/deprovisionering¶
For at provisionere konti og autorisationer i applikationsrepositories skal du bruge Systancia Identity Provisioning-motoren (SIP) til at oprette en downstream-provisioneringskonnektor: ud fra CyberElements Identity, som er den autoritative kilde, og under hensyntagen til de konfigurerede synkroniseringsregler oprettes, opdateres eller slettes konti og autorisationer i applikationsrepositories i henhold til de regler, der er defineret i importreglerne.
En downstream-provisioneringssekvens skal mindst bestå af følgende elementer:
- En eksport af Identity-repository (autoritativt) af typen ”USER + ACCESS” eller ”ACCOUNT + ACCESS”
- En eksport af målapplikationens repository
- En synkroniseringsregel
- En importregel i målapplikationens repository
Se siden ”Administration af automatiske provisioneringskonnektorer” for at oprette en konnektor.
Halvautomatisk provisionering/deprovisionering¶
En halvautomatisk provisioneringskonnektor oprettes ved hjælp af et workflow af typen ”User request” eller ”Event” med mindst én manuel provisionerings- eller deprovisioneringsopgave.
I den manuelle provisioneringsopgave vises de provisioneringshandlinger, der skal udføres, i en notifikation, der sendes til operatøren. Når operatøren har udført opgaven, kan han klikke på knappen ”Task validated” for at angive, at provisioneringen er afsluttet. Kontoens og/eller autorisationernes provisioning-status opdateres i CyberElements Identity. Det gør det muligt for administratorer at kontrollere status for en identitets rettigheder.





















































































