Wildfly og Undertow

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

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:

javax.servlet.http.HttpServlet
io.undertow.servlet.handlers.ServletHandler
io.undertow.servlet.handlers.FilterHandler
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler
io.undertow.servlet.handlers.ServletDispatchingHandler
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler
io.undertow.server.handlers.PredicateHandler
dk.sds.nsp.accesshandler.NspServletHandler
io.undertow.server.handlers.PathHandler
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler
io.undertow.server.handlers.PredicateHandler
io.undertow.security.handlers.AbstractConfidentialityHandler
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler
io.undertow.security.handlers.AuthenticationMechanismsHandler
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler
io.undertow.security.handlers.SecurityInitialHandler
io.undertow.server.handlers.PredicateHandler
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler
io.undertow.server.handlers.PredicateHandler
io.undertow.servlet.handlers.ServletInitialHandler

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.

Placeringen af AH i stakken kan summeres på et lidt højere abstraktionsplan i følgende digram:
Stakken

NSP Access Handler

Opgaver

NSP Access Handler (AH) løser følgende opgaver på NSP platformen:

Access Log

NSP Access Handler opbygger en ensartet Json Access Log for hvert eneste kald til platformen (Med mindre man slår det fra for f.eks. kald af status sider eller hentning af wsdl & xsd filer). Access Loggen indeholder detaljer fra Http Headers, Soap Headers, JWT Authentication Header og JSON Request Body., Det er også muligt at konfigurere et stort antal andre Xml elementer til at komme med i loggen, hvis/når det er relevant.

Eksempler på indeholdet af en Access Log Entry kan være

  • HTTP Header. F.eks. den URL som servicen er kaldt på eller den SOAP Action der angiver hvilken operation der skal udføres.
  • SAML attributter. F.eks CVR nummeret på en organisation eller autorisationskoden for en medarbejder
  • XML elementer med tekstindhold. F.eks. Hvilken STS der har udsted en billet eller hvilket Audience en borgerbillet har og derved hvad den må bruges til.
  • JSON attributter fra et REST kald
  • Claims fra en JTP-H sikkerhedsbillet

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.

Certificate Revocation Check

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

Den Gode Webservice (DGWS) billet validering

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

OIO Identitetsbaserede Webservices (OIO-IDWS) billet validering

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

JWT Token Profile for Healthcare (JTP-H) billet validering

NSP Access Hanlder implementerer NSP Security API interfacet og stiller informationer fundet i en indkommende JWT billet til rådighed for NSP komponenten hvis denne overholder JTP-H specifikationen. AH validerer at billetten er signeret af en af de konfigurerede Identity Providers (F.eks. den kommende SDS Open ID Connect server)

Den Gode Webservice response enhancement

Den Gode Webservice 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 indeholdte en DGWS billet.

OIO Identitetsbaserede Webservices response signering

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

Struktur

Nedenstående graf viser hvorledes AH er opdelt i et antal handlers der hver bidrager til en eller flere af de omtalte opgaver
Handler hierarchy


Handlers

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.

Handleren opretter herefter 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 forsøger handleren at afgøre om det indkommende request er et SOAP kald med XML eller et REST kald med JSON. Denne information gemmes også på Undertow's Exchange objekt og anvendes til at udvælge hvilke af de efterfølgende NSP handlers, der delegeres til.

Audit Log Handler

Opretter en ny NSP Audit Log Entry og 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 Log4J.

Eksempel på en Audit Log Entry
{
    "time": "2024-06-13T12:36:36.974Z",
    "category": "dk.sds.nsp.audit.log",
    "audit": {
        "timestamp": "2024-06-13T14:36:36.76+02:00",
        "components": [
            {
                "component": "SDM",
                "contexts": [
                    {
                        "context": "SKRS Replicate",
                        "information": [
                            {
                                "key": "register",
                                "type": "SPI",
                                "value": "sikrede"
                            },
                            {
                                "key": "datatype",
                                "type": "SPI",
                                "value": "sikrede"
                            },
                            {
                                "key": "version",
                                "type": "SPI",
                                "value": 1
                            },
                            {
                                "key": "registerVersion",
                                "type": "SPI",
                                "value": 1
                            },
                            {
                                "key": "max records",
                                "type": "SPI",
                                "value": 1000
                            },
                            {
                                "key": "offset",
                                "type": "SPI",
                                "value": "14960482270000021005"
                            },
                            {
                                "key": "returned elements",
                                "type": "SPI",
                                "value": 1000
                            },
                            {
                                "key": "returned first element",
                                "type": "SPI",
                                "value": "14960482270000021006"
                            },
                            {
                                "key": "returned last element",
                                "type": "SPI",
                                "value": "14960482270000022005"
                            }
                        ]
                    }
                ]
            }
        ]
    }
}


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.

