Tijdens de bijeenkomst van 11 november 2014 is gesproken over security tijdens documentcreatie. De kernvraag is: hoe weet de DCA dat de DCV ook daadwerkelijk de DCV is die hij beweert te zijn?
Er zijn verschillende mogelijkheden zoals gebruik van SSL of WS-security. Beide mogelijkheden worden nu gebruikt maar zijn niet interoperabel. Er moet dus een keuze gemaakt worden.
De keuze is gevallen op WS-Security UsernameTokenprofile 1.1, zie voor de specificaties hiervan http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-UsernameTokenProfile.pdf
Om elkaar te helpen bij het implementeren ervan willen we in dit onderwerp code snippets en voorbeelden verzamelen van het gebruik van WS-Security UsernameTokenprofile 1.1 bij systemen die de standaard implementeren. In principe geldt dit voor alle programmeertalen gebruikt bij de systemen die de standaard zullen implementeren. Op basis van de ondertekende addenda zouden dat in ieder geval de volgende programmeertalen/-omgevingen zijn:
- .NET bindings
- Java
- PHP
Andere relevante voorbeelden zijn natuurlijk ook welkom!
Tijdens afgelopen bijeenkomst van 25 maart is dit onderwerp nogmaals ter sprake gebracht. Naar voren is gebracht dat beide versies (WS-I en SSL) ondersteund zouden moeten worden en gemeenten een keuze kan maken).
Graag reactie op bovenstaand voorstel. Op de teleconferentie van 28 mei 2015 zal dit besproken en besloten worden.
Bij deze nog deze verduidelijking:
Een DCV zal met een DCA moeten kunnen communiceren met ondersteuning van:
1. Standaard (unsecure) SOAP 1.1 via HTTP en MTOM, zoals beschreven in stuf.bindingen.030100.pdf.
2. Two-Way SSL, SOAP 1.1 via HTTP en MTOM, op basis van certificates.
3. WS-Security UsernameTokenprofile 1.1, SOAP 1.2 via HTTP en MTOM.
Aangezien WS-Security geen streaming toelaat omdat hierbij een compleet gebufferde bericht moet worden gebruikt om message encryption te kunnen uitvoeren, is het onze voorkeur om optie 2 (transport encryption) als default/best-practice te benoemen als beveiligings protocol binnen dit koppelvlak.
Ik dacht dat we optie 3 hadden afgesproken in verband met de overeenkomst met CMIS. Ik zie wel dat een bezwaar, maar waarom zouden we optie 3 dan überhaupt nog in de DCR-standaard blijven ondersteunen als die technisch niet even werkbaar is als de andere? En waarom werkt optie 3 voor CMIS wel, maar voor dit niet? Wellicht schiet mijn kennis hier tekort? :-)
Hallo Joost, voor zover ik weet specificeert CMIS alleen 'WS-Security UsernameToken', zonder versie specificatie. In de praktijk (Alfresco) wordt hiervoor de plain-text variant gebruikt, dus worden credentials zonder encryptie gecommuniceert waarbij iedereen ze kan zien. Het lukt me via DotNet op deze manier met Alfresco te communiceren hoewel dit niet standaard ondersteund wordt door Microsoft (moet met custom binding). Ik denk door gebruik van WS-Security UsernameToken 1.0, waardoor het bericht zelf niet geencrypt hoeft te worden. Ik merk dat Microsoft dat voor WS-Security UsernameTokenprofile 1.1 het gewoon niet toestaat dit als plain text te versturen, maar weet niet genoeg van de hoed en de rand van deze protocollen om te weten of dat een keuze is van Microsoft of de standaard zelf.
CMIS staat zelf toe ook andere protocollen te gebruiken, zie http://chemistry.apache.org/opencmis-client-bindings.html, kopje 'Custom Authentication Provider', dus we zijn nergens aan gebonden.
Omdat we onlangs beloten hebben de gebruiker binnen het CMIS bericht te versturen, en niet via de SOAP header (UsernameToken), kunnen we nu optie 3 inderdaad laten vervallen. Dit heeft zeker onze voorkeur!
Zie http://docs.oasis-open.org/cmis/CMIS/v1.0/cd04/cmis-spec-v1.0.html#_Toc2... voor CMIS specificatie dat WS Security Username Token niet verplicht is.
In diezelfde link is te zien dat de CMIS 1.0 specificaties vereisen dat:
Dit betekent volgens mij voor CMIS binnen de Zaak- Documentservices dat weliswaar ook andere protocollen toegestaan zijn maar dat WS-I Basic Profile 1.1 en Basic Security Profile 1.0 in ieder geval verplicht zijn voor de DMS component.