Document toolboxDocument toolbox

(sv) Fältnivåsäkerhet (FLS)

Owned by Tom Wyczółkowski
Last updated: Sept 12, 2024 by Maciej Zabielski
3 min read

Inledning

Administratörer kan kontrollera tillgången till specifika metadatafält inuti ett objekt, utifrån användare eller roller.

Detta styrs med fältnivåsäkerhet, nedan kallat FLS (förkortning av Field Level Security). Varje objektklass kan ha flera definierade FLS-uppsättningar. Varje uppsättning innehåller en lista över alla fält som är tillgängliga i en given klass och de grundläggande användarbehörigheterna, som Synlig, Skrivskyddad, etc. Alla FLS-uppsättningar kan tilldelas användare eller grupper. FLS appliceras därför på alla objekt i en given klass och inte på enstaka, specifika objekt. 


Exempel: När en användare loggar in i ett system och begär ett objekt kontrolleras först det grundläggande säkerhetsschemat. Om behörighet till objektnivån beviljas appliceras FLS på objektets metadata. Om objekt t.ex. innehåller 10 metadatafält kanske användaren bara har behörighet att se 5 av dessa. Administratören kan bestämma vilka av dessa 5 fält som användaren kan uppdatera. 


FLS-system kan också användas "på begäran" för att påverka de metadataurval som visas av specifika Tesselets. Exempelvis kan urvalet av de metadatafält som visas i förhandsgranskningen av objektegenskaper begränsas.



FLS-krav

FLS-definition

  1. Det finns inga begränsningar för FLS (en uppsättning rättigheter för alla klassfält) i de olika klasserna.

  2. FLS anger alla fält för klasserna och utökar dem med särskilda egenskaper:

    1. Skrivskyddad (när detta markeras blir fältet skrivskyddat)

    2. Dold (data överförs till klienten, men motsvarande schema innehåller denna egenskap för att visa att processen är en annan i klientvyn)

    3. Inte tillgänglig (detta fält är inte tillgängligt för användaren – det överförs inte, kan inte visas eller uppdateras)

  3. Alla FLS kan tilldelas användare, grupper eller roller.

  4. Alla klasser har minst en FLS (standard-FLS kan inte raderas)

FLS- och schemabearbetning

  1. FLS är specifika för objektklasser och användare, inte enstaka objekt

  2. Databegäran består vanligtvis av två steg:

    1. Hämtning av det klasschema som behövs för att skapa display- och lagringsmodeller

    2. Hämtning av rådata

  3. Scheman måste bearbetas via FLS eftersom de ska innehålla information om egenskaper som Skrivskyddad eller innehåller fält som inte är tillgängliga för den valda användaren

    1. Basschemat hämtas från HDDN eller från cachen.

    2. Systemet kontrollerar om det finns någon eller några FLS som gäller för den aktuella användaren. Om inte används standard-FLS.

    3. Om flera FLS hittas kombineras de och det mest restriktiva egenskapsurvalet används. 

    4. Schemat modifieras i enlighet med FLS (fältegenskaper ändras, fält tas bort)

  4. Objektdata för GET-begäran filtreras genom FLS/bearbetat schema i HRIS-zonen (fält tas bort, andra egenskaper lagras i schemat)

  5. Objektdata vid uppdatering filtreras också genom FLS/bearbetat schema i HRIS-zonen för att erhålla symmetrisk säkerhet (användaren kan inte uppdatera fält som är otillgängliga eller skrivskyddade). 

  6. Vid uppdatering filtreras innehållet i Transportobjektet med uppdateringspaketet innan begäran skickas till HDAS.

FLS-behörighet

Behörighet

Beskrivning

Behörighet

Beskrivning

Ej tillgänglig

Detta fält tas bort från objektklasschemat och från data.

Användaren kan inte se eller redigera detta fält.

Skrivskyddad

Detta fält är skrivskyddat Det är inaktiverat i användargränssnittet

Inga ändringar accepteras för detta fält.

Dold

Detta fält återges som dolt, men data är fortfarande åtkomliga vid behov

för läs-/skrivåtgärder.

 

FLS och möjliga konflikter med andra inställningar

Systemet tillämpar inte strikta regler och det är upp till administratören att skapa logiska profiler.

FMA kräver t.ex. att varje objektklass har minst ett ID- och ett etikettfält. Om en administratör anger att ett fält som används som etikett inte är tillgängligt

kommer detta att ignoreras eftersom detta fält behövs på systemnivå.

 

Konflikter kan även inträffa för obligatoriska fält. Önskat alternativ kan anges i objektklassdefinition. Obligatoriska fält kan döljas för specifika användare som ändå har rätt att lägga till nya objekt.

Dessa användare behöver i så fall bara fylla i fält som är obligatoriska och synliga för dem. Om en annan användare med mindre restriktiv behörighet vill redigera detta objekt måste användare fylla i obligatoriska/tomma fält innan objektet kan sparas.

Det bästa är om objekt skapas av användare med tillräcklig behörighet för att fylla i alla erforderliga fält.