We are currently designing the security of a system and planning to use claims based authorisation.
According to this wikipedia article, the SOAP binding is "SAML SOAP Binding (based on SOAP 1.1)"
In our solution we have Java, WCF and ASMX web services, some SOAP 1.1 and some 1.2.
Question is will sending a SAML 2.0 token across the various versions of SOAP and different technologies work? Does SAML require that we use SOAP 1.1?
Yes - The SAML SOAP binding (at least for Web SSO Profile) requires SOAP 1.1 for conformance. Section 3.2.2 "Protocol-Independent Aspects of the SAML SOAP Binding" of the SAML 2.0 Bindings doc notes: "Note this binding only supports the use of SOAP 1.1."
While you can try using newer versions of SOAP, there is no guarantee that you'll be interoperable with other 3rd Party implementations.
--Ian
What is the use case you are going to implement..? In most of the cases you can avoid "SAML SOAP Binding" and use WS-Trust with SAML Token Profile 1.1 - which supports claim based authorization - it does not depend on SOAP version...
Related
I have a web service to consume in BizTalk which exposes both SOAP 1.1 and 1.2 endpoints and is secured with Basic Http Authentication.
I'm using the WCF-Custom adapter and trying to use SOAP 1.2.
This comparison table shows that I cannot have the combination of basic Http authentication AND SOAP 1.2 and I'll have to use 1.1 and basicHttpBinding
Will any of the other WS-* bindings allow me to do what I want? I would prefer to use SOAP 1.2 because it will, presumably*, be around longer than 1.1.
*may be misguided?
Yes, I believe you are misguided.
What that table and article is saying is that the WCF protocal wants to send the credentials securely either by having a secure transport or encrypting the message payload.
You can use basic authentication with WCF-Custom and Basic Authentication.
Set the Binding type to wsHttpBinding, under WSHttpBidingElement, Security, Transport, set the clientCredentialType to Basic.
i read about 2 WS* protocols , WS-TRUST and WS-FED. but i am confused about real time scenario how to use these protocols . can anyone let me know in which scenarios i can use WS-TRUST and WS-FED ? it would be very helpful if someone can tell which is best among these 2 protocols for securing a REST service and a normal.ASPX page.
WS-Federation is for web applications (e.g. ASP.NET WebForms or MVC)
WS-Trust is for SOAP-based web services (e.g. WCF)
for HTTP services you have to look into OAuth2.
I am on a WCF project that is going to be interfacing with WebSphere.
They have told me that they will create a WSDL for me to call from my WCF solution.
I know ZERO about WebSphere. So I am asking if the term WSDL is universal. Or is it kind of like "SQL" (meaning the basics are the same, but an Oracle/WebSphere query/call may not run on SQL Server/WCF).
Has anyone tried this? Are there hidden "gotchas"?
From a purely semantic perspective both WCF WSDL's and JAX-RPC (Websphere) WSDL's are compliant with both SOAP 1.1 and SOAP 1.2. However they both tend to have some slight variations in out of the box endpoint generation, wsdl location to endpoint mapping external references location, soap:action generation and WS-* compliance that could present you issues.
IBM mentions the following as a common issue when integrating WCF generated WSDL's with their products which are based on JAX-RPC
Note: Web services allow applications to interoperate by using standard descriptions of services and standard formats for the messages they exchange. For example, the Web service import and export bindings can interoperate with services that are implemented using Web Services Enhancements (WSE) Version 3.5 and Windows Communication Foundation (WCF) Version 3.5 for Microsoft .NET. When interoperating with such services, you must ensure that:
The Web Services Description Language (WSDL) file that is used to access a Web service export includes a non-empty SOAP action value for each operation in the interface.
The Web service client sets either the SOAPAction header or the wsa:Action header when sending messages to a Web service export.
I have the following criteria to help me pick a WCF Http binding. My services need to:
be deployed in an intranet support impersonation/delegation
be interoperable with clients using unknown technology
support transaction flow between client and servers
not use certificates if possible (discards "Transport" security mode)
We need to decide between basicHttpBinding and wsHttpBinding.
Here are a few notes and questions on the three points:
I believe wsHttpBinding with "Message" security mode and "Windows" clientCredentialType would allow me to perform delegation.
The security configuration selected in point 1. to implement delegation does seem to make interoperability complex to support, am I right? The WS-* standards (wsHttpBinding) are definitely interoperable, but combined with "Message" security and "Windows" credential, could any WS-* compatible client invoke my services?
I believe wsHttpBinding seems the way to go here to support transaction flow?
Using "Message" security without certificates seems simpler in our situation?
Thanks in advance
If you want to support transaction flow, you need to use the wsHttpBinding. basicHttpBinding is really just that, a basic XML web service. MS claims it supports the WS-I Basic Profile v1.1 but it looks more like v1.2 since you can use MTOM with that binding.
Both are highly interoperable: wsHttpBinding is an implementation of numerous WS-* standards; what it doesn't support are older SOAP-only clients. That includes anyone using a .NET 2.0 style web service reference, and many forms of Java-based SOAP proxy.
With security, you start to get more of the benefits of a wsHttpBinding showing up. The basicHttpBinding cannot do Windows credentials, though, as you noted, that will limit your interoperability. I suspect you will find it very difficult to authentication non-Windows clients using Windows credentials, but as you indicated, that's the only way to get impersonation to happen. For non-WCF clients running on Windows, you may have more luck, since the client could still get access to the logged-in user's authentication token.
The best way to see how your security modes are going to affect non-WCF clients is to publish the bindings for your service and run the Java wsimport tool against them; if that can produce a working proxy from your WSDL then you should be able to use the service from any client.
As the name states... right now I'm using BasicHttpBinding, but I'm wondering if I can switch to WSHttpBinding and still be interoperable with, for example, Java.
wsHttpBinding and the newer ws2007HttpBinding both implement WS-* standards. You may have to configure the details so that they interoperate with your specific clients.
WSHttpBinding offers a lot of interoperable features but in the same time it by default uses message security with Windows authentication, service credentials negotiation over SPNego protocol and security context (WS-SecureConversation). Windows authentication and SPNego are not good candidates for interoperability and secure conversation doesn't have to be provided by older SOAP stacks.
So the answer is "it depends". You usually have to configure WSHttpBinding to be interoperable with Java. Moreover you don't have "full" control over used protocols (especially for security part) so sometimes you will use custom binding for interoperability.