Document toolboxDocument toolbox

(no) Feltnivåsikkerhet (FLS)

Owned by Tom Wyczółkowski
Sept 11, 2017
3 min read

Introduksjon

Administrator kan styre tilgang til spesifikke metadatafelt i et objekt basert på bruker eller rolle.

Dette oppnås takket være feltsikkerhetsnivå, i det følgende kalt FLS. Hver objektklasse kan ha flere FLS-sett angitt. Hvert sett inneholder en liste over alle felt som er tilgjengelige i en gitt klasse og et sett med grunnleggende brukerrettigheter, f.eks. Synlig, Skrivebeskyttet, osv. Hvert FLS-sett kan ha tilordnede brukere eller grupper. Som et resultat brukes FLS på alle objekter i en gitt klasse i stedet for enkeltstående, spesifikke objekter. 


Eksempel: Når en bruker logger seg på systemet og ber om et objekt, kontrolleres første basissikkerhetsskjema. Hvis det gis tilgang til objektnivå, brukes FLS på objekters metadata. Hvis objektet inneholder la oss si 10 felt med metadata, kan det hende at en bruker kun ser 5 av dem. Det kan hende at en administrator vil avgjøre hvilke av disse 5 feltene en bruker kan oppdatere. 


FLS-systemet kan også brukes "ved behov" for å påvirke metadatasett som vises av spesifikke Tesseleter, for eksempel kun vise valgte metadatafelt i forhåndsvisningen for objektegenskaper.

FLS-krav

FLS-definisjon

  1. Et hvilket som helst antall FLS-er (et sett med rettigheter for alle klassefelt) kan angis for hver klasse.

  2. FLS angir alle felt for klassen, og utvider dem med spesialegenskaper:

    1. Skrivebeskyttet (når dette er avmerket, blir feltet skrivebeskyttet)

    2. Skjult (data overføres til klienten, men tilsvarende skjema vil inneholde denne egenskaper som indikasjon på forskjellige behandling på Vis for klient)

    3. Ikke tilgjengelig (dette feltet er ikke tilgjengelig for brukeren – det overføres ikke, kan ikke vises eller oppdateres)

  3. Hver FLS kan ha tilordnede brukere, grupper eller roller.

  4. Det finnes minst én standard-FLS for klasse (standard-FLS kan ikke slettes)

FLS- og skjemabehandling

  1. FLS er spesifikk for objektklasse og bruker – ikke et enkeltstående objekt

  2. Dataforespørsel består vanligvis av to trinn:

    1. hente klasseskjema som er nødvendig for å opprette, vise og lagre modeller

    2. hente rådata

  3. Skjema må behandles gjennom FLS, ettersom det skal inneholde informasjon om egenskaper som f.eks. "skrivebeskyttet", eller ikke skal ha felt som ikke er tilgjengelige for valgte bruker.

    1. Basisskjema hentes fra HDDB eller fra hurtigbuffer

    2. Systemet kontrollerer om det finnes en gjeldende FLS (eller flere FLS) for gjeldende bruker, hvis ikke brukes standard-FLS.

    3. Hvis det finnes flere FLS, kombineres de, og det mest restriktive settet med egenskaper brukes. 

    4. Skjema modifiseres i henhold til FLS (feltegenskaper endres, felt fjernes)

  4. Objektdata under GET-forespørsel filtreres gjennom FLS/behandlet skjema i HRIS-sone (felt fjernes – andre egenskaper lagres i skjema)

  5. Objektdata under oppdatering filtreres også gjennom FLS/behandlet skjema i HRIS-sone for å oppnå symmetrisk sikkerhet (bruker kan ikke oppdatere utilgjengelige eller skrivebeskyttede felt). 

  6. Under oppdatering filtreres innhold i transportobjekt med oppdateringspakke, før forespørsel sendes til HDAS.

FLS-rettigheter

Rettighet

Beskrivelse

Rettighet

Beskrivelse

Ikke tilgjengelig

Dette feltet er fjernet fra objektklasseskjemaet og fra dataene.

Det er ikke mulig for brukeren å vise eller redigere dette feltet.

Skrivebeskyttet

Dette feltet er skrivebeskyttet. Det er nedtonet på brukergrensesnittet.

Ingen endringer godkjennes for dette feltet.

Skjult

Dette feltet gjengis som skjult, men dataene i det er likevel tilgjengelige ved behov

for skrivetilgangsoperasjoner.

 

FLS og mulige konflikter med andre innstillinger

Systemet håndhever ikke strenge regler, og det er opp til en administrator å angi profiler som faktisk gir mening.

HyperDoc krever for eksempel at hver objektklasse har minst ID- og etikettfelt. Hvis en administrator vil stille inn felt som brukes som etikett som Ikke tilgjengelig,

vil dette bli ignorert, ettersom dette feltet er obligatorisk på systemnivå.

 

En annen mulig situasjon i konflikt finner sted for obligatoriske felt. Obligatorisk kan stilles inn i objektklassedefinisjon. Obligatorisk felt kan skjules for spesifikk bruker som fremdeles har rettighet til å legge til nye objekter.

Denne brukeren vil i så fall kun måtte fylle ut felt som er obligatoriske og synlige for brukeren. Hvis en annen bruker med mindre restriktive rettigheter ønsker å redigere dette objektet, må denne bruken fylle ut manglende og obligatoriske felt før han får lov til å lagre dette objektet.

Ideelt sett skal objekter opprettes av brukere som har tilstrekkelige rettigheter til å fylle ut alle obligatoriske felt.