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. 

nap-reference-web

nap-reference-facade 

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 af funktionalitet i applikationen begrænset, hvis den åbnes uden at være framet.

Hvis applikationen køres i indlejret 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 kun relevant information sendt tilbage til nap-reference-web. 

Nap-reference-web

Nap-reference-web er bygget med Angular version 9 og fungerer som illustration på:

  1. Projekt opsætning overholdende https://www.nspop.dk/display/public/web/Husregler+for+udvikling+til+NSP.
  2. Brug af NAP SDK NAP SDK - Guide til anvendere

  3. GUI for NAP Projekter.

Nap-reference-web er en front end til nap-reference-facade og deployes i dennes kontekst-rod i byggepipelinen.

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 configuration-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 kontekst roden.

For yderligere information omkring konfiguration henvises til NAP Ref.Impl. - Guide til udviklere.

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.

@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 det kun er beskeder af typen SessionClose. 

Hvis bruger ønsker at blive logget ud sendes en besked med SessionClose fra det 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 den saml/Logout på den server, der holder sessionen.

import { Injectable } from '@angular/core';
import { NapAngularService } from 'nap-angular-sdk';
import {
  filterEvents,
  NAPEventCatalogue,
  NAPMessage
} from 'nap-typescript-sdk';
import { combineLatest, merge, Observable, Subject } from 'rxjs';
import { map, switchMap, tap } from 'rxjs/operators';
import { v4 as UUID } from 'uuid';
import { ConfigurationsService } from './configurations.service';

/**
 * Service to handle user session
 *
 * @export AuthService
 * @class AuthService
 */
@Injectable({
  providedIn: 'root',
})
export class AuthService {

  innerLogout = new Subject<undefined>();
  logOut$: Observable<boolean> = merge(
    this.innerLogout,
    this.napSDK.incoming$.pipe(
      filterEvents([NAPEventCatalogue.v1.SessionClose]),
    )).pipe(
      switchMap(() => this.logOutUrl$),
      tap(logOutUrl => {
        // Direct the window to the OIOSaml logout filter
        window.location.assign(logOutUrl);
        console.log('Will redirect:' + logOutUrl);
      }
      ),
      map(() => true)
    );

  private logOutUrl$: Observable<string> = combineLatest([
    this.configService.fetch(
      config => config.serverUrl
    ),
    this.configService.fetch(config => config.logOutEndpoint)
  ]).pipe(
    map(([serverUrl, logOutUrl]) => serverUrl + logOutUrl),
  )

  constructor(
    private napSDK: NapAngularService,
    private configService: ConfigurationsService
  ) {
  }

  /**
   * completes the current session and logs out the user
   */
  logout(): void {
    console.log('NapReferenceWeb Logging out');
    this.innerLogout.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

I komponenten appointment (src/app/appoinment/), 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.


  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.incoming$.pipe(
    filterEvent(NAPEventCatalogue.v1.PatientOpen),
    map(message => FHIRValueGetter.getPatientInfo(message))
  );


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.


/**
 * Generetas Requests to get appoitnemnts for a given person and organization
 *
 * @export AppointmentService
 * @class AppointmentService
 */
@Injectable({
  providedIn: 'root'
})

export class AppointmentService {

  /**
   * The appointment endpoint
   *
   * @private
   * @memberof AppointmentService
   */
  private appointmentEndPoint$ = this.configurationService.fetch(
    config => config.appointmentsEndpoint
  );

  /**
   * The server url
   *
   * @private
   * @memberof AppointmentService
   */
  private serverUrl = this.configurationService.fetch(config => config.serverUrl);

  /**
   * A refresh indicator
   *
   * @private
   * @memberof AppointmentService
   */
  private serviceActivator = new BehaviorSubject(undefined);

  constructor(
    private http: HttpClient,
    private errorService: ErrorService,
    private configurationService: ConfigurationsService,
    private napSDK: NapAngularService
  ) {
  }

  /**
   * Make a HTTP GET to the serverurl/appointmentendpoint
   * @param patientIdentifier
   */
  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(NAPEventCatalogue.v1.MessageFactory.createSessionErrorMessage(UUID(), error.innerError?.message, error.errorMessage)); // indicate to the host that something went wrong
        return of(undefined);
      }),
    );
  }

  /**
   * Triggers a data update of the service
   */
  refresh(): void {
    this.serviceActivator.next(undefined);
  }
}


