Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Navitabs
rootNSP Access Handler - Leverancebeskrivelse


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.

...

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 ((Med mindre man slår det fra for 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 , 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.

...

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

...

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.

Den Gode Webservice response enhancement

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

...

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

Gliffy Diagram
macroId16885215-2aa7-48ba-b9b0-619ef21f2507
displayNameHandler hierarchy
nameHandler hierarchy
pagePin36


Handlers

I dette afsnit beskrives hver enkelt handler i flere detaljer.

...

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

...

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

...

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.

...

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

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

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:

Code Block
titleKonfiguration
a
c -> cc
c.a
c.b
Code Block
languagejs
titleInput
{
    "a": "A",
    "b": ["B1", "B2"],
    "c": [
        {
            "a": "A1",
            "b": "B1"
        },
        {
            "a": "A2",
            "b": "B2"
        },
        {
            "a": ["A31", "A32"],
            "b": "B3"
        },
        "C1"
    ]
}
Code Block
titleLog
{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:

Code Block
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 propertiesDenne 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

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.

...