Eksempel på en Access Log Entry
{
    "code": 200,
    "duration": 66,
    "httpHeaders": {
        "Content-Type": "text/xml",
        "SSLSessionID": "",
        "X-Forwarded-For": "185.43.140.254, 185.43.140.254",
        "X-NSI-LB-UID": "171828185924606mBmis0yKPZEG+VxLDoW9mw=="
    },
    "httpHost": "test2.ekstern-test.nspop.dk",
    "idCardAttributes": {
        "medcom:CareProviderID": "78834412",
        "medcom:CareProviderName": "Systematic A/S",
        "medcom:ITSystemName": "Cura",
        "sosi:AuthenticationLevel": "3",
        "sosi:IDCardID": "M9/+UQ5CkOS3f8IiKr1Iig==",
        "sosi:IDCardType": "system",
        "sosi:IDCardVersion": "1.0.1"
    },
    "method": "POST",
    "path": "/stamdata-batch-copy-ws/service/StamdataReplication",
    "query": "",
    "port": 8443,
    "protocol": "http",
    "reqSize": 6855,
    "resSize": 112965,
    "soapHeaders": {
        "Issuer": "TEST2-NSP-STS",
        "MessageID": "AAABkBGUdep1GweYcY9OAVNPU0k=",
        "NameID": "SubjectDN={C=DK, OID.2.5.4.97=NTRDK-78834412, O=Systematic Care Test, SERIALNUMBER=UI:DK-O:G:2ad05894-dc65-4a9b-a47d-f11545c0d7c7, CN=Columnacuratest (funktionscertifikat)},IssuerDN={C=DK, O=Den Danske Stat, OU=Test - cti, CN=Den Danske Stat OCES udstedende-CA 1},CertSerial={514258879967773476201292624786303860058590338398}"
    },
    "threadId": "default task-55",
    "time": "2024-06-13T14:31:00.626+02:00",
    "stats": {
        "handlerDuration": 4,
        "RequestContentDuration": 0,
        "ResponseContentDuration": 0,
        "SecurityProtocolRequestDuration": 1,
        "SecurityProtocolResponseDuration": 0,
        "bufferAllocated": false,
        "usedBuffers": 1,
        "activeBuffersInPool": 1,
        "idleBuffersInPool": 380
    }
}

HTTP Request Length Handler

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

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.

Hvis requestet anvender Message Transmission Optimization Mechanism (MTOM) delegeres kaldet først til en MTOM Parser der bygger på Apache James Mime4J kodebiblioteket (en del af Wildfly platformen). Parseren sørger for at samle de forskellige attachments til et samlet XML dokument som handleren kan håndtere.

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

For eksemplet på et SAML Assertion Attribute element ovenfor, vil denne konfiguration tilføje en attribut til Access Log Entry'et med navnet "medcom:CareProviderID" og værdien "46837428".

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 Attachment, 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 bliver læst af MTOM parseren, så det også er tilgængelig.

Security Protocol Detection Handler

Denne handler søger 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 et JSON Web Token (JWT), indlejret i et SOAP SAML token, til en IDWS billet, kan denne handler konfigureres til at tilføje udvalgte attributter fra JWT Headers og JWT Claims til NSP Access Log Entry. Konfigurationen læses fra filen jsonwebtoken.config.

En JWT er sammensat af 3 Base64 encodede dele adskilt af et punktum (Headers, Claims og Signature) som vist i dette eksempel:

eyJraWQiOiJzc2lfZm9jZXNfMjAyMSIsImFsZyI6IlJTMjU2In0.eyJpc3MiOiJodHRwOi8vc3RzLXRlc3RlciIsImNlcnRzdWJkbiI6IlNFUklBTE5VTUJFUj1QSUQ6OTIwOC0yMDAy
LTItNTE0MzU4OTEwNTAzICsgQ049TGFycyBMYXJzZW4sIE89SW5nZW4gb3JnYW5pc2F0b3Jpc2sgdGlsa255dG5pbmcsIEM9REsiLCJzY29wZSI6ImNsZWFyIHNvc2ktc3RzIiwiY3By
IjoiMDUwMTc5MjI3NSIsImV4cCI6MTU0Njg4MDAwOH0.FldqvlosDWIeiqVZCa4hoGAuVftJuBxDxQaAaVWSkbN1lfJK13671VkfTTdOrx40PnVAPuxRddNE3feCk1yiVWBbW-R96rOq
0nIE0kOvnSgXUUN70qWCysCLibRsSpLe-3Yhv0GLIKFtMsp_Rhi-9jRL_2GFmantdj_x4lXOvXGFTYwJznr2mC-jsthrBgXyyK4uDjwVoGXPtLQVPUcc8RF1fo_Bbo_BVhiUCEDsmtU8
HM5vfQRyqZvxZKTyKVegNmPlVaKhteH77XWG39prnFArEM7LnlKdFVokmrWnJOKpbqwgFLSligI2P4l27PvvXLhhui2OTo4i0x08Mq_DMw

