Page History

...

Der er også lavet en "trust"-løsning, så enkelte organisationer må kalde med system id-kort og en HSUID header, der angiver, at man er en autoriseret læge, der handler på egne vegne eller man er en autoriseret sygeplejerske, der handler på vegne af en autoriseret læge.

Servicen kan kun kaldes af sundhedsfaglige og indeholder følgende brugertyper som hver har lidt forskelligt forretningslogik:

...

Dette trin opererer udelukkende på NSP Security API og forsøger udfra undersøgelse af NSP Security API modellen at matche til een af komponentens brugertyper. Dette kan med fordel laves som en række af match-metoder (en til hver brugertype) på en ActorProvider-klasse i komponenten. En ActorProvider kan bestemme en Actor, hvis en-og-kun-en af de implementerede match metoder returnere en Actor. I dette tilfælde sendes denne videre i algoritmen - ellers kastes en Exception.

I match-metoderne er det kun attributterne på modellen i NSP SecurityAPI (SecurityContext) som ligger til grund for valget af Actor og det er klart at nogle af disse vil ikke kunne matche med vores nuværende DGWS/IDWS billetter, men fremtidige vil kunne, derfor skal vi stadig have dem med. Implementationen skal matche det, der er dokumenteret i komponentens design og arkitekturdokumentation.

I NSP Security API findes der en DevelopmentSecurityProvider klasse, der vil kunne anvendes i udarbejdelse af unit tests for ActorProvider-klassen.

Eksempel på ActorProviderActorProviders match-funktion:

I NSP Eksempl Service laves herefter en ActorProvider klasse der har en " public Actor getActor(SecurityContext) " metode som kalder følgende metoder:

• private Actor matchDoctor(SecurityContext)

• private Actor matchNurse(SecurityContext)

• private Actor matchNurseOnBehalfOfDoctor(SecurityContext)

• private Actor matchHealthCareProfessional(SecurityContext)

• private Actor matchExecutiveHealthCareProfessional(SecurityContext)

• private Actor matchHealthCareProfessionalOnBehalfOfDoctor(SecurityContext)TODO: SecurityContextProvider dokumenteres (og findes som development udgave)

private Actor matchTrustedSystemUser(SecurityContext)

I det følgende vil vi give et eksempel i pseudokode på, hvordan matchHealthCareProfessional og matchTrustedSystemUser vil kunne se ud:

public Actor getActor(SecurityContext sc) {
	if (sc.getTicket.isValid()) {
		throw new SecurityException("Sikkerhedsbilletten er ikke valid");
	}

	Actor doctor = matchDoctor(sc);
	Actor nurse = matchNurse(sc);
	Actor nurseOnBehalfOf = matchNurseOnBehalfOfDoctor(sc);
	Actor healthCareProfessional = matchHealthCareProfessional(sc);
 	Actor executiveHealthCareProfessional = matchExecutiveHealthCareProfessional(sc);
 	Actor healthCareProfessionalOnBehalfOfDoctor = matchHealthCareProfessionalOnBehalfOfDoctor(sc);
	Actor trustedSystemUser = matchTrustedSystemUser(sc);

	Actor actor = checkExactlyOneActorHasBeenDetemined(doctor, nurse, nurseOnBehalfOf, executiveHealthCareProfessional, healthCareProfessionalOnBehalfOfDoctor, trustedSystemUser);
	return actor;
}

private checkExactlyOneActorHasBeenDetemined(Actor determined...) throws SecurityException {
	// Tjekker, at der er præcist een ellers smides exception
}

private Actor matchHealthCareProfessional(SecurityContext sc) {

	// Tjekker om nødvendige bruger og organisation findes. Der må ikke være en på-vegne-af-bruger i for denne aktør
	if (!securityContext.getActingUser().isPresent() || securityContext.getResponsibleUser().isPresent() || !securityContext.getOrganisation().isPresent()) {
		return null;
	}
}

TODO kode eksempel fra DDS (måske pseudokode for at hjælpe)?

...