Page History
Navitabs | ||||
---|---|---|---|---|
|
Table of Contents |
---|
Introduktion
Anvendere betragtes som udviklere af afprøvningsprojekter. Denne guide har til formål at give disse udvikler eksempler på en webapplikation og en facade.
Guiden inkluderer instruktioner til opsætning af hele nap platformen samt selvstændige eksempler på kodeimplementationer.
Nap-reference-implementering
Nap-reference-web er en web applikation, som implementerer nap-typescript-sdk og nap-angular-sdk. Som konsekvens af dette, kan denne køres indlejret i et værtssytem (eks. nap-java-host) og kommunikerer med værtssystemet over en indlejret javascript bro. Igennem denne bro henter applikationen en SAMLassertion og patient konteksten fra værtssytemet, hvorefter den kalder den tilhørende facade (nap-ref-facade) og forsøger at hente aftaledokumenter den valgte patient i værtssystemet. Kaldet indeholder den overførte SAMLassertion som en authentication header, og en hardcoded SOR værdi som X-OrganizationSor header.
Nap-reference-facade er en javaapplikation, som implementerer SEAL.java til at validerer SAMLassertion, org.openehealth.ipf.commons til at hente aftaledokumenter fra Dokumentdelingsservice (DDS), og dk.s4.hl7.builders til at formatere aftaledokumenter fra XML til objekter, hvorfra den hiver den relevante information ud og sender tilbage til klienten.
Funktionaliteten af Nap-ref-web illustreres bedst, når applikation er indlejret i et værstsystem, f.eks. nap-java-host Platformsservices (NAP) - Leverancebeskrivelse.
Kom i gang med NAP
I følgende beskrives opsætningstrinene for at komme i gang med NAP platformen.
Krav til software:
Docker skal være installeret, da opsætningen foregår via docker-compose.
Et docker netværk kaldet nap_net skal laves (`docker network create nap_net`)
Komponenterne fra https://svn.nspop.dk/svn/components/nap/ skal hentes ned.
Start nap-host-java
OBS vi har ikke nogen distributionskanal for denne executeable endnu. Så foreløbigt:
Kør `mvn install -P generateexecutable` og start den executable det bliver generate i /target.
Login ved at trykke på localhost og bruge default login credentials. Dette vil trække en SAMLassertion fra STS på test1. Du kan bruge denne i 30 min.
Skriv et cpr nummer på en test person (Eksempelvis "2708599967", som er et hyppigt anvendt test cpr nummer). Du kan nu browse rundt i fanerne.
For at fanen "afprøvningsplatformen" fungere, skal Nap-Compose og Nap-Lobby startes, som er de næste trin i opsætning.
Dette vil hoste lobbyen på localhost:8080/nap/lobby/web/, som er den url hosten kigger efter.
Nap-Compose
Ideen med nap-compose er, at denne reverse proxy fungerer som en NSP loadbalancer med path rewriting.
For at starte denne reverse proxy køres `docker-compose up`. Dette vil åbne port 8080 på localhost.
Nap-Lobby
Nap-lobby er kataloget for de afprøvningsprojekter, der findes i nappen.
Kør `docker-compose up` fra compose/test. Med Nap-compose kørende, er denne nu tilgængelig for nap-host-java.
For at at Lobby skal vise nogen projekter skal den have forbindelse til Nap-admin.
Nap-admin
Kør `docker-compose up` fra compose/test. Med Nap-compose kørende, er denne nu tilgængelig for Lobbyen og projekter bliver vist
Ny implementering / Dit projekt
Der ligger et Developer projekt, der hurtigt kan sætte gang i anvendelsen af NAP - platformen som udviklingsmiljø.
Hvis dette projekt trykkes på, vil java-host åbne en hvilken som helst applikation der hostes på lokalhost:4600.
Konfigurer din løsning ind i NAP
Når en ny applikation skal ind på platformen, er der 2 steder platformen skal konfigureres før det fungerer.
Reverse proxy
Denne reverse proxy konfigureres ved at opdatere nap-httpd.conf.
<VirtualHost *:8080> ServerName nap
ProxyPass /nap/reference/web/services/main http://napreffacade:8080
ProxyPassReverse /nap/reference/web/services/main http://napreffacade:8080
ProxyPass /nap/reference/web http://naprefweb:8080
ProxyPassReverse /nap/reference/web http://naprefweb:8080
</VirtualHost>
Lav en konfiguration magen til ovenfor hvor reference og naprefweb udskiftes efter ønske.
Urlen skal dog passe med, den url der indsættes nedenfor
Database
For at dit projekt skal vises i lobbyen, skal projektet optræde i din lokale napadmindb.
Du kan gøre dette med sql inserts direkte eller opdatere compose/db/migration/V2__insert_data_localhost.sql med en kopi af nedenstående, som bare opdateres med dit nye info
Code Block | ||
---|---|---|
| ||
insert into administration.Project (active, description, releaseDate, version, name, id) values (true, 'Dit udviklingsprojekt kan åbnes her.', '2018-11-30', '1.0.0', 'Nap Web Develop', UuidToBin(UUID()));
insert into administration.Manifest (releaseDate, url, version, id) values ('2019-11-30', 'http://localhost:8080/nap/developer/web/', '1.0.0', UuidToBin(UUID()));
insert into WebApp (active, manifest_id, name, id, project_id) values (true, (select id from administration.Manifest where url LIKE 'http://localhost:8080/nap/developer/web/' ), 'Nap Web Developer version 0.0.1', UuidToBin(UUID()), (select id from administration.Project where name LIKE 'Nap Web Develop'));
insert into WebApp_cvr (WebApp_id, cvr) values ((select id from administration.WebApp where name LIKE 'Nap Web Developer version 0.0.1'), '20921897');
insert into Manifest_eventCatalogueVersions (Manifest_id, eventCatalogueVersions) values ((select id from administration.Manifest where url LIKE 'http://localhost:8080/nap/developer/web/' ), 1);
|
database og flyway skal således køres igen med `docker-compose up & docker-compose down`
Nap-reference-web
Nap-reference-web er bygget med Angular version 9 og fungerer som illustration på:
- Opsætning og struktur af angular projekt.
Brug af NAP SDK
- GUI for NAP Projekter.
Applikationens hovedfunktionalitet er at vise aftaledokumenter for den patient, der er i kontekst i det værtssystem, den er indlejret. Der skal tilføjes en NAP Bridge (https://www.nspop.dk/pages/viewpage.action?pageId=102392863#NAPSDK-Guidetiludviklere-NAPBridge(kontekstdeling)) på den givne applikations global scope, for at funktionaliteten fungere.
Diagram over NAP Bridge virkmåde, kan ses på dette link https://www.nspop.dk/x/U1oaBg
Opsætning og struktur af et angular projekt
Komponenter
Da angular frameworket lægger sig op af model-view-controller pattern er dette også implementeret i nap-reference-web.
Derfor er der simple komponenter til at visning aftaler, hjælpinformation, fejl osv.
Services
Services håndterer forretningslogikken.
Derfor er der simple services til håndtering af authentication, applikationsfejl og konfigurering osv.
Dependencies
Der ligger en .npmrc, som sætter npm registry til https://nexus.nspop.dk/nexus/repository/nsp-npm/
Konfiguration
Nap-reference-web benytter sig af en konfigurationsfil (assets/configurtation.json), som loades via configuration-servicen. Denne konfigurationsfil bliver således overskrevet i de forskellige docker-compose setups.
Da NSP web applikationer kan blive deployet på vilkårlige paths, er det vigtigt at applikationen fungerer med relative paths. Detter er opnået ved hashrouting.
Code Block |
---|
@NgModule({
imports: [RouterModule.forRoot(routes, { useHash: true })],
exports: [RouterModule]
})
export class AppRoutingModule { }
|
Testing
Nap-reference-web benytter sig af testframeworket Karma, da det kommer default med angular. Karma bruger Istanbul til at genere test-coverage rapporter. Testene køres i en headless chromium browser.
Dokumentation
Kodedokumentationen bliver generet med TSDoc.
Brug af NAP SDK
Nap-reference-web implementerer version 1 af eventkataloget.
Session-Open og Session-close (security)
Session-open starter en trusted session hvor brugerens SAMLassertion overføres. Session-close lukker sessionen og brugerens SAMLassertion slettes. Denne funktionalitet findes i auth-servicen.
Code Block | ||
---|---|---|
| ||
export class AuthService {
private sessionMessageSubject = new BehaviorSubject<NAPMessage | undefined>(
undefined
);
/**
* The current session
*
* @memberof AuthService
*/
public session$ = this.sessionMessageSubject.asObservable();
constructor(private napSDK: NapAngularService) {
this.napSDK.incomming$
.pipe(
filterEvents([
NAPEventCatalogue.v1.SessionOpen,
NAPEventCatalogue.v1.SessionClose,
])
)
.subscribe((napMessage) => {
if (napMessage.event.type === NAPEventCatalogue.v1.SessionOpen) {
this.sessionMessageSubject.next(napMessage);
} else {
this.sessionMessageSubject.next(undefined);
}
});
const napMsg: NAPMessage = {
date: new Date().toISOString(),
id: UUID(),
event: { type: NAPEventCatalogue.v1.SessionOpen },
};
// Ask for the SAMLassertion in host
this.napSDK.sendMessage(napMsg);
}
/**
* Tricker logout event
*/
logout(): void {
this.sessionMessageSubject.next(undefined);
const napMsg: NAPMessage = {
date: new Date().toISOString(),
id: UUID(),
event: { type: NAPEventCatalogue.v1.SessionClose },
};
this.napSDK.sendMessage(napMsg);
}
} |
Patient-Open og Patient-close
Patient-open sender den brugervalgte patient journal og patient-close lukker den bruger valgte patient (set fra det indlejrede systems perspektiv). Et eksempel på dette kan ses i appointment.component
Code Block |
---|
constructor(
private napSDK: NapAngularService,
private appointmentService: AppointmentService,
private authService: AuthService
) {
const napMsg: NAPMessage = {
date: new Date().toISOString(),
id: UUID(),
event: {
type: NAPEventCatalogue.v1.PatientOpen,
},
};
this.napSDK.sendMessage(napMsg);
}
public currentPatient$: Observable<NAPPatientInfo | undefined> = this.napSDK.incomming$.pipe(
filterEvent(NAPEventCatalogue.v1.PatientOpen),
map(message => FHIRValueGetter.getPatientInfo(message))
); |
Session-Error
Session-error sendes, hvis der sker en uventet fejl i projektet skal dette sendes til værtssystemet og vice versa. Et eksempel på dette findes i appointment-service:
Code Block |
---|
private appointmentEndPoint$ = this.configurationService.fetch(
config => config.appointmentsEndpoint
);
private serverUrl = this.configurationService.fetch(config => config.serverUrl);
private createNapErrorMessage(error: GenericAppError): NAPMessage {
return {
date: new Date().toISOString(),
id: UUID(),
event: {
type: NAPEventCatalogue.v1.SessionError,
context: [
{
resource: {
resourceType: FHIRValueSetter.FHIRResourceType.Basic,
code: {
coding: [
{
code: NAPEventCatalogue.v1.SessionError,
system: FHIRValueSetter.FHIRSystem.NAP,
},
],
},
identifier: [
{
system: FHIRValueSetter.FHIRIdentifierSystem.NAPErrorMessage,
value: error.innerError?.message ? error.innerError?.message : '',
},
{
system: FHIRValueSetter.FHIRIdentifierSystem.NAPErrorDescription,
value: error.errorMessage,
},
],
},
},
],
}
}
}
public getAppointments(patientIdentifier: string | undefined): Observable<any[] | undefined> {
return combineLatest(
[
this.serverUrl,
this.appointmentEndPoint$,
this.serviceActivator
]
).pipe(
switchMap(([serverUrl, endpointPath, _]) => this.http.get<any[]>(serverUrl + endpointPath + '/' + patientIdentifier)),
catchError(error => {
this.errorService.postError(error);
this.napSDK.sendMessage(this.createNapErrorMessage(error)); // indicate to the host that something went wrong
return of(undefined);
}),
);
} |
Nap-reference-facade
Nap-reference-facade er bygget med java 8 og fungerer som illustration på:
- Projekt opsætning overholdende https://www.nspop.dk/display/public/web/Husregler+for+udvikling+til+NSP.
- Sikkerhed i NAP kontekst
Brug af Dokumentdelingsservice (DDS)
Opsætning og struktur
Dependencies
Dependencies er hentet fra https://nexus.nspop.dk/nexus/content/groups/public og de dependencies, som stilles til rådighed af wildfly8 platformen er angivet med scope provided.
For at kunne kalde Dokumentdelingsservice (DDS) er følgende dependencies anvendt:
...
dk.sosi.seal
...
Java-bibliotek til understøttelse af "Den Gode Webservice" og validering af SAMLassertion, se http://digitaliser.dk/group/374971.
...
dk.s4.hl7.builders
...
Dansk profileret XML converter af hl7 clinical documents
...
org.openehealth.ipf.commons
...
Warning |
---|
NAP projektet er ikke aktivt og NAP er derfor ikke pt. under support og vedligehold. |
Table of Contents |
---|
Introduktion
Denne guide er primært målrettet til anvendere, som skal implementere en ny afprøvningsløsning og har til formål, at give eksempler på kode og opsætning af web applikation og facade til NAP.
Guiden beskriver en web applikation som bruger en backend, som interagerer med Dokumentdelingsservice (DDS), og som anvender oiosaml.java 2.21 (https://www.digitaliser.dk/resource/5359238) som sikkerhed- og autentikationslaget jf. Sikkerhedsarkitektur for iNSP løsninger.
Der er beskrevet instruktioner til opsætning af et web projekt og en backend, som overholder givne NSP standarder (Husregler for webløsninger og https://www.nspop.dk/display/public/web/Husregler+for+udvikling+til+NSP)
Guiden indeholder eksempler på kodeimplementationer, men ellers er projekterne tilgængelig på svn.nspop.dk og kan bruges som inspiration til et afprøvningsprojekt.
Sammenhæng med øvrige dokumenter
Dette dokument er en del af den samlede dokumentation for NAP Reference implementation.
Dokumentet er udformet, så det i videst muligt omfang opfylder sit formål uafhængigt af de øvrige dokumenter.
Ønskes mere information omkring arkitektur og design findes dette på NAP Ref.Impl. - Design og Arkitektur beskrivelse.
Ønskes mere information omkring installationsvejledning til anvender kan findes på NAP Ref.Impl. - Installationsvejledning.
Hvis der er behov for yderligere dokumentation omkring hele NAP platformen, henvises til NAP Platform - Guide til anvendere.
NAP Ref.Impl. Opbygning
Nap-references består af en java backend (nap-reference-facade) samt en front for backend (nap-reference-web), bygget med angular frameworket og som anvender version 1.0.0 af nap-typescript-sdk og nap-angular-sdk.
Applikationens hovedfunktionalitet er at vise aftaledokumenter for den patient, der er i kontekst i det værtssystem, den er indlejret i (f.eks. nap-java-host). Derfor er funktionalitet i applikationen begrænset, hvis den åbnes uden at være framet.
Hvis applikationen køres indlejret i et værtssystem som understøtter sikker browser opstart og tilføjer NAP Bridge på global scope af indlejrede systeme kan kommunikation mellem host og nap-reference ske i gennem NAP SDK - Guide til anvendere.
Denne kommunikation giver muligheden for overførelse af informationer som patientkontekst og sessionsfejl mellem det indlejrede system og værtssystemet.
Når nap-reference får overført en patientkontekst kaldes facaden med det cpr nummer samt en SOR værdi tilføjet i en "X-OrganizationSor" header (denne værdi er hardcoded i dette tilfælde, da den ikke kan læses ud af SOSI IDkortet)". Facaden validere kaldet og viderestiller til Dokumentdelingsservice (DDS).
Nap-reference-facade sørger for at validere kaldet og hente relevante aftaledokumenter (via anvendelse af org.openehealth.ipf.commons) for den valgte patient. For at formatere aftaledokumenterne fra XML til objekter, bruges biblioteket "dk.s4.hl7.builders".
Før aftaledokumenterne returneres, bliver information, der anvendes nap-reference-web udtrukket.
Nap-reference-web
Nap-reference-web er bygget med Angular version 9 og fungerer som illustration på:
- Projekt opsætning overholdende https://www.nspop.dk/display/public/web/Husregler+for+udvikling+til+NSP.
Brug af NAP SDK NAP SDK - Guide til anvendere
- GUI for NAP Projekter.
Nap-reference-web er en front end til nap-reference-facade og deployes i dennes kontekst-rod i byggepipelinen.
Se NAP Ref.Impl. - Installationsvejledning for mere information omkring Jenkins pibeline.
Opsætning og struktur af et angular projekt
Komponenter
Angular frameworket lægger sig op af MVC (model-view-controller) design mønsteret, og dette er implementeret i nap-reference-web.
Der er simple komponenter til at visning af aftaler, hjælpeinformationer, fejl osv.
Services
Services håndterer forretningslogikken.
Der er simple services til håndtering af authentication, applikationsfejl og konfigurering osv.
Dependencies
Der er brugt dependencies, som er hentet igennem NSP nexus. Der ligger en .npmrc i projektet, som sætter npm registry til https://nexus.nspop.dk/nexus/repository/nsp-npm/ således dependencies fra package.json hentes herfra.
Konfiguration
Nap-reference-web benytter sig af en json konfigurationsfil, som loades via configurations servicen.
Der findes 2 konfigurationer en til dev (configurations-dev.json) samt en til releases (configurations.json) som adskiller sig i serverens url.
Configurations-dev.json anvendes til når nap-refence-web er under udvikling og køres via ng serve (så der kommer live reloading af kodeændringer), hvor configurations.json anvendes når nap-reference-web er pakket og deployet sammen med nap-reference-facade i kontekstroden.
For yderligere information omkring konfiguration henvises til NAP Ref.Impl. - Driftsvejledning.
Da INSP web applikationer og services kan blive deployet på vilkårlige url'er, og skal kunne loade ressourcer relativt til, hvor de er deployet, er det vigtigt at applikationen fungerer med relative paths.
Dette er opnået ved hashrouting.
Code Block |
---|
@NgModule({
imports: [RouterModule.forRoot(routes, { useHash: true })],
exports: [RouterModule]
})
export class AppRoutingModule { }
|
Du kan læse mere på https://angular.io/guide/router
Debugging
Hvis Nap-reference-web åbnes i browser kan den debugges med almindelige developer tools.
Hvis den åbnes i nap-java-host, er den eneste debugging mulighed konsol logs.
Testing
Nap-reference-web benytter sig af testframeworket Karma, da det kommer default med angular. Karma bruger Istanbul til at generere test-coverage rapporter. Testene køres i en headless chromium browser.
For opbygning af tests, henvises til at kigge i projektets .spec filer.
Dokumentation
Koden er dokumenteret efter TSDoc standard og kan derfor genereres med TSDoc.
Logging
Der bliver logget til konsollen i tilfælde af fejl - endvidere sendes logiske fejl med NAP SDK'et, som beskrevet nedenfor.
Brug af NAP SDK
Nap-reference-web implementerer version 1 af eventkataloget, og da det er et angular projekt, er der gjort brug af nap-angular-sdk'et.
nap-reference-web gør brug af det udstillede interface i nap-angular-sdk, og nedenfor er der eksempler på hvordan det er blevet brugt.
Security (SAML logout samt Session-close NapEvent)
Der er lavet en AuthService, som sørger for at håndtere sessioner.
Nedenstående funktionalitet findes i src/app/services/auth.service.ts.
Auth service lytter på indkommende beskeder fra NAP SDK'et, og filtrerer beskeder, således der kun reageres på beskeder af typen SessionClose.
Hvis en bruger ønsker at blive logget ud sendes en besked med SessionClose fra den kontekst brugeren har igangsat eventet.
Det betyder at eventet både kan sendes fra indlejret system til værtsystem og omvendt.
Når brugeren skal logges ud skal browseren flyttes til saml/Logout på den server, der holder sessionen.
Se auth.service.ts i https://svn.nspop.dk/src/components/nap/nap-reference-web/trunk/src/app/services/
Patient-Open og Patient-close
I komponenten appointment (src/app/appointment/), vises de forskellige aftaler for den givne patient.
For at få den nuværende patient, sendes en besked med typen PatientOpen igennem SDK'et. Dette gøres i constructoren.
Herefter lyttes der på indkommende beskeder med typen PatientOpen. Der gøres brug af en hjælpe metode i nap-typescript-sdk, FHIRValueGetter.getPatientInfo(), som konvertere den indkommende besked til et objekt som indeholder patient oplysningerne.
Hvis den nuværende patient skal lukkes, set fra det indlejrede systems perspektiv, sendes der en besked med typen PatientClose.
se appointment.component.ts i https://svn.nspop.dk/src/components/nap/nap-reference-web/trunk/src/app/appointment/
Session-Error
I appointment service (src/app/service/appointment.service.ts) vises et eksempel på fejlhåndtering som skal gå igennem NAP SDK'et.
createNapErrorMessage() opbygger en besked med typen SessionError, som indikerer der er sket en uventet fejl i projektet som skal sendes til værtssystemet og vice versa.
Fejlen bliver sendt hvis kaldet til getAppointments() fejler.
se appointment.service.ts i https://svn.nspop.dk/src/components/nap/nap-reference-web/trunk/src/app/services/
Nap-reference-facade
Nap-reference-facade er backend til nap-reference-web.
Nap-reference-facade er bygget med java 8 og fungerer som illustration på:
- Projekt opsætning overholdende https://www.nspop.dk/display/public/web/Husregler+for+udvikling+til+NSP.
- Sikkerhed i NAP kontekst Sikkerhedsarkitektur for iNSP løsninger
Brug af Dokumentdelingsservice (DDS)
I bygge processen lægges nap-reference-web ind i src/main/webapp, hvorfra disse er tilgængelig i kontekstroden. Se NAP Ref.Impl. - Installationsvejledning for mere information omkring Jenkins pibeline.
Opsætning og struktur
Dependencies
Dependencies er hentet fra https://nexus.nspop.dk/nexus/content/groups/public og de dependencies, som stilles til rådighed af wildfly8 platformen er angivet med scope provided.
For at kunne kalde Dokumentdelingsservice (DDS) er følgende dependencies anvendt:
dk.sosi.seal | Java-bibliotek til understøttelse af "Den Gode Webservice" og validering af SAMLassertion, se http://digitaliser.dk/group/374971. |
dk.s4.hl7.builders | Dansk profileret XML converter af hl7 clinical documents |
org.openehealth.ipf.commons | Dansk profileret bibliotek til Cross Enterprise Document sharing. Bruges til at integrere Dokumentdelingsservice (DDS). Du kan læse mere på https://github.com/KvalitetsIT/aftaledeling/tree/master/dgws-eksempel/src/main/java/dk/sds/appointment. |
dk.digst.oiosaml2.java | Danske profilering af OASIS SAML 2.0 standarden. |
Konfiguration
Alt konfiguration foregår ved at loade filer fra et selv-defineret wildfly modul og ind i classpath under deployment.
Dette gør wildfly ved at modulet defineres i jboss-deployment-structure.xml.
Der findes flere information om hvordan nap-refernece-facade konfigureres på NAP Ref.Impl. - Driftsvejledning.
Testing
Testene bliver eksekveret af maven-surefire-plugin med test frameworket junit. Test coverage bliver målt af Jacoco.
Dokumentation
Kodedokumentationen overholder javadoc standarden således dette kan generes med et værktøj fra fx den IDE man bruger.
Sikkerhed
Sikkerhedsarkitekturen følger det skitserede i Sikkerhedsarkitektur for iNSP løsninger. Dermed er der åben for mulighederne for integration til udbredte procedure Sikker browser opstart, samt understøtter tilslutning til Nemlogin.
dk.digst.oiosaml2.java
Anvendes som autentifikationsfilter. For at et OIOSAML kan loades skal oiosaml-kofigurationer være placeret i oiosaml.home under deployment.
Indstilling af oisaml.home og konifiguration af OIOSAML sker som vist i compose/development/docker-compose.yml med environmental variable og ved mounte konfigurationsfiler ind.
For registreing af SPFIlter se SpringLoader.Java i https://svn.nspop.dk/src/components/nap/nap-reference-facade/trunk/src/main/java/dk/sds/nsp/nap/reference/facade/
OIOSAML sørger for at validere den assertion der kommer fra en given iDP (https://www.nspop.dk/display/public/web/Sikkerhedsservices+%28STS%29+-+Leverancebeskrivelse i dette tilfælde) og tilføjer denne til brugerens session.
Der findes eksempel på hvordan OIOSAML konfigureres på NAP Ref.Impl. - Guide til udviklere.
SOSI idkort fra Samlassertion
Desuden er der implementeret et service specifikt autentifikationsfilter, der udtrækker det IDkort, som er indlejret i en SAMLassertion så det kan bruges i DGWS kald.
Se AuthFilter.java i https://svn.nspop.dk/src/components/nap/nap-reference-facade/trunk/src/main/java/dk/sds/nsp/nap/reference/facade/filters/AuthFilter.java
dk.sosi.seal
Seal anvendes til at indlejre et SOSI IDkort i et XML dokument som er parseable for DGWS.
for et eksemple på en SOAP interceptors, som sætter en DGWS header for client requests til DGWS se https://svn.nspop.dk/src/components/nap/nap-reference-facade/trunk/src/main/java/dk/sds/nsp/nap/reference/facade/soapinterceptor/.
Snitfladebeskrivelse og brug
Nap-reference-facades snitflader bliver beskrevet i følgende.
oiosaml
Dokumentationen OIOSAML kan læses her https://github.com/digst/OIOSAML.Java/tree/master/docs
Men konkret anvendes følgende 2 endpoints til autentifikation og logout.
/saml/SAMLAssertionConsumer
Brugeres til at validere autentifikations requests og registrere en brugers assertion i en threadlocal session.
/saml/Logout
Bruger til single logout. Den sletter brugerens session.
/youAreLoggedOut
Anvendes af oiosaml.java som for singleLogoutService i forbindelse med Sikker browser opstart.
Hvis en bruger, som har startet applikationen med sikker browser opstart ønskes logget ud, vil oiosaml.java navigerer brugeren til dette endpoint, når brugeren er blevet logget ud.
Dette endpoint er derfor ikke beskyttet af autentikationsfilter og vil altid returnere 200 samt en html, der fortæller brugeren er logget ud
Konfiguration
Alt konfiguration foregår ved at loade filer fra et selv-defineret et wildfly module ind i classpath under deployment.
Dette gør wildfly ved at modulet defineres i jboss-deployment-structure.xml.
Testing
Testene bliver eksekveret af maven-surefire-plugin med test frameworket junit. Test coverage bliver målt af Jacoco.
Dokumentation
Kodedokumentationen overholder javadoc standarden således dette kan generes med et værktøj fra fx den IDE man bruger.
Sikkerhed
dk.sosi.seal bliver brugt til at verificere SAMLassertion.
Code Block | ||
---|---|---|
| ||
/**
* @param headers Map of request headers
* @return Saml assertion if its valid or null in case of invalid SAML assertion
* @throws AuthenticationException If ant authentication exception occure
*/
public OIOSAMLAssertion extractAndValidate(MultivaluedMap<String, String> headers) throws AuthenticationException {
final List<String> authentication = headers.get(AUTHENTICATION_PROPERTY);
try {
String xml = new String(Base64.decode(authentication.get(0)), StandardCharsets.UTF_8);
Document doc = parseXml(xml);
Element encryptedAssertionElm = doc.getDocumentElement();
PrivateKey privateKeyForAudience = certificateVault.getSystemCredentialPair().getPrivateKey();
// decrypt the xml for the assertion and parse it
final Element element = EncryptionUtil.decryptAndDetach(encryptedAssertionElm, privateKeyForAudience);
OIOSAMLAssertion assertion = new OIOSAMLAssertion(element);
log.debug("extracted: \n" + assertion.getUID());
validateAssertion(assertion);
return assertion;
} catch (IOException | ParserConfigurationException | SAXException e) {
throw new AuthenticationException("Could not validate authentication header", e);
}
} |
Snitfladebeskrivelse og brug
Nap-reference-facade har 2 snitflader som bliver beskrevet i følgende.
/aftaler/{cpr}
Den eneste aftage aftager af denne service er nap-reference-web.
Headers | |||
---|---|---|---|
Key | Value | Authentication | BASE64 encoded SAMLassertion |
X-OrganizationSor | Sor nummer (bruges af dokumentdelingsservicen) |
/isAlive
Bruges af NSP loadbalanceren for at tjekke at servicen er deployet. Returnerer en html side med deployment info.
Da denne service ikke er afhængige af afhængig af database eller andre interne services, returnere den altid statuskode 200, hvis aplikationen kørerapplikationen kører.
Eksempel på request/response
...