RE: [cmis] Looking for additional information around CMIS conformant aut

Thanks Craig this is great information in your sample! I highly appreciate publications like this. I talked with a developer here today and if I understood correctly you provide an extra DLL to be able to control the header information. What we have investigated so far is it that it seems to get out-of-the box interoperability (Java/.Net) only between .Net 3.5 and the Metro stack on Java. This is really disappointing. I fear that neither .Net 3.5 is an option for many products out there nor is Metro an option for us at the moment. So we are currently looking what the best way is to integrate as much interoperability as possible with our existing JAX-WS stack. The main issue with Metro is that you get a whole bunch of other protocols in addition to the basic authentication. This means a totally different WSDL compared to what we have today and lot of questions around backwards compatibility with our existing clients.

I think it makes sense to collect the various SOAP headers as they are used today within our repositories so that we have a clue what we can expect at the PlugFest. I start with the .Net 3.5 one that is used if you import the WSDL from a Metro web service. This is probably the long term goal for interoperability.

// CalculatorWS Metro 1.4 + MS WCF(.Net3.5) generated code

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

<s:Header>

<o:Security s:mustUnderstand="1"

xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

<u:Timestamp u:Id="_0">

<u:Created>2009-02-13T08:08:01.268Z</u:Created>

<u:Expires>2009-02-13T08:13:01.268Z</u:Expires>

</u:Timestamp>

<o:UsernameToken u:Id="uuid-15dc2b6a-e1a9-469a-8182-39f55e3a6ad2-1">

<o:Username>mike</o:Username>

<o:Password o:Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">

mikepasswd

</o:Password>

</o:UsernameToken>

</o:Security>

</s:Header>

<s:Body>

</s:Body></

s:Envelope>

If you don't mind we should publish the header from your sample code as well Craig…

I will post the OpenText one when we have implemented something. I also encourage others to post theirs.

We can decide later if we want to recommend one or a subset of those to be understood/generated on CMIS client and/or server side.

Jens

From: Randall_Craig@emc.com [mailto:Randall_Craig@emc.com]
Sent: Dienstag, 10. Februar 2009 17:54
To: Jens Hübel; cmis@lists.oasis-open.org
Subject: RE: [cmis] Looking for additional information around CMIS conformant authentication

Jens-

You’re welcome to check out my posts about accessing CMIS from WCF, which include source code: http://craigrandall.net/archives/2009/01/consuming-cmis-wsdl-in-visual-studio/.

At the tail end of this post, I state “implicit SOAP headers in a contract require extra coding on the part of a consumer.”

Anyway, download my sample and read its README file and the code. It explains, I believe, the very condition you’ve encountered.

Regards,

-Craig

From: Jens Hübel [mailto:jhuebel@opentext.com]
Sent: Tuesday, February 10, 2009 12:47 AM
To: cmis@lists.oasis-open.org
Subject: [cmis] Looking for additional information around CMIS conformant authentication

Hi all,

we are currently investigating how to add support WS-Security 1.1 to our CMIS implementation. To test interoperability Java-.Net we are trying to build a sample (Hello World like) client to authenticate against server. It seems that in the WCF configuration in .Net you can set a whole bunch of various options and parameters in the behaviors and bindings sections. Currently we are facing the problem that the .Net client always generates some information that the server does not understand (causing exceptions etc.). Well this problem is just our implementation issue and probably the spec in this regard is accurate and precise enough. However I wonder if we could make life easier (having the PlugFest in mind) from a practical perspective if:

a) someone has already tested this and could provide a sample configuration file that works at least in one repository

b) we should agree to support at least one common configuration (again not as part of the spec but just for practical reasons at the plugfest) for .Net and Java

c) we have a common place to share such things that are not directly spec related but are just tools, guidelines, best practices that make life easier for all us

I remember that multiple vendors ran into the authentication issue the last time. I assume that MTOM would be another candidate for such kind of additional information. So perhaps we can make some preparations to be as good as possible prepared for the next tests. Comments if you see any value in this would be welcome.

Thanks Jens

P.S. I am not 100% sure if this mailing list is the right place to ask questions like this. If there is any better place for questions not directly related to the work on the spec please let me know.

cmis message