Page History
...
Brugertyper og adgangsscenarier
TODO Eva: omkriv Omskriv i forbindelse med SDS-5198)
DDS Registry understøtter en række brugertype og adgangsscenarier. Disse brugertyper stille forskellige krav til autentifikations- og kaldkontekst. Derudover er anvendelsen af de eksterne services (samtykke, behandlingsrelation, minlog) forskellig for de forskellige adgangsscenarier.
...
Generel struktur af invoker
TODO Eva
Fælles for de service-invokere, der er beskrevet i foregående afsnit er at de hver især har ansvar for:
- at indhente krævede konfigurationsparametre (fx URL for kaldte service)
- at etablere og om nødvendigt genetablere kontakt til servicen
- at gennemføre kald af den eller de operationer
- at håndtere og indkapsle alle fejl
Der er overordnet to typer af invokers: Dem med og dem uden DGWS sikkerhed.
Invoker med
...
anvendelse af DGWS
Registry:
Når der laves kald af ConsentVerificationServiceInvoker , MinLogRegistrationInvoker og TreatmentRelationInvoker genanvendes det indkommende ID-kort anvendt ved dokumentanvenders kald af DDS. Der skabes en kopi af indkommende Medcom-header, dog med nyt MessageId.
Ved kald til samtykkeverifikationsservicen, der i tilgift forventer en HSUID-header, genbruges HSUID-headeren fra DDS Registry-opslaget.
Repository:
For ConsentVerificationServiceInvoker, MinLogRegistrationInvoker og TreatmentRelationInvoker anvendes serviceklienter, der arver fra SosiService. Derved får de ved instantiering automatisk en DGWSConsumer-instans og altså også cached ID-kort-håndtering. Når der laves kald af disse services bliver et ID-kort, der stadig er gyldigt, genbrugt fra tidligere kald, og om nødvendigt bliver nyt ID-kort indhentet automatisk fra STS.
Ved de tre invokere’s kald af operationer på hhv. samtykkeverifikationsservicen, MinLogRegistration-servicen og behandlingsrelationsservicen benyttes DGWSConsumer til at skabe de nødvendige DGWS-headere (Medcom- og sikkerhedsheader).
Ved kald til hhv. samtykkeverifikationsservicen og MinLogRegistration-servicen, der begge i tilgift forventer en HSUID-header, genbruges HSUID-headeren modtaget med kaldet af DDS Repository.
Invoker uden DGWSConsumer eller STS-anvendelse
skal det foregå med et SOSI Idkort. Det er DDS's ansvar at anskaffe et system idkort således, at dette kald kan gennemføres.
Der er lavet generel håndtering af disse system idkort herunder caching.
Der er også tilfælde, hvor backends for enten DDS Registry eller DDS Repository forventer at få akkreditiver med i kaldet. Her er det som udgangspunkt den samme sikkerhedsbillet, som blev anvendt til DDS selv, der delegeres videre til den modtagende backend. Hvis DDS Registry eller DDS Repository bliver kaldt med en IDWS billet er videre delegering ikke muligt p.g.a Holder-of-key constraint. I dette tilfælde vil DDSens eget system idkort anvendes, som beskrevet ovenfor for kald til MInSpærring og BRS.
Invoker uden anvendelse af DGWS
Der er backends for både DDS Registry og DDS Repository, der ikke foreventer en sikkerhedsbillet. NXRG er et eksempel på dette. Til dette formål anvendes en serviceinvoker uden DGWSDocumentRegistryInvoker henholdsvis DocumentRetrieveInvoker er specielle derved, at IHE Registry ikke overholder DGWS og derfor ikke kræver ID-kort indhentet fra STS for at kunne kaldes.
ConsentOverrideLoggingInvoker foretager blot logning lokalt og kalder ikke nogen service.
...