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