Nap-reference-facade

Nap-reference-facade er backend til nap-reference-web og deployes med denne webapplikation i kontekst roden.

Nap-reference-facade er bygget med java 8 og fungerer som illustration på:

  1. Projekt opsætning overholdende https://www.nspop.dk/display/public/web/Husregler+for+udvikling+til+NSP.
  2. Sikkerhed i NAP kontekst Sikkerhedsarkitektur for iNSP løsninger
  3. Brug af Dokumentdelingsservice (DDS)

I bygge processen lægges den bygge nap-reference-web ind i src/main/webapp hvorfra disse er tilgængelig i kontekstroden.

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. - Guide til udviklere.

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.home være sat under execution for wildfly. 
Dette gøres med environmental variabel som vist i compose/development/docker-compose.yml

...
services:
 napreffacade:
    ...
    environment:
      # Set oiosaml.home + open debug socket
      - JAVA_OPTS=$JAVA_OPTS -Doiosaml.home=/pack/oiosaml -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n

	...


Nedenfor er et eksempel på registrering af SPFilteret.


 
@WebListener
public class SpringLoader implements ServletContextListener {
    protected static final String ANNOTATION_CONFIG_CONTEXT = "ANNOTATION_CONFIG_APPLICATION_CONTEXT";

    /**
     * Initialize standalone spring context. Registers the spring configuration and finally register it at the servlet context
     */
    @Override
    public void contextInitialized(ServletContextEvent servletContextEvent) {
        AnnotationConfigApplicationContext springContext = new AnnotationConfigApplicationContext();
        springContext.register(SpringContext.class);
        springContext.refresh();
        final ServletContext servletContext = servletContextEvent.getServletContext();
        servletContext.setAttribute(ANNOTATION_CONFIG_CONTEXT, springContext);
        ServletRegistration servletRegistration = servletContext.addServlet("SAMLDispatcherServlet", DispatcherServlet.class);
        servletRegistration.addMapping("/saml/*");
        FilterRegistration.Dynamic filterRegistration = servletContext.addFilter("LoginFilter", SPFilter.class);
        filterRegistration.addMappingForUrlPatterns(null, false, "/api/*");
        filterRegistration.addMappingForUrlPatterns(null, false, "/saml/*");
        filterRegistration.setInitParameter("a", "b");
    }

    @Override
    public void contextDestroyed(ServletContextEvent servletContextEvent) {
        Object ctx = servletContextEvent.getServletContext().getAttribute(ANNOTATION_CONFIG_CONTEXT);
        if(ctx instanceof AnnotationConfigApplicationContext) {
            ((AnnotationConfigApplicationContext)ctx).close();
        }
    }
}


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. 

@Provider
public class AuthFilter implements ContainerRequestFilter {
    static private final Logger log;
    public static final Response ACCESS_DENIED = Response.status(401).build();
    private static final String[][] XML_PATH_TO_SAML_ASSERTION = {
            {NameSpaces.WSA_1_0_SCHEMA, WSATags.metadata.getTagName()},
            {NameSpaces.LIBERTY_DISCOVERY_SCHEMA, LibertyDiscoveryTags.securityContext.getTagName()},
            {NameSpaces.LIBERTY_SECURITY_SCHEMA, LibertySecurityTags.token.getTagName()},
            {NameSpaces.SAML2ASSERTION_SCHEMA, SAMLTags.ASSERTION}
    };

    static {
        log = Logger.getLogger(AuthFilter.class);
    }

    // https://howtodoinjava.com/resteasy/resteasy-containerrequestfilter-example/
    @Override
    public void filter(ContainerRequestContext requestContext) {
        final RequestContext context = RequestContext.getContext();
        final UserAssertion userAssertion = UserAssertionHolder.get();
        context.setAssertion(userAssertion);
        context.setUserIdCard(getIdCardFromAssertion(userAssertion));
    }

