Introduktion

Som det kan ses på SEAL.JAVA - Guide til anvendere siden, så er det ikke nødvendigt for udviklerne at producere XML. Udviklerne slipper også for at håndtere digests eller digitale signature.
Denne form for kompleks logik er indkapslet bag elementer fra biblioteket.

Objekt Hierarkiet

De centrale POJO'er udgør et simpelt objekthierarki som vist nedenfor i nedenstående figur.

Klassediagrammet er næsten selvforklarende. Til venstre finder du den vigtigste abstraktion af meddelelser (Anmodning/request, svar/reply osv.). SecurityTokenRequest og SecurityTokenResponse er meddelelser, der bruges til at oprette føderationsoplysninger.

Meddelelser kan have et ID-kort vedhæftet. Dette ID-kort kan enten være et system-ID-kort eller et bruger-ID-kort, afhængigt af typen af ​​service. Hvis tjenesten kræver oplysninger om en bestemt bruger for at udføre, skal ID-kortet være et UserIDCard. Et eksempel på en sådan tjeneste kan være at anmode om oplysninger om medicin til patient fra Lægemiddelstyrelsen. I dette tilfælde har tjenesteudbyderen brug for bevis for brugerens identitet.

I andre tilfælde, f.eks. når man leverer data til Lægemiddelstyrelsen i natlige batch, er det kun nødvendigt at kende systemets identitet. I dette tilfælde er et SystemIDCard tilstrækkeligt.

Bibliotekerne

Indgangspunktet for udviklerne er altid “SOSIFactory”, “IDWSHFactory”, “OIOSAMLFactory” eller "OIOIDWSFactory". Disse er beskrevet under  SEAL.JAVA - Guide til anvendere.

Herfra er det muligt at oprette nye anmodningsobjekter, svarobjekter, ID-kort, IdentityTokens osv., samt at de-serialisere XML til “kopier” af objekter fra afsendersiden.

Biblioketerne har  et  "CredentialVault” tilknyttet. CredentialVault er en simpel indkapsling af PKCS-elementer (Public Key Crypto System): et (muligvis tomt) sæt betroede X.509-certifikater og nul til en offentlig-privat nøglepar.
CredentialVault overføres til SOSIFactory på byggetid.

Vaults

Den konkrete realisering af vaults kan variere med det miljø, hvor biblioteket bruges. I et simpelt miljø kan realiseringen være en filbaseret CredentialVault, der læser en PKCS # 12-fil og pålidelige X.509-certifikater fra disk (eksempel kan findes i koden), eller en realisering baseret på en database/cache i et komplekst J2EE-miljø.

Hvis du ikke har brug for "stærke" legitimationsoplysninger (dvs. på godkendelsesniveau 1), kan du konstruere SOSIFactory med EmptyCredentialVault, som er en tom implementering af CredentialVault-grænsefladen.

Klasseforholdene er vist nedenfor.

Federations

Konfigurationen kan også suppleres med en federation, som applikationen, der bruger biblioteket, skal fungere indenfor. Denne federation er defineret i henhold til den certificeringsmyndighed, der udsteder de certifikater, der bruges i federation, og identiteten af STS.
Hvis (og kun hvis) en federation er defineret, kan biblioteket automatisk udføre spærringskontrol, når man verificerer digitale signaturer på hentede ID-kort. Biblioteket vil også være robust mod fornyelse af STS-certifikatet.

Federation er den foretrukne mekanisme til at skabe tillid (trust) inden for SOSI, og brugerne opfordres kraftigt til at gøre brug af de indbyggede federations i SOSI-biblioteket.

Se desuden eksempler i SEAL.JAVA - Guide til anvendere

IDWS funktionalitet

Der er funktioner i SEAL, som kan bruges til at opbygge de requests og response objekter der bruges, når man omveksler OIO Bootstrap token til identity token.

...