Page History

...

• Hvilke brugertyper er til stede i min komponent?
• Hvordan skal disse brugertyper tjekkes/mappes i forhold til de forretningsregler, der gæder i min komponent=?
• Eksempler på aktører. Denne liste er ikke udtømmende, og det er vigtigt at overveje, hvad der skal gælde i de enkelte komponenter.:

Teknisk opsætning og anvendelse af NSP Security API

I forgående afsnit blev det fremhævet, at det ikke er en NSP komponents ansvar selv at inkludere NSP Security API i dens færdigbyggede modul.

I stedet udtrykker komponenten, at den regner med, at de omgivelser, hvori den efterfølgende afvikles, stiller NSP Security API til rådighed på afviklingstidspunktet.

Afviklingsomgivelserne for en standard NSP komponent er Wildfly (evt via et af NSP'ens Docker images). På Wildfly findes en række tredjeparts biblioteker, der leveres med platformen - herunder også NSP Security API.

Som default er de fleste af disse bibliotekter afskærmet og således ikke til rådighed for komponenten på afviklingstidspunktet - men via en særlig konfigurationsfil (som Wildfly forstår) kan det udtrykkes, at komponenten ønsker, at få adgang til et eller flere af disse biblioteker.

For at Wildfly kan stiller NSP Security API til rådighed for en komponent skal filen /src/main/webapp/WEB-INF/jboss-deployment-structure.xml findes i Maven projektet og i det byggede modul og have følgende indhold:

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
    <deployment>
        <!-- NSP komponenter styrer selv logning -->
        <exclude-subsystems>
            <subsystem name="logging"/>
        </exclude-subsystems>

        <!-- Denne komponent anvender NSP Security API -->
        <dependencies>
            <module name="dk.sds.nsp.security"/>
        </dependencies>
    </deployment>
</jboss-deployment-structure>

Det er vigtigt af forstå, at der ikke nødvendigvis er sammenhæng mellem det versionsnummer af NSP Security API, som bliver udtrykt i Maven afhængigheden, og den version af NSP Security API, der bliver stillet til rådighed af Wildfly.

Det er komponentens eget ansvar at sørge for, at der er sammenhæng mellem disse. Eventuelle versionsforskelle mellem det, som en komponent tror, at den får stillet til rådighed, og det, som den rent faktisk får stillet til rådighed, kan give en masse udfordringer og underlige fejl (NoSuchMethodException, ClassNotFoundException med flere), når komponenten afvikles og anvender NSP Security API.

I praksis kan man tjekke versionen af NSP Security API, der bliver stillet til rådighed af Wildfly, på følgende måde:

root@7e07691acb13:~# cd /tmp
root@7e07691acb13:/tmp# jar xf /pack/wildfly/modules/system/layers/base/dk/sds/nsp/security/main/nsp-security-api.jar
root@7e07691acb13:/tmp# cat META-INF/MANIFEST.MF 
Manifest-Version: 1.0
Implementation-Title: NSP Security API
Implementation-Version: 
Archiver-Version: Plexus Archiver
Built-By: root
Created-By: Apache Maven 3.5.4
Build-Jdk: 1.8.0_275
Specification-Version: 1.0.6

I ovenstående eksempel er det NSP Security API version 1.0.6, der stilles til rådighed af den konkrete version af Wildfly, hvilket hænger fint sammen med det versionsnummer, der blev udtrykt i Maven afhængigheden (i pom.xml).

TODO: Dokumentationskrav: 1) Brugerhistorier med komplet liste af brugertyper og beskrivelse af dem, så de giver mening for anvenderne 2) De enkelte brugertyper og de regler, der omgiver dem (hvad tjekkes i security api) skal beksrives i design og arkitekturguide

Eksemplerne nedenfor skal beriges med, hvad der IKKE må være tilstede (f.eks. for borger må der ikke være en organisation). Kig på de enkelte attributter i security api f.eks. som en tabel eller ligenden, så man kan se strukturen og de regler der gælder på de forskellige niveauer.

Komponenten skal modellere disse aktører på en eller anden måde (f.eks nedarvning eller en simpel enumeration, der lister typerne).