    private UserIDCard getIdCardFromAssertion(UserAssertion ua) {
        UserAttribute attribute = ua.getAttribute(OIOSAMLAttributes.DISCOVERY_EPR);
        if (attribute == null) {
            if (log.isDebugEnabled()) log.debug("No embedded idcard in SAML assertion");
            return null;
        }

        if (!Attribute.URI_REFERENCE.equals(attribute.getFormat())) {
            if (log.isDebugEnabled()) log.debug("Attribute of name " + OIOSAMLAttributes.DISCOVERY_EPR +
                    " is not an embedded idcard - NameFormat mismatch (was + " + attribute.getFormat() +
                    ", expected " + Attribute.URI_REFERENCE);

            return null;
        }

        if (log.isDebugEnabled()) log.debug("Extracting idcard from SAML assertion");

        String attributeValue = attribute.getValue();
        InputSource inputSource = new InputSource(new StringReader(attributeValue));
        DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory.newInstance();
        documentBuilderFactory.setNamespaceAware(true);
        DocumentBuilder documentBuilder;
        try {
            documentBuilder = documentBuilderFactory.newDocumentBuilder();
            Document document = documentBuilder.parse(inputSource);

            Element idCardElm = getDescendant(document.getDocumentElement());

            return (UserIDCard) new IDCardModelBuilder().buildModel(idCardElm);

        } catch (ParserConfigurationException | SAXException | IOException e) {
            log.error("Error parsing embedded idcard", e);
        }

        return null;
    }

    private Element getDescendant(Element elm) {
        for (String[] qName : AuthFilter.XML_PATH_TO_SAML_ASSERTION) {
            NodeList nodeList = elm.getElementsByTagNameNS(qName[0], qName[1]);
            if (nodeList == null || nodeList.getLength() == 0) {
                log.error("Path element not found: {" + qName[0] + "}" + qName[1]);
                return null;
            }
            Node child = nodeList.item(0);
            if (!(child instanceof Element)) {
                log.error("Path component {" + qName[0] + "}" + qName[1] + " is not an element; node=" + child);
                return null;
            }
            elm = (Element) nodeList.item(0);
        }

        return elm;
    }
}


dk.sosi.seal

Seal anvendes til at indlejre et SOSI IDkort i et XML dokument som er parseable for DGWS.

Nedenstående er eksempler på en DGWS interceptor, som sætter en DGWS header for client requests til DGWS.

/**
 * Soap interceptor that adds DGWS headers to XDS calls
 */
public class DGWSInterceptor extends AbstractSoapInterceptor {
    // https://www.nspop.dk/display/ESP/Teknisk+implementeringsvejledning+Aftaleoversigt
    static private final Logger log;

    private static final AppConfiguration conf = AppConfiguration.getInstance();
    static private CredentialVault certificateVault;
    private UserIDCard userIdCard;

    public DGWSInterceptor(UserIDCard userIdCard) {
        super(Phase.PRE_STREAM);
        this.userIdCard = userIdCard;
    }

    static {
        log = Logger.getLogger(DGWSInterceptor.class);

        try {
            Properties props = SignatureUtil.setupCryptoProviderForJVM();

            certificateVault = new ClasspathCredentialVault(props, conf.getKeystorePath(), conf.getKeystorePassword());

        } catch (Exception e) {
            log.error("Initialization error", e);
        }
    }

    @Override
    public void handleMessage(SoapMessage message) throws Fault {
        // DGWS is SOAP11
        message.setVersion(Soap11.getInstance());

        // Add the DGWS headers
        SOSIFactory sosiFactory = new SOSIFactory(certificateVault, SignatureUtil.setupCryptoProviderForJVM());

        Request request = sosiFactory.createNewRequest(false, null);
        request.setIDCard(userIdCard);
        Document sosi = request.serialize2DOMDocument();
        NodeList children = sosi.getDocumentElement().getFirstChild().getChildNodes();
        for (int i = 0; i < children.getLength(); i++) {
            Node element = children.item(i);
            QName qname = new QName(element.getNamespaceURI(), element.getLocalName());
            Header dgwsHeader = new Header(qname, element);
            message.getHeaders().add(dgwsHeader);
        }
    }
}


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.

/aftaler/{cpr}

Den eneste aftager af denne service er nap-reference-web. 

Headers
KeyValue
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ængig af database eller andre interne services, returnere den altid statuskode 200, hvis applikationen kører.

Eksempel på request/response

http://nap/web/reference/services/main/aftaler/124567890

{
    "title": "Ekkokardiografi",
    "orgName": "Skejby Sygehus",
    "indication": "Har ondt i hjertet somme tider",
    "date": 1591142400
}