Beveiligingsstandaard voor webdiensten onder druk

eWEEK meldt dat het vormen van de Web Services Security standaard (WS-Security) vertraging op aan het lopen is. WS-Security definieert een set SOAP-headers (Simple Object Access Protocol) die gebruikt kunnen worden om de integriteit van webservices mee te garanderen. Ontwikkeling van de standaard staat onder leiding van OASIS: de Organization for the Advancement of Structured Information Standards. Binnen het consortium van bedrijven en organisaties dat bezig was met de specificatie van de standaard is nu onenigheid uitgebroken over de te volgen koers. Onderwerp van het dispuut is de vraag of de standaard (voorlopig) aangenomen moet worden zoals hij nu is - met ruimte voor latere aanpassingen - of eerst geperfectioneerd moet worden. Onder andere Microsoft en Iona Technologies zijn voorstanders van een snelle aanname, maar hebben daarin onder meer IBM, Sun en Cisco tegenover zich gevonden. De tegenstanders zijn van mening dat het noodzakelijk is dat een aantal uitbreidingen eerst wordt opgenomen in de standaard:

A short list of additional features includes some form of extensions for WSDL (Web Services Description Language) that would enable developers to express how to control the level of encryption, the type of encryption and what gets encrypted. This faction is proposing a Quality of Protection working group to investigate what other additions the specification may need before being released. "We need the ability to comprehensively control Web services security as it relates to specifying a Web service at design time using WSDL and at run-time using SOAP [and] WSDL," said Zahid Ahmed, XML Web services architect at Commerce One, in Pleasanton, Calif.

Reacties (11)

[Verwijderd]

De ws-security standaard beschrijft een aantal tags en methodes om webservices te authenticeren, bijv. username/password, certificaat, en manieren om de content van de requests te encrypteren.

De encryptie die daarvoor evt. gebruikt wordt is vrij om te kiezen, als je wil mag je rot-13 gebruiken, maar md-5 etc. kunnen ook.

Het grootste probleem is op dit moment dat de enige manier om achter de ws-security eigenschappen van een webservice te komen is het te vragen aan de ontwikkelaar en er eigenlijk maar twee toolkits zijn om het makkelijk te gebruiken de microsft wsdk en een van IBM voor Java implementaties.

Persoonlijk hoop ik dat ze de spec snel uitbrengen zodat er meer toolkits komen en het makkelijker ook voor bv. soap:lite te implementeren is. De wsdl specs kunnen nog wel even wachten, voorlopig vraag ik het wel aan de bouwer van de webservice wat hij heeft gebruikt.

[edit]
huidige spec

[aTmosh]

Het grootste probleem is op dit moment dat de enige manier om achter de ws-security eigenschappen van een webservice te komen is het te vragen aan de ontwikkelaar

En juist daarom zou je moeten wachten op een echt standaard waarbij je het niet meer hoeft te vragen maar alles gewoon met elkaar zou moeten werken. Dat is namelijk wat een standaard is.

Natuurlijk is Microsoft zoals gebruikelijk voorstander van snelle introductie, dan kunnen ze door hun positie op de markt eigen uitbreidingen alvast inburgeren waardoor het moeilijker wordt om die niet meer in de standaard op te nemen later. Resultaat: M$ heeft een voorsprong als ze opgenomen worden in de standaard. Dit is al jarenlang aan de gang, het heet 'embrace and extend'.

[Verwijderd]

Maakt het zoveel uit of de wsdl je verteld wat er gebeurt of de developer? In beide gevallen moet je toch zelf de implementatie doen.

[aTmosh]

Maakt het zoveel uit of de wsdl je verteld wat er gebeurt of de developer?

Natuurlijk maakt het uit, communicatie binnen een bedrijf is vaak het kostbaarst, de developer kan ziek of off-site zijn of niet meer bij je werken waardoor een project op allerlei manieren vertraging op kan lopen, in het minste geval word je even onderbroken waardoor concentratieverlies optreedt. Dat scheelt echt een hoop, soms kan het een half uurtje extra duren voor je weer 'in the zone' bent als je gestoord wordt voor allerlei onbenullige dingen (en dat geldt net zo goed voor die developer). Of nog langer als je je aan dat feit op zich gaat ergeren.

Je zou kunnen zeggen dat dit door de communicatie te optimaliseren vermeden kan worden (of door zoiets simpels als goede documentatie), maar er zijn zoveel dingen waar dit niet voor te doen is (of omdat we nu eenmaal mensen zijn) dat het beter is het probleem bij de oorzaak op te lossen.

