Page History

...

Wildfly Application Server bygger på Undertow Servlet Container, hvilket gør det muligt gennem dennes Servlet Extension mekanisme at udvide containeren med kode, der håndtere håndterer NSP specifikke detaljer.

Undertow består af et større antal HttpHandlers der hver har sin egen afgrænsede del af ansvaret for at få udført et Http Servlet Request og produceret et Http Servlet Response. Handlers i Undertow opbygges i en kalds-kæde så hver handler både kan håndtere Request og Response (I Undertow samles dette i en Exchange).

...

Stakken læses nedefra og op i forhold til håndtering af Request og derefter oppefra og ned ifm håndtering af Response. Stakken viser også, hvor NSP Access Handler er placeret i denne.

NSP Access Handler (AH) implementerer Undertows HttpHandler interface og tilføjes i stakken via den omtalte Servlet Extension mekanisme, således at den køres, efter Servlet Containeren har håndteret eventuelle sikkerhedsaspekter, men inden andre Servlet relaterede handlers køres. Placeringen sikrer også, at Undertow har allokeret en dedikeret Task Thread til at håndtere kaldet frem for en asynkron XNIO Thread, der bruges længere nede i stakken.

...

NSP Access Handler opbygger en ensartet Json Access Log for hvert eneste kald til platformen, med mindre der er tale om et Http Get kald uden nogen Http Body (f.eks. ved kald af status sider eller hentning af wsdl & xsd filer). Access Loggen indeholder detaljer fra Http Headers samt Soap Headers, men det er muligt at konfigurere et stort antal andre Xml elementer til at komme med i loggen, hvis/når det er relevant. ASHA: Kan vi give et godt eksempel herpå?

Audit Log

NSP Access Handler implementerer NSP Audit Log interfacet og samler informationer fra den kaldte NSP komponent samt Access Loggen sammen. Disse informationer bruges til at bygge en ensartet Json Audit Log for hvert kald til komponenten.

...

NSP Access Handler verificerer, at certifikater i et kald til en NSP komponent er udstedt under et kendt OCES intermediate/rod-certifikat samt ikke optræder på dennes spærelistespærreliste.

Message Transmission Optimization Mechanism (MTOM)

Flere NSP komponenter understøtter, at anvendere gør brug af MTOM bindingen i SOAP. På grund af AH's placering i Undertows stak af Handlere skal AH selv kunne parse disse Multipart beskeder.

...

NSP Access Handler implementerer NSP Security API interfacet og stiller informationer fundet i den en indkommende DGWS billet til rådighed for NSP komponenten. AH validerer at billeten billetten er korrekt signeret af en STS.

...

NSP Access Handler implementerer NSP Security API interfacet og stiller informationer fundet i den en indkommende OIO-IDWS billet til rådighed for NSP komponenten. AH validerer at billeten billetten er korrekt signeret af en STS og at hele requestet er signeret af det rigtige anvendersystem.

Den Gode Webservice response enhancement

Den Gode Webservice standarden diktere 2 forksellige standard dikterer to forskellige Soap Headers, der skal være i svar fra en DGWS service. AH sørger for at tilføje disse, hvis det indkommende request indeholder indeholdte en DGWS billet.

OIO Identitetsbaserede Webservices response signering

OIO-IDWS standarden diktere dikterer, at hele svaret fra et kald til en OIO-IDWS service skal signeres med et Service Provider certifikat. AH sikrer dette, hvis det indkommende request indeholdte en OIO-IDWS billet.

...

Denne handler sørger for at læse requestet ind i en ReadWriteBuffer. Denne buffer kan skrives til en enkelt gang, hvorefter indholdet kan læses flere gange som en stream af bytes. Dette gør det muligt f.eks. at anvende Java XML, Seal.Java og andre kodebiblioteker, der understøtter java.io.InputStream.

Når requestet er læst ind, pakkes Undertow's HttpServletRequest objektet ind i en NSP udgave, således at alle læsninger sker via denne buffer.

...

