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 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:
NSP Access Handler (AH) løser følgende opgaver på NSP platformen:
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.
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æreliste
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 indkommende DGWS billet til rådighed for NSP komponenten. AH validerer at billeten er korrekt signeret af en STS.
NSP Access Handler implementerer NSP Security API interfacet og stiller informationer fundet i den indkommende OIO-IDWS billet til rådighed for NSP komponenten. AH validerer at billeten er korrekt signeret af en STS og at hele requestet er signeret af det rigtige anvendersystem.
Den Gode Webservice standarden diktere 2 forksellige 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 en DGWS billet.
OIO-IDWS standarden diktere 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.
Nedenstående graf viser hvorledes AH er opdelt i et antal handlers der hver bidrager til en eller flere af de omtalte opgaver
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 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.
Opretter en ny 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 NSP Access Log Entry også til den nyNSP Audit Log Entry og det hele logges som et JSON objekt via en konfigurerbar Log4J kategori.
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.
sørger for at berige NSP Access Log Entry med størelsen på requestet
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 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:
<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 |
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 |
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.
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.
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.
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 |
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.
På baggrund af den detekterede sikkerhedsprotokol i det indkommende request delegerer denne handler videre til enten OIO-IDWS Request Handler eller DGWS 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 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.