In beide gevallen moet je toch zelf de implementatie doen.

Mijn eigenlijke punt was dat standaarden met elkaar zouden moeten werken zodat je niet voor x verschillende scenario's opnieuw moet implementeren maar dat is wellicht dagdromerij..

[Verwijderd]

Er zijn al genoeg half zachte encryptie methodes. Ik hoop dat ze de tijd nemen om een behoorlijke standaard neer te zetten.

Je vraagt je af waarom MS zo zit te pushen. Zouden ze al iets op de plank hebben liggen? Iets .Net achtig? Snel op de markt brengen met een half af standaard? Continu naar eigen inzicht de standaard vervolgens wijzigen...omdat ze toch het grootste marktaandeel hebben. Zoiets?

Just a thought...

edit:
Gcaptain en ik tikte dit berichtje tegelijk/simultaan/parallel in hetzelfde universum. we zijn het kennelijk voor een groot deel met elkaar eens

[C7RL]

Is heel goed mogelijk dat ze al iets op de plank hebben liggen, mischien houden ze wel een dubbele agenda bij dat weet je niet. Maar zo'n nieuwe beveiliging standaard is natuurlijk weer een heel mooi sales argument voor bepaalde consumenten produkten. Daarbij inspelen op de angst van de consument en dan doet het er niet toe of het produkt perfect is. Men heeft er weer een mooie kreet bij die groot op de verpakking gezet kan worden, en wapperen met de grote namen erop die het ontwikeld hebben. In deze wereld gaat het om de pegels en dan speelt tijd een grote rol en dat is niet altijd positief!

[Marcelloz]

Aan deze splitsing zie je duidelijk dat Microsoft nog erg consumer-gericht is, terwijl IBM en SUN juist erg business driven zijn. Snel uitrollen betekent snel kunnen cachen, ookal staat het systeem nog een beetje in de kinderschoenen. Je zou kunnen zeggen dat de huidige versie een 'lite' is van wat het eigenlijk zou moeten zijn. Voor het grote publiek genoeg ( aldus Microsoft ), maar voor de echte business waarbij webservices gebruikt worden om business te integreren te licht ( aldus SUN en IBM ). Voor beide is wat te zeggen. Uiteindelijk moet iedereen zich eraan conformeren, en dan heeft Microsoft NU een sterker verhaal naar zijn klanten dan IBM en SUN, want die moeten langer wachten op de volledige standaard om geloofwaardig naar hun klanten te zijn. Niet zo gek dus dat er 2 kampen ontstaan.

Het zal uiteindelijk wel in een versie 1 en een versie 2 uitmonden, waarbij iedereen wat water bij de wijn doet.

[Verwijderd]

Het accepteren van de WS-security standaard verloopt niet zo makkelijk als werd gedacht. Waarschijnlijk zullen WS-trust, WS-policy en WS-authentication dus nog wel helemaal lang duren.
De complete security standaard voor web services is dus echt nog ver weg.

[Verwijderd]

volgens mij wordt het nog een echte soap

MS wil natuurlijk zeer vlug in zee gaan en later verbeteringen aanbrengen. Langs beide kanten kun je het positief of negatief bekijken.
Elke standaard is toch eenvoudig begonnen ... elk programma is toch begonnen met een versie 1.0 als eerste stabiele waar later dan extra functionaliteit aan toegevoegd werd.

Let's go with the current standards! Adapt to the need of the industry when the time is ready for it.

[Verwijderd]

Nadeel van SOAP is op dit moment dat 't helemaal niet zo "Simple" meer is. In de meeste gevallen, en ook hier, is XML-RPC m.i. meer dan genoeg.

De tegenstanders zijn van mening dat het noodzakelijk is dat een aantal uitbreidingen eerst wordt opgenomen in de standaard

Ik bedoel maar. Als je een standaard gebruikt die zichzelf "Simple" noemt, hou 't dan zelf ook simpel.

[4AMD]

Leuke afweging: nu een beveiligingsstandaard introduceren die misschien wel lek is of nu geen beveiligingsstandaard en eerst nog eens rustig naar lekken zoeken...

Zul je trouwens net zien dat MS het erdoordrukt en hij nu als 'klaar' wordt gepresenteerd en dan wordt er een groot lek gevonden...