Har du någon gång suttit och slitit ditt hår när du försökt förstå hur accessreglerna fungerar då du sitter och letar efter fel? Jag har… Det går ju att debugga ACL-reglerna rätt bra men för att göra det lättare att förvalta plattformen kan det vara bra att man har definierat en struktur för tilldelning av rättigheter som alla förstår och använder. Detta går nog att göra på olika sätt men här är ett förslag hur man kan jobba med att tilldela rättigheter för de som ska kunna se olika saker samt de som ska kunna jobba med olika saker i ServiceNow.
Allt i denna artikel är gjort i Orlando.
När vi jobbar med rättigheter har vi lite olika komponenter att tillgå i ServiceNow:
Access Control Rules (ACL)
Själva reglerna som definierar access till olika tabeller och fält
Roller
ACL:er kan kopplas till roller som används antingen av grupper eller läggs direkt på personer (vilket man inte ska göra).
Grupper
En grupp kan kopplas till en roll som har vissa rättigheter (d.v.s. associerade till ACL-regler). Medlemmar i en grupp får relaterade rättigheter. Det är endast på detta sätt man ska tilldela rättigheter till personer. Inga rättigheter ska läggas direkt på en person även om det rent tekniskt är möjligt. Genom att koppla rättigheter/roller till gruppen kan man göra justeringar i gruppen som slår på alla medlemmar. Det är även lätt att ge och ta bort rättigheter från personer.
Skapa och uppdatera ACL:er
För att kunna skapa och uppdatera ACL:er som diskuteras i denna artikel måste admin få rättigheter att göra det. Annars kan han/hon endast läsa dessa.
1. Klicka på “System Administrator” (eller den användare som du har i den listan):
2. Markera “security_admin” och klicka “Ok”. Nu kan du uppdatera ACL:er.
Rätt att se ärendetyp
Låt oss säga att vi har en användargrupp som ska kunna se incidenter. Samma princip gäller oavsett vilket objekt (ex. change, problem) det är i ServiceNow.
(1) Vi skapar en grupp som heter “AG View Incident”. ‘AG’ står för Access Group. I.o.m. att detta inte är en grupp som ska vara synligt, exempelvis kunna tilldela incidenter till, gör det inget att namnet har prefix AG.
(2) För objekt som kommer OOB så finns det redan roller vi kan använda. Skulle vi sätta upp egna roller så måste vi gå in och göra ändringar på funktionalitet som kommer med plattformen och det ska vi inte göra. För att se incidenter krävs det att man har rollen ‘sn_incident_read’.
(3) Det krävs två ACL:er för att en användare ska kunna läsa, men inte skapa eller skriva, incidenter. Följande krävs (vi behöver inte skapa dessa med undantag om vi vill visa fält som är dolda enligt nedan):
incident Ger access till tabellen
incident.* Ger access till fälten i incident.
incident.<field> Styr rättigheterna för specifika fält. Exempelvis finns en regel för incident.work_notes som ger roll ‘sn_incident_write’ access att läsa Work Notes. I.o.m. att det bara finns en läsregel för det fältet och roll ‘sn_incident_read’ inte finns med så kommer användare som inte har roll ‘sn_incident_write’ se Work Notes. Vill du att användaren ska kunna se Work Notes kan du skapa en ACL där du ger ‘sn_incident_read’ rätt att se det fältet. Gör ‘Insert and stay’ på work_note-regeln och lägg till roll till ‘sn_incident_read’ (roll-listan kopieras inte när man gör ‘Insert and stay’).
Notera att det finns en Business Rule (‘incident query’) som säkerställer att man har rätt roll för att se incidenter. Detta är en av anledningarna till att vi inte vill skapa egna ACL:er och roller utan använda vad som finns. Skulle vi skapa egna ACL:er och roller så skulle vi behöva justera funktionen i denna affärsregel.
Skapar man egna objekt/tabeller behöver man skapa egna ACL:er och koppla dessa till roller.
(4) Vi behöver koppla roll ‘sn_incident_read’ till ‘AG View Incident’. Gå till gruppen och lägg till roll ‘view_incident’ i den relaterade listan längst ner.
(5) Ta en användare som inte redan har rättigheter att se incidenter och lägg till den personen i ‘AG View Incident’.
(6) Impersonate ovan användare. Skriv in ‘incident.list’ i vänstermenyns sökfält och tryck enter. En lista med incidenter ska visas. Om du klickar på ena öppnas incidenten med alla fält låsta.
Hemliga/Säkerhetsklassade fält
Låt säga att vi lägger ut ett fält för personnummer i incidentformuläret. Det ska inte kunna ses av alla utan endast av personer med rätt behörighet. Låt oss kalla fältet för “Social number” (u_social_number).
(1) Skapa och lägg ut fältet som första steg. Impersonate samma person som tidigare och kolla att du kan se fältet.
(2) Skapa en regel, incident.u_social_number, specifikt för detta fält. Vi tilldelar rollen security_admin till denna ACL. Så här ser regeln ut:
(3) Impersonate samma användare som tidigare. Lista incidenter och öppna en incident. Du ska nu inte kunna se fältet ‘Social Number’ men alla andra. Om Security Admin loggar in så kommer den personen se fältet.
Rätt att arbeta med ärende
Vi fortsätter att jobba med incidentformuläret. Nu behöver vi ha möjlighet att skapa grupper för de som faktiskt ska jobba med incidenter också. Det är folk i olika supportlinjer i organisationen.
(1) Skapa en grupp som heter ‘2nd Line’.
(2) Vi måste lägga ut ett fält i gruppformuläret som heter ‘Type’. Gör det (m.h.a. Form Design, fältet finns fördefinierat).
(3) Vi måste skapa en typ för vårt ändamål. Skriv in ‘sys_user_group_type.list’ i sökfältet ovanför vänstermenyn. Tryck enter.
(4) Skapa en ny typ som heter ‘incident_agent’.
(5) Gå tillbaka till grupp ‘2nd Line’ och välj den nya typen i fältet du lagt ut.
(6) Lägg in en medlem i gruppen som inte är samma som fick läsrättigheter ovan och som inte har rätt att jobba med incidenter.
(7) Öppna en incident. Högertryck på texten ‘Assignment group’ och välj Dictionary.
(8) Vi måste nu se till att grupp med typ ‘incident_agent’ går att välja. Det är det som står i fliken ‘Reference Specification’ som bestämmer vilka grupper man kan välja. Då fält ‘Assigned to’ är ärvt från task-tabellen så kommer alla ändringar vi gör här slå på alla andra formulär som också använder det fältet. Det måste vi undvika och för det ändamålet så ska vi göra ‘Override’ på reference qualifier. Med ServiceNow kommer ‘itil’ definierat som ‘Type’ för assigned to.
I den relaterade listan ‘Dictionary override’ finns en rad med tabell ‘incident’. Öppna den. Det finns ett fält som heter ‘Override reference qualifier’ och när du markerar den visas ett textfält som heter ‘Reference qualifier’. Här ska du skriva in referensen till den grupptyp du vill ska vara valbar. Skriv in följande men ändra sys_id till den grupptyp du definierat i systemet:
typeLIKE244696dbdb04241014c5808768961910
Du kan få fram sys_id genom att gå till typen du skapade ovan och välja att kopiera sys_id.
(9) Spara och gå tillbaka incidenten. Klicka på förstoringsglaset bredvid fältet ‘Assignment group’. Fönstret som visas ska se ut så här:
Skulle du göra samma sak på ett problem eller change så skulle du få en annan lista innan du gjort anpassningarna i denna artikel. Notera att på change måste du göra en override på “Attributes” och skriva in tree_picker=false också. Av någon anledning fungerar detta inte om den är satt till true (den sätts direkt i Dictionary till true i relaterade listan ‘Attributes’).
Nu kan man ju tro att det är klart men det är det ju inte. Om du gör impersonate på den användare du la till i gruppen så kommer den personen inte se några incidenter, vi måste fixa lite rättigheter.
(10) Vi kan återanvända samma struktur som för accessgruppen vars medlemmar skulle kunna läsa incidenter med skillnaden att vi nu måste tilldela rättigheter för att kunna skriva också. Gå till grupp “2nd Line”.
(11) En grupp kan ingå i en annan grupp. Så istället för att tilldela ‘2nd Line’ en roll så behåller vi strukturen med accessgrupper. M.a.o. skapar vi en grupp ‘AG Write Incident’ och kopplar roll ‘sn_incident_write’ till den. Vi kopplar ihop grupperna genom att välja grupp ‘AG Write Incident’ som ‘Parent’ till ‘2nd Line’. Nu räcker det med att vi lägger till användare i grupp ‘2nd Line’ för att de ska få rättigheter att jobba med incidenter. På det sättet förlitar vi oss på samma sätt att jobba med rättigheter (d.v.s. accessgrupper) men behöver endast administrera användare för den grupp som de som ska jobba med incidenter är med i.
Om det finns någon som ska kunna uppdatera incidenter utan att vara tilldelad lägger man den personen direkt i accessgruppen (exempelvis om en person är på semester kanske dennes chef ska kunna tilldela den personens ärenden till någon annan). Rollen ‘sn_incident_read’ ingår i gruppen ‘sn_incident_write’ så den får användaren på köpet.
Gör du impersonate på personen som är med i ‘2nd Line’ så kommer personen kunna se och arbeta med incidenter.
Det finns begränsningar med ovan sätt att arbeta. Du kan ju bara ha en ‘Parent’ till en grupp. Är det så att de som är med i ‘2nd Line’ ska kunna jobba med flera ärendetyper (change, problem, etc.) så funkar det inte. Då är det bättre att man helt separerar accessgrupper och grupper för tilldelning. Då måste man lägga varje användare som ska jobba med, exempelvis, incidenter i en accessgrupp (‘AG Write Incident’) samt i en grupp som används för tilldelning (‘2nd Line’). Ingen ‘Parent’ väljs då i någon grupp. Detta är troligtvis det sätt som kommer vara vanligast.
(13) Nu så, nu kan du välja vilka som ska kunna jobba med incidenten också.
Det finns fördefinierade roller för andra objekt OOB. Det är bara att använda dessa för relaterade objekt på samma sätt som är beskriver i denna artikel Listar de vanligaste här:
