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 signaturer.
Denne form for kompleks logik er indkapslet bag elementer fra biblioteket.

Objekt Hierarkiet

DGWS

De centrale POJO'er i forbindelse med Idkort (DGWS) 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.

BST2IDWS

Ligesom i DGWS tilfældet, så findes der i SEAL klasser til omveksling fra boostraptokens til IDWS tokens (borgere)

Ved omveksling til IDWS tokens, findes klassen OIOSAMLFactory, som både benyttes i forbindelse med at lave et BST2IDWS request og det indlejrede bootstraptoken (en af de tre underklasser til OIOBSTSAMLAssertion), og i forbindelse med at parse response dokumentet.

BST2SOSI

Nedenfor vises klassehierarkiet for omveksling fra bootstraptokens til SOSI idkort (medarbejdere). Bemærk at Assertion klasserne til BST2SOSI indgår i samme hierarki som BST2IDWS.

Ligesom for BST2IDWS omvekslingen, benyttes OIOSAMLFactory her til oprettelse af bootstraptoken, request og response objekter.

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 et 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.

Custom vaults

Håndtering af primære nøgler er ikke angivet i biblioteket. Så enten foretages en hjemmelavet realiseringen af CredentialVault-grænsefladen, eller hvis miljøet tillader det, så kan man bruge enten FileBasedCredentialVault, RenewableFileBasedCredentialVault eller ClasspathCredentialVault, som alle leveres med biblioteket.

• FileBasedCredentialVault læser og skriver PKCS til filsystemet.
• RenewableFileBasedCredentialVault er en udvidelse af FileBasedCredentialVault, der giver brugeren mulighed for at forny VOCES-certifikater ved hjælp af en webservice.
• ClasspathCredentialVault leder efter en bestemt nøglebutik ud fra applikationens opsatte referencer for den gældende klasees.

Hvis du vælger at implementere dit eget credential  vault, skal du tage et kig på GenericCredentialVault og tilhørende sub-klasser til inspiration.
En Credential Vault kan realiseres på forskellige måder:

• At lade en database gemme de betroede certifikater og systemoplysninger.
• Inkludere de betroede certifikater og systemoplysninger i distributionen af ​​applikationen (EAR, WAR, JAR-fil).
• Indlæse credentials og certifikater en gang ved opstart (fra en hemmelig fil / bibliotek / CD) og gemme legitimationsoplysninger og certifikater i en cache.
• Hvis der køres på en applikationsserver, kan credential vault integreres i trust store og credentails  store på applikationsserveren.
• En "hardkodet" klasse, der indeholder de betroede certifikater (STS-certifikat) og systemoplysninger (primær nøgle til dette system).
  

Bemærk, at brugen af ​​CredentialVault til opbevaring af federation certifikater er blevet fravalgt til fordel for Federation-mekanismen. Det anbefales stærkt at en CredentialVault kun gemmer private certifikater og nøgler, når de bruges sammen med federation. Som nævnt tidligere inkluderer SOSI-biblioteket også EmptyCredentialVault, som bruges, når der ikke kræves en federation.

EmptyCredentialVault kaster CredentialVaultException, hvis dens metoder bliver kaldt, fordi dette betyder, at du prøver at håndtere et sikkerhedsniveau over niveau 1.

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

Certifikater og kryptosystemer

SOSI-biblioteket kræver ikke en bestemt JCE

-kryptoudbyder for at køre. Der er dog nogle krav til de anvendte kryptoudbydere:

• Kryptoudbyderen skal levere RSA-SHA1-algoritmen.
• Hvis systemoplysninger er gemt i #PKCS12-filer, skal kryptoudbyderen være i stand til # PKCS12-formatet.
• Hvis den indbyggede mekanisme til spærringskontrol af certifikater bruges, så kan det være nødvendigt med en ekstern kryptoudbyder, der understøtter “X.509”.
  

Hvis du ikke har en kryptoudbyder, der overholder disse krav, kan Bouncy Castle-kryptoudbyderen (http://www.bouncycastle.org/) bruges.

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.

...

Man kan oprette et LibertyResponse med det svar man har modtaget fra Service udbyderen og man har mulighed for manuelt at validere indholdet response.

Note: Fra version 2.5.20 og 2.6.9 placeres elementet BinarySecurityToken på Security elementet i stedet for Header. For at få den gamle opførsel, kan man sætte environment variablen NSP_USE_LEGACY_BINARY_SECURITY_TOKEN_PLACEMENT.

Brugen af IDWS funktionaliteten er vist i nedenstående sekvens diagram.

...