Using SAML2 Tokens with WCF channelfactory and Weblogic services

Question

Help! :) I'm having no end of problems trying to get the following working(apologies in advance if I'm not using the exact correct terminology) :)

I need to get a .NET web application (client) communicating with Weblogic web services secured with SAML 2 policies. There are restrictions in that I need to use .NET 3.5/4 and as such am using WIF (with the extensions) to work with ADFS2 configured to generate SAML2 tokens.

The website -> adfs2 -> SAML2 token bit is working fine so far - I definitely getting tokens through.

Additional(1) - the Weblogic services have to use SAML2 policies that implement a sender-vouches confirmation method and although ADFS 2 supplies bearer by default, I am able to manipulate the SAML assertion before we send the token across the wires to the service(s).

Additional(2) - For numerous reasons, the webservices are not reached over SSL and basicHTTPBinding is my only option.

Now the problem.. I just can't communicate with Weblogic in such a way as to send the token in the request (any logged attempt returns an oracle "General Web Service Security Error" due to there being no valid security header in the request). The preferred approach would be via WCF, using a channel factory - the code below is a rough example of what I've tried - the claimsidentity/token stuff was taken from the code sample that came with the WIF extension stuff:

IClaimsIdentity identity = Thread.CurrentPrincipal.Identity as IClaimsIdentity;
Saml2SecurityToken token = identity.BootstrapToken as Saml2SecurityToken;

BasicHttpBinding binding = new BasicHttpBinding();
binding.Security.Mode = BasicHttpSecurityMode.None;
binding.Security.Transport.ClientCredentialType = HttpClientCredntialType.None;

EndpointAddress address = new EndpointAddress("http://someaddress");

ChannelFactory<weblogicService.MyService> factory = new ChannelFactory<weblogicService.MyService>(binding,address);

factory.ConfigureChannelFactory<weblogicService.MyService>();
factory.Credentials.SupportInteractive = false;
weblogicService.MyService proxy = factory.CreateChannelWithIssuedToken<weblogicService.MyService>(token)
proxy.DoSomething();

The answer at the following post (and everywhere else I've been able to find): WCF and WebLogic SAML interop

..is exactly what I'm doing - but whether viewing the traffic with WireShark OR by implementing a customer MessageInspector and looking at the request in "BeforeSendRequest", I can't see any sign of the token (and the request is rejected as a consequence).

Also it doesn't matter if I manipulate the token to include sender-vouches or just leave it as it is originally.

Additional (3): I have been able to successfully communicate with the Weblogic service if I don't use ADFS2/SAML/WIF/WCF etc. but instead, go via a more basic WSE2.0/3.0 web references approach (i.e. creating SoapRequest, UserName token etc..)

The problem with that, is in supplying a valid username and password without user interaction. In other words, keeping a "SSO approach", and not have to implement Forms Authentication (or equivalent) to get the user credentials each time.. There doesn't appear to be any obvious way of using the SecurityToken generated by ADFS with WSE either..

Can anyone help shed some light? Why the WCF channel factory approach with a supplied token is simply not working i.e. no sign of a valid token when debugging and certainly no valid SAML token being received by Weblogic.

I have also looked at going the CustomMessageEncoder route, and adding the SAML Assertion into the SOAP header that way.. but from what I have been able to find out, it really shouldn't be this difficult. Is something in WCF broken?

Answer 1

End point binding limitations (basicHTTP) doesn't support SAML2 afaik, also ADFS2.0 only seems to supply bearer tokens and modifying the token after the fact is also non starter (the suggested overrides in WIF to do this don't seem to work as expected) and finally because the web services aren't behind https, having a security mode of none (which is the only one that could be used) meant no token was being sent anyway.. ahh well, back to the drawing board!