Opretter en ny NSP Audit Log Entry og registrere registrerer denne i den aktive tråds Nsp Audit Provider, således at kald fra komponenten til Audit API'ets metoder tilføjer auditdata heri. Når komponenten har udført sin operation tilføjes NSP Access Log Entry også til den ny NSP Audit Log Entry og det hele logges som et JSON objekt via en konfigurerbar Log4J kategori. ASHA: Skal vi meget kort nævne Log4J kategorierne?

Access Log Handler

Opretter en ny NSP Access Log Entry, som lægges på på Undertow's Exchange objekt ,således at de andre handlers kan tilføje information dertil. Når alle handlers er færdig logges informationerne som et JSON objekt via en konfigurerbar Log4J kategori.

...

sørger for at berige NSP Access Log Entry med størelsen størrelsen på requestet.

HTTP Request Header Handler

Tilføjer et antal faste HTTP headers til NSP Access Log Entry og kan konfigureres med et antal yderligere HTTP Headers. De faste er Host, Protocol, Port, Method, Path og Query. Handleren læser filen httpheaders.config og logger de HTTP Headers, der er konfigureret deri. Det kunne f.eks. være Content-Type, SOAPAction og X-Forwarded-For.

...

Parser requestet ved hjælp af en XMLStreamReader fra Java XML biblioteket. For hvert event i XML dokumentet (start tag, text, attributte, end tag mv.) kaldes de underliggende handlers. Handleren vedligeholder en form for for Breadcrumb context som de underliggende handlers kan bruge til at finde ud af, hvor i dokumentet parsningen er kommet til, hvilket sikrer en hurtig afvikling af alle de underliggende handlers.

...

Med denne handler er det muligt at angive, at tekst-indholdet af et bestemt XML element skal tilføjes til NSP Access Log Entry. Dette gør det muligt at logge relevante dele af requestet blot ved at kende Namespace og navnet på et element. Eksempelvis angives udstederen af et DGWS token i XML dokumentet på denne måde:

...

Et SAML token (DGWS, IDWS, OIOSAML mv.) indeholder et antal antal SAML Assertion Attribute elementer på følgende form:

...

I skrivende stund konfigureres følgende for alle NSP komponenter: ASHA: Det ville være godt, hvis der efter den følgende kodeblok blev angivet, hvad der ville bliver tilføjet til Access Log entry for eksemplet lige ovenfor.

# Standard attributter på et DGWS idkort.
medcom:CareProviderID
medcom:CareProviderName
medcom:ITSystemName
medcom:UserAuthorizationCode
medcom:UserOccupation
medcom:UserRole
sosi:AuthenticationLevel
sosi:IDCardID
sosi:IDCardType
sosi:IDCardVersion

# IDWS attributter på et BST2IDWS omvekslet token.
dk:gov:saml:attribute:SpecVer
dk:gov:saml:attribute:CprNumberIdentifier
dk:gov:saml:attribute:AssuranceLevel

...

Denne handler parser de X.509 certifikater der findes i requestet og stiller dem til rådighed for andre handlers i træet. Det er kun de certifikater der findes på SAML Assertions, som vist nedenfor, der bliver samlet op. Certifikaterne skal bruges ifm. CRL tjekket.

<?xml version="1.0" encoding="UTF-8"?>
<ns2:Envelope 
    xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:ns4="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:ns5="http://www.w3.org/2000/09/xmldsig#"
    xmlns:ns6="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
    <ns2:Header>
        <ns6:Security>
            <ns4:Assertion IssueInstant="2016-04-19T10:44:41Z" Version="2.0" id="IDCard">
                <ns5:Signature id="OCESSignature">
                    <ns5:KeyInfo>
                        <ns5:X509Data>
                            <ns5:X509Certificate>MIIGJDCCBQygAwIBAgIEUw8UsTAN...QqP4wxK/TprIanlOxQWHIA==</ns5:X509Certificate>
                        </ns5:X509Data>
                    </ns5:KeyInfo>
                </ns5:Signature>
            </ns4:Assertion>
        </ns6:Security>
    </ns2:Header>
</ns2:Envelope>

Hvis der er tale om et MTOM request, kan det være, at certifikatet ikke ligger direkte i XML dokumentet, men at der derimod ligger et XOP Include element med en reference til den MTOM AttatchmentAttachment, der indeholder det binære certifikat. I dette tilfælde læser Handleren denne reference og stiller den til rådighed for andre handlers i træet. Selve certifikatet vil blive læst af MTOM parseren, så det også er tilgængelig. ASHA: MTOT parseren kan jeg ikke finde på overbliksfiguren. Hvor ligger den "gemt" under?

Security Protocol Detection Handler

Opretter en ny NSP SecurityContext, som lægges på på Undertow's Exchange objekt, således at de andre handlers kan tilføje information dertil. Derudover registreres NSP SecurityContext både som en attribut på HttpServletRequest objektet samt i den aktive tråds NspSecurityProvider. Dette giver komponenten mulighed for at få fat i konteksten enten via Security API'et eller direkte fra Servlet Request objektet.

Herefter søger Handleren efter en SAML Attribute i requestet med navnet "sosi:IDCardVersion" eller "dk:gov:saml:attribute:SpecVer" og bruger værdien til at afgøre, om det er et DGWS eller IDWS request. Denne information lægges på NSP SecurityContext objektet.

...

XML Binary Security Token Handler

Ved omveksling af en et JSON Web Token til en IDWS billet, kan denne handler konfigureres til at tilføje udvalgte JWT Headers og JWT Claims til NSP Access Log Entry. Konfigurationen læses fra filen jsonwebtoken.config.

I skrivende stund konfigureres følgende: ASHA: Her er det mindre klart, hvad der tilføjes til Access Log entry. Kunne der ikke indføres et eksempel ligesom ovenfor?

#################
# JSON Web Tokens
#################

# Key ID - The alias of the certificate in the truststore
kid -> keyid

# Issuer of the token
iss -> issuer

# What the token can be used for
scope

# The cpr number of the person
cpr

...

Her tjekkes om de certifikater, som andre handlers har fundet i det indkommende request, findes på den tilsvarende spærreliste (CRL). Spærrelisterne læses op fra Certificate Revocation Authority databasen (CRA) og caches i memory. Det er muligt at konfigurere, hvor ofte spærrelisterne genindlæses fra databasen, default gøres dette hvert 10. minut.

OCES strukturen er opbygget med ét rod-certifikat der udsteder Intermediate CA certifikater, hvorunder både medarbejder, virksomheds og funktionscertifikater udstedes. Hver CA certifikat har en spærreliste som indeholder løbenummeret løbenumrene på de udstedte certifikater, der er spærret.

Security Protocol Request Handler

...

Denne handler anvender Seal.Java til at parse de indkommende SOAP Headers ud fra OIO-IDWS specifikationen. Handleren sørger for at validere at sikkerhedsbilletten (i Seal.Java kaldet en CitizenIdentityToken) er korrekt underskrevet af en NSP STS, samt at hele requestet er signeret med det Holder-of-Key certifikat, der er på sikkerhedsbilletten. Herefter udstiller handleren de forskellige attributter fra sikkerhedsbilletten gennem SecurityContext klasserne.

...

Denne handler sørger for at pakke Undertow's HttpServletResponse objektet ind i en NSP udgave, således at alle skrivninger fra servicen sker til en ReadWriteBuffer. Dette betyder, at de andre handlers, der delegeres til, kan få adgang til det fulde response, inden det sendes retur til anvenderen af servicen.

...

OIO-IDWS Response Signature Handler

OIO-IDWS standarden diktere dikterer, at alle svar skal være signerede. Da servicen ikke ved, om den er blevet kaldt med en OIO-IDWS billet (den forholder sig til abstraktionen leveret af Security API), så anvender denne handler Seal.Java til at erstatte XML svaret med ét, der er signeret med et konfigurerbart certifikat.

DGWS Response Header Handler

DGWS standarden diktere dikterer, at der skal forefindes to særlige SOAP Headers på svaret. Da servicen ikke ved, om den er blevet kaldt med en DGWS billet (den forholder sig til abstraktionen leveret af Security API), så sørger denne handler for at erstatte XML svaret med ét, der indeholder disse SOAP Headers.

...