Links

  • 1. Sogeti
  • 2. JBoss
  • 3. IBM
  • 4. Oracle
  • 5. SpringSource
  • 6. NL-JUG
  • 7. Java

Archives

Syndication  RSS 2.0

RSS 1.0
RSS 2.0

Bookmark this site

Add 'JCN Blog' site to delicious  Add 'JCN Blog' site to technorati  Add 'JCN Blog' site to digg  Add 'JCN Blog' site to dzone

Posted by Rene de Groot at 22:08 on Monday 15 October    Add 'WS-Security: is it really that simple?' site to delicious  Add 'WS-Security: is it really that simple?' site to technorati  Add 'WS-Security: is it really that simple?' site to digg  Add 'WS-Security: is it really that simple?' site to dzone

De Web Services Security (WS-Security) sessie werd gegeven door Eelco Klaver van E.Consulting. De sessie begon met de uitleg waarom WS-Security niet vaak gebruikt wordt, maar dat het toch nodig is. Dit toonde hij met cases om af te sluiten met overdonderende XML configuratie voorbeelden om twee WS-Security frameworks te vergelijken.

De basis van beveiliging werd neergezet aan de hand van 5 doelen.

  • Authentication – Bepalen met zekerheid van wie een bericht is.
  • Confidentiality – Vertrouwelijke informatie moet beperkt toegankelijk zijn
  • Integrity – De inhoud van een bericht moet compleet en ongewijzigd zijn
  • Authorisation – Bepalen of een partij toegang mag hebben
  • Non-repudiation – Het is onweerlegbaar dat het bericht verstuurd is

De eerste 3 punten zijn grotendeels op te lossen door op transport niveau de communicatie te beveiligen. De voor de hand liggende oplossing is SSL encryptie in een two-way opzet. De authorisatie is goed in een J2EE server te implementeren. Als je de non-repudiation eis laat vieren heb je de security af. Dat is tenminste de snelle oplossing….

WS-Security is beveiliging op het niveau van het SOAP bericht. Dit levert nieuwe mogelijkheden op en neemt de nadelen van transport beveiliging weg. Een groot nadeel is dat transport beveiliging slechts tussen end-points geregeld kan worden. Op het moment dat een broker geintroduceerd wordt in het communicatie proces valt transport beveiliging door de mand. De broker is een man-in-the-middle die als security end-point functioneert. Als een client via een broker een bericht naar een achterliggend systeem stuurt kan dat achterliggend systeem niet voldoen aan authentication, confidentiality, integrity, authorisation en non-repudiation. Daarnaast is transport beveiliging alles of niets. Een compleet bericht valt onder een authentifier en is met een decryptie als geheel te lezen.

WS-Security steunt op XMLsec standaarden om SOAP berichten te signen en te encrypten. Het digitaal onderteken van berichten kan op verschillende niveaus. Zo zijn delen van een bericht te signen, een compleet bericht of meerdere berichten gezamenlijk. Dit is te gebruiken voor flexibele authentication, integrity en non-repudiation. Met encryptie van (delen van) berichten is flexibele confidentiality te bereiken. De authorisation kan dan in verschillende applicaties geregeld worden.

De afsluiting van de sessie was erg gehaast. Daar werden het XWS-Security framework voor Spring-WS getoond. De beveiliging wordt dan als interceptor ingezet op een end-point URI. Bij WSS4J in combinatie met Axis / XFire wordt de beveiliging als handler aan een end-point toegevoegd. Beide werken met XML configuraties waarbij de beveiliging wordt gespecificeerd.

De sessie toonde mij duidelijk de meerwaarde van WS-Security boven transport beveiliging. WS-Security opent veel meer mogelijkheden om de beveiliging goed in te regelen. De getoonde frameworks doen veel om de deze beveiliging makkelijk toepasbaar te maken, maar zijn zeker een stuk complexer dan een simpele SSL verbinding opzetten.


© 2020 Java Competence Network. All Rights Reserved.