...

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.
Et Credential Vaults kan realiseres på forskellige måder:

• At lade en database gemme de betroede certifikater og systemoplysninger.
• Inkluderer 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ører 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.

...

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 soæ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.

...