[Bitrepository-devel] Rettighedsmodel skal IKKE være med i de globale CollectionSettings! (nok)

[Kåre Fiedler Christiansen]

Hej,

Lidt uddybning af hvad jeg synes er mest relevant, illustreret ved et par eksempler.


·         Hvem har ansvaret for at konfigurationen af systemet svarer til hvad der står i aftalen?

I modellen som den er nu, er det samlingsejer der beskriver konfigurationen i maskinlæsbar form. Naturligvis skal en ansvarlig ejer af benet sikre sig at konfigurationen svarer til det der står i aftalen, men jeg synes der er lagt en uforholdsmæssigt stor del af ansvaret over på samlingsejeren, ved at lade ham skrive konfigurationen der bliver læst af et ben.

Forestil jer, at en samlingsejer (eller rettere, dennes tekniske lakaj) kommer til at kopiere public key’en for den forkerte organisation ind som den der må erstatte filer på et ben. Dette får lov at gå i drift, og en hacker får adgang til at erstatte begge filer på den baggrund.

Fordi samlingsejer selv har stået for at skrive konfigurationen, er det uklart hvem der har ansvaret for den mistede fil. Hvis hver pillar-ejer havde sikret at det er de rette certifikater, der giver adgang, ville ansvaret være enklere (og mere organisatorisk uafhængigt) placeret.

·         Hver gang der tilføjes en komponent i systemet skal ALLE komponenter have opdateret konfigurationer.

Det er min forventning at vi på Statsbiblioteket vil have en voksende mængde af klienter med læseadgang til bitmagasinet. Det virker helt forkert, at fordi jeg tilføjer en læseklient skal jeg opdatere alle pillars og klienter i systemet – og ikke bare de relevante pillars og messagebussen.

·         Alt andet en permissions i CollectionSettings kan opfattes som en beskrivelse af ”topologien” og ”protokolkontrakten” for en collection. Disse må anses for at være ret stabile over tid. Det giver god mening at kopiere disse rundt mellem alle komponenter, og checke at de er identiske i alle komponenter med f.eks. en checksum.

Ting som oplysninger om hvilke ben der indgår, hvilke checksummer der er understøttet, hvilke komponenter leverer audit trails, opførsel af operationer hvor der er mulighed for fortolkning etc. Dette er i modstrid med permissions, som ændrer sig efterhånden som samlingen benyttes på nye måder.

·         For en driftafdeling er der klare fordele i at kunne køre standard-værktøjer på certifikater – man kan trække certifikat-headers ud, og man kan sammenligne med de certifikater man selv har genereret til systemet.

For eksempel vil det sikkert være Jens Henrik der genererer de certifikater der giver adgang til at foretage sig operationer på Statsbibliotekets samlinger. Han vil herefter også være den der skal tilføje certifikaterne til vores pillars konfiguration. Her vil han sikkert gerne checke at der er tale om de samme certifikater. At skulle trække certifikaterne ud af XML og base64decode dem er selvfølgelig muligt, men en ekstra arbejdsgang.

Generelt synes jeg det peger mod at konfiguration af ”topologien og kontrakten” for en collection, og permissions på en collection bør være uafhængige konfigurationer. Jeg ville selv foretrække at permissions kun indeholder permissions for den relevante komponent, og helst også som standard-certifikater.

Mikis har indkaldt mig som konsulent på næste bitmag videomøde, hvor jeg gerne uddyber.

Hilsen
  Kåre


From: bitrepository-devel-bounces at ml.sbforge.org [mailto:bitrepository-devel-bounces at ml.sbforge.org] On Behalf Of Christian S. Vandel
Sent: Thursday, September 20, 2012 1:56 PM
To: List for the Bitrepositorys developers
Subject: Re: [Bitrepository-devel] Rettighedsmodel skal IKKE være med i de globale CollectionSettings! (nok)

Hej Alle

 *   Hvis ColllectionSettings bliver distribueres i samlet form til alle komponenter, får alle komponenter indsigt i hvem der må hvad i en collection. Dette giver komponenterne væsentligt større indsigt i rettighedsmodelen end der er behov for.

Nu er rettighederne jo knyttet til certifikaterne, så alternativet er at *ingen* har styr på hvem som må hvad! Certifikaterne er i sig selv bare en klump bits og bytes, så det giver ikke nogen synderlig viden om noget andet end lige præcis at beskeder signeret med dette certifikats modpart er berettiget til operationen.

 *   CollectionSettings er temmelig svært at overkue for mennesker og temmelig lette at læse programmatisk, hvilket giver mulighed for at CollectionSetting leverandøren kan sende rettighedsmæssige ændringer i CollectionSetting rundt til komponenterne, som kan have meget svært ved at gennemskue, inden de opdatere deres lokale CollectionSettings med de tilsendt. Dette strider mod princippet om at pillar organisationerne selvstændigt kan tage ansvar for deres kopi. Vi kan allerede nu se at vi har svært ved at beskrive rettighederne konsistent i CollectionSettings.

Hvis man ikke som organisation er i stand til at gennemskue xml’en, og ønsker at håndhæve visse restriktioner, uden at det er indbygget i egen konfiguration eller kode, ja så er der et problem…

 *   Certificaterne i en collection settings vil være en af de mere dynamiske dele af Collection konfigurationen. Derfor er det ikke hensigtmæssigt at de ligger direkte i CollectionSettings, da dette vil give anledning til en konstant opdatering og dermed publisering af CollectionSettings.

Hvorfor skulle certifikaterne være en særlig dynamisk del af konfigurationen?

Sidste har vi punktet vi allerede har diskuteret på et statusmøde omkring konvertering pem fil -> CollectionSettings.xml -> pem file, som vi er tvunget til at gennemfører fordi vi vil have certificaterne distribueret vha. CollectionSettings. Hvis vi ikke gøre dette kan vi sparer denne konvertering frem og tilbage, og samtidig undgå at miste de ekstra oplysninger der ligger i den originale pem fil.

Hvad er det for nogen ekstra oplysninger?

/Christian



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.sbforge.org/pipermail/bitrepository-devel/attachments/20120924/fa1cce3f/attachment.html>