Page History

...

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).

Følgende er et eksempel på hvilke Undertow og Wildfly handlers der er involveret i et simpelt SOAP kald indtil kontrollen ender i en Java Http Servlet:

...

I dette afsnit beskrives hver enkelt handler i flere detaljer.

Request

...

Handler

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.

Request Handleren delegerer herefter håndtering af requestet til et større antal handlers.

Audit Log Handler

Opretter en ny Nsp NSP Audit Log Entry og registrere 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 accessdata tilføjes NSP Access Log Entry også til den nyNSP Audit Log Entry og det hele logges som et JSON objekt via en konfigurerbar Log4J kategori.

Access Log Handler

Opretter en ny NSP Access Log Entry som lægges 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.

HTTP Request Length Handler

sørger for at berige NSP Access Log Entry med størelsen 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.

Request Content Handler

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 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.

XML Element Text Handler

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:

<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">TEST1-NSP-STS</saml:Issuer>

 Ved at angive følgende i konfigurationsfilen elementtexts.config vil strengen TEST1-NSP-STS blive logget med nøglen Issuer:

{urn:oasis:names:tc:SAML:2.0:assertion}Issuer -> Issuer

I skrivende stund konfigureres følgende for alle NSP komponenter:

# MedCom headeren
{http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd}FlowID -> FlowID
{http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd}MessageID -> MessageID

# Standard SAML
{urn:oasis:names:tc:SAML:2.0:assertion}Issuer -> Issuer
{urn:oasis:names:tc:SAML:2.0:assertion}NameID -> NameID

# WS Addressing - To versioner.
{http://schemas.xmlsoap.org/ws/2004/08/addressing}To -> To
{http://schemas.xmlsoap.org/ws/2004/08/addressing}Action -> Action
{http://www.w3.org/2005/08/addressing}To -> w3To
{http://www.w3.org/2005/08/addressing}Action -> w3Action
{http://www.w3.org/2005/08/addressing}MessageID -> w3MessageID

# IDWS Audience (Den service billetten kan bruges til) på et BST2IDWS omvekslet token.
{urn:oasis:names:tc:SAML:2.0:assertion}Audience -> Audience

SAML Assertion Attribute Handler

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

<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="medcom:CareProviderID" NameFormat="medcom:cvrnumber">
    <saml:AttributeValue>46837428</saml:AttributeValue>
</saml:Attribute>

Denne handler kan konfigureres til at tilføje udvalgte attributter (navn og værdi) til NSP Access Log Entry. Konfigurationen sker i filen attributevalues.config. 

I skrivende stund konfigureres følgende for alle NSP komponenter:

# 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

X509 Certificate Handler

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 Attatchment 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.

Security Protocol Detection Handler

Opretter en ny NSP SecurityContext som lægges 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.

X509 Certificate Subject Handler

IDWS kald til platformen indeholder både STS'ens certifikat og anvendersystemets Holder-of-key certifikat. Denne Handler finder Holder-of-key certifikatet, parser det og tilføjer X.509 Subject Distinguished Name derfra til NSP Access Log Entry.

XML Binary Security Token Handler

Ved omveksling af en 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:

#################
# 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

Certificate Revocation Handler

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 på de udstedte certifikater der er spærret.

Security Protocol Request Handler

På baggrund af den detekterede sikkerhedsprotokol i det indkommende request delegerer denne handler videre til enten OIO-IDWS Request Handler eller DGWS Request Handler

OIO-IDWS 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.

DGWS Request Handler

Denne handler anvender Seal.Java til at parse de indkommende SOAP Headers ud fra DGWS specifikationen. Handleren sørger for at validere at sikkerhedsbilletten (i Seal.Java kaldet et IDCard) er korrekt underskrevet af en NSP STS. Herefter udstiller handleren de forskellige attributter fra sikkerhedsbilletten gennem SecurityContext klasserne.

Response Handler

HTTP Response Length Handler

HTTP Response Header Handler

Security Protocol Response Handler

OIO-IDWS Response Signature Handler

DGWS Response Header Handler