Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

...

Fra version 3 er Seal.java splittet op i moduler for at give mulighed for kun at hente den dokumentation man har brug for. Dermed  kan man undgå at hente den del af koden, som er beregnet til STS.

Følgende moduler er oprettet:

  • seal-common.java
  • seal-dgws-common.java
  • seal-dgws-exchange.java
  • seal-idws-common.java
  • seal-idws-exchange.java
  • seal-exchange-common.java
  • seal-sts.java

Objekt Hierarkiet

DGWS

...

De centrale POJO'er i forbindelse med Idkort (DGWS) udgør et simpelt objekthierarki som vist nedenfor i nedenstående figur.

...

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)

Gliffy Diagram
size1200
nameidws pojo seal
pagePin6

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.

Gliffy Diagram
size1200
namebst2sosi pojo seal
pagePin1

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.

...

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 et offentlig-privat nøglepar.
CredentialVault overføres til SOSIFactory på byggetid.

...

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.

...

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

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

...

  • 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 spærringskontrol af certifikater bruges, så kan det være nødvendigt med en ekstern kryptoudbyder, der understøtter “X.509”.

...

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.

...