I noticed that Olive has a native WS-Trust STS implementation and thought I'd have a go compiling it and installing it. Compilation and installation seem to work as expected, unfortunately, I've had little luck actually running the STS.
Unhandled Exception: System.Net.HttpListenerException: There's another listener for http://localhost:9091/ at System.Net.EndPointListener.AddPrefix (System.Net.ListenerPrefix prefix, System.Net.HttpListener listener) [0x00000] at System.Net.EndPointManager.AddPrefixInternal (System.String p, System.Net.HttpListener listener) [0x00000] at System.Net.EndPointManager.AddListener (System.Net.HttpListener listener) [0x00000]
I've tried this on Mac OS X 10.4.10 (PPC, Intel) with Mono Framework 1.2.4 release (Universal). Am I missing anything obvious here? I'm very new to Mono, so I'm not sure how to interpret where I should look to try and debug this exception - no line numbers, for example.
If Olive has enough support for WS-Addressing, WS-Security and WS- Trust, then it would be an ideal alternative to something like gSOAP as a web service client framework on *NIX systems.
The cause of the problem is simple: you are trying something unfinished.
WCF work is unlikely restarted until we release some versions of mono which is to support missing .NET 2.0 profile stuff (I mean, I'll be primarily working on those areas, not WCF).
> I noticed that Olive has a native WS-Trust STS implementation and > thought I'd have a go compiling it and installing it. Compilation and > installation seem to work as expected, unfortunately, I've had little > luck actually running the STS.
> Unhandled Exception: System.Net.HttpListenerException: There's another > listener for http://localhost:9091/ > at System.Net.EndPointListener.AddPrefix (System.Net.ListenerPrefix > prefix, System.Net.HttpListener listener) [0x00000] > at System.Net.EndPointManager.AddPrefixInternal (System.String p, > System.Net.HttpListener listener) [0x00000] > at System.Net.EndPointManager.AddListener (System.Net.HttpListener > listener) [0x00000]
> I've tried this on Mac OS X 10.4.10 (PPC, Intel) with Mono Framework > 1.2.4 release (Universal). Am I missing anything obvious here? I'm > very new to Mono, so I'm not sure how to interpret where I should look > to try and debug this exception - no line numbers, for example.
> If Olive has enough support for WS-Addressing, WS-Security and WS- > Trust, then it would be an ideal alternative to something like gSOAP > as a web service client framework on *NIX systems.
On Jun 26, 2:06 am, Atsushi Eno <atsu...@ximian.com> wrote:
> Hi,
> The cause of the problem is simple: you are trying something > unfinished.
Ah, well, I can't have everything!
> WCF work is unlikely restarted until we release some versions > of mono which is to support missing .NET 2.0 profile stuff > (I mean, I'll be primarily working on those areas, not WCF).
OK, that sounds reasonable. Maybe I've been concentrating too much on server-side components. What I really need is a C# client running in Mono (with or without Olive) that can talk WS-Security. WS-Addressing is highly desirable, but all this means is sticking a WS-Addressing header in a SOAP message.
Would it be possible to point me toward some existing code in Olive or Mono that I can build upon? I noticed in the Olive status/status.txt file it mentions that a large percentage of WS-Security has been implemented, so it sounds like Olive is something I can work with.
>> WCF work is unlikely restarted until we release some versions >> of mono which is to support missing .NET 2.0 profile stuff >> (I mean, I'll be primarily working on those areas, not WCF).
> OK, that sounds reasonable. Maybe I've been concentrating too much on > server-side components. What I really need is a C# client running in > Mono (with or without Olive) that can talk WS-Security. WS-Addressing > is highly desirable, but all this means is sticking a WS-Addressing > header in a SOAP message.
> Would it be possible to point me toward some existing code in Olive or > Mono that I can build upon? I noticed in the Olive status/status.txt > file it mentions that a large percentage of WS-Security has been > implemented, so it sounds like Olive is something I can work with.
Actually there are some sample sets of clietn and server that uses WS-Security stuff (olive/samples/services/secure-messages dir). As far as I remember, sample 1 to 9 will work, and later won't.
However it is somewhat low-level samples that mostly do not create WSHttpBinding but creates couple of CustomBinding with my own SecurityBindingElements. So, if you want to use them, it will be harder than you'd do with .NET WCF.
Besides, WS-Trust is not done. I remember that I've got stuck with wst:Authenticator (AUTH-HASH) miscalculation with either of SslSecurityTokenParameters and SspiSecurityTokenParameters. So, there is no secure WST requests/responses, which often does not make sense.
Having said that, WS-Security without Trust may work for you. But if you'd found issues, I don't think I have time to fix them.
> Actually there are some sample sets of clietn and server that > uses WS-Security stuff (olive/samples/services/secure-messages dir). > As far as I remember, sample 1 to 9 will work, and later won't.
Thanks for the pointer - I'll have a look at those first.
> However it is somewhat low-level samples that mostly do not create > WSHttpBinding but creates couple of CustomBinding with my own > SecurityBindingElements. So, if you want to use them, it will be > harder than you'd do with .NET WCF.
Not to worry, we all have to start somewhere, even if it is low level.
> Besides, WS-Trust is not done. I remember that I've got stuck with > wst:Authenticator (AUTH-HASH) miscalculation with either of > SslSecurityTokenParameters and SspiSecurityTokenParameters. So, > there is no secure WST requests/responses, which often does not > make sense.
Hmm, this could be more challenging. My aim here is to have an Olive/ WCF client perform a WS-Trust issuance request (SAML) to a Java-based STS. The requested SAML token would then be placed in the WS-Security header of a new message (same client) to a target service, also Java- based. All in the name of cross-platform, cross-framework interoperability! I'll have to take another look at how WCF does all this - my experience so far has been with WSE 3.0, but WCF is becoming increasingly important.
> Having said that, WS-Security without Trust may work for you. But > if you'd found issues, I don't think I have time to fix them.
WS-Security is a necessity, especially for interop. WS-Trust is a bonus - as I've already mentioned, I only want a WS-Trust client - the issuance and validation is done by an existing Java-based infrastructure. I appreciate the information and pointers that you have provided.