De to første dele er blot JSON objekter og eksempelt ovenfor indeholder derfor disse JWT Headers og JWT Claims:

{
    "kid": "ssi_foces_2021",
    "alg": "RS256"
}
{
    "iss": "http://sts-tester",
    "certsubdn": "SERIALNUMBER=PID:9208-2002-2-514358910503 + CN=Lars Larsen, O=Ingen organisatorisk tilknytning, C=DK",
    "scope": "clear sosi-sts",
    "cpr": "0501792275",
    "exp": 1546880008
}

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

Med denne konfiguration vil følgende blive tilføjet til Access Log Entry'et baseret på eksemplet ovenfor:

{
    "keyid": "ssi_foces_2021",
    "issuer": "http://sts-tester",
    "scope": "clear sosi-sts",
    "cpr": "0501792275",
}

JSON REST Content Handler

Ved kald af REST services hvor forespørgslen indeholder JSON i stedet for XML, sørger denne handler for at logge udvalgte attributter fra selve forespørgelsen samt udvalgte Claims fra JWT billetten. Konfigurationen læses fra filerne jsonattributes.config og jsonwebtoken.config. Logning af JWT Claims sker på samme måse som beskrevet ovenfor. Logning af JSON attributter fra Http Body sker ved at angive de ønskede attributter i dot-notation. Handleren håndtere både at selve attributten er et array og at de overliggende objekter er i arrays. I det følgend er vist et eksempel på en konfiguration, et JSON objekt samt hvilke attributter der bliver logget:

Konfiguration
a
c -> cc
c.a
c.b
Input
{
    "a": "A",
    "b": ["B1", "B2"],
    "c": [
        {
            "a": "A1",
            "b": "B1"
        },
        {
            "a": "A2",
            "b": "B2"
        },
        {
            "a": ["A31", "A32"],
            "b": "B3"
        },
        "C1"
    ]
}
Log
{a=[A], c.a=[A1, A2, A31, A32], c.b=[B1, B2, B3], cc=[C1]}


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

JTP-H Request Handler

Denne handler anvender kodebiblioteket JJWT til at parse et indkommende JSON Web Token (JWT) i HTTP Headeren "Authorization". Handleren verificerer at JWT'en overholder JWT Token Profile for Healthcare (JTP-H) specifikationen og udstiller de forskellige attributter fra sikkerhedsbilletten gennem SecurityContext klasserne. Handleren konfigureres i filen jtph.properties som vist i følgende eksempel:

jtph.enabled=true

# Keys
jtph.keys.sdsoidc.type=pkcs12
jtph.keys.sdsoidc.file=sdsoidc.keystore
jtph.keys.sdsoidc.password=kodeord
jtph.keys.sdsoidc.alias=1

# Issuers
jtph.issuers.sds.name=http://issuer.nspop.dk/sds
jtph.issuers.sds.audience=http://audience.nspop.dk/minlog
jtph.issuers.sds.ttl=PT15M
jtph.issuers.sds.assurance.level.1=https://data.gov.dk/concept/core/nsis/loa/Substantial
jtph.issuers.sds.assurance.level.2=https://data.gov.dk/concept/core/nsis/loa/High
jtph.issuers.sds.issuance.policy.1=http://issuance.policy.nspop.dk/nsp

I filen er det muligt at konfigurere hvilke udstedere af sikkerhedsbilletter som handleren skal stole på samt hvilke nøgler der skal bruges til at verificere signaturen på JWT'en. Se driftvejledningen for en detaljeret gennemgang af de forskellige properties.

Response Handler

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.

HTTP Response Length Handler

I denne handler tælles antallet af bytes i svaret fra servicen og dette tilføjes til NSP Access Log Entry

HTTP Response Header Handler

Denne handler tilføjer eventuelle HTTP headers i svaret til NSP Access Log Entry

Security Protocol Response Handler

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

OIO-IDWS Response Signature Handler

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


  • No labels