As far as I know, in order to use UserName credentials with basicHttpBinding to authenticate against the SQL Server membership provider, I need to set TransportWithMessageCredentials security mode. But recently I had a look at the WCF Security guide. And in this book I found the similar example, but instead of TransportWithMessageCredentials, Basic mode is used and a custom HTTP module is created that will authenticate users.
I'm wondering which approach is worth using?
Both approaches do the same but they use different approach. The first approach uses SOAP header to pass credentials whereas second approach uses HTTP header to pass credentials.
The second approach involves additional network roundtrip (handled internally by WCF) because first call is rejected with 401 status code and demanded Basic authentication and only second call contains the header with credentials. This is the way how HTTP authentication works and client should not send credentials until server requires them (even there is possibility to preauthenticate but I think WCF doesn't use it). The second approach cannot be used with streamed transfer mode.
There can be one additional difference between those two methods. The first approach authenticate each call whereas second approach authenticate connection so if you call the service multiple times from the same proxy (and the same connection) you will be authenticated only once with the second approach but for each call with the first approach.
Edit:
There is no preference between those two. You will use the one which is more suitable for your needs. If you have control over both client and server or if you know that client will use some more powerful SOAP stack the first one is easier to set up. If you don't have control over your clients and they can use different platforms you can find second more interoperable.
As a side note the first one works only with SOAP protocol whereas the second one works for SOAP, POX and REST (POX and REST require different binding).
Related
I have an application that will be consuming several REST APIs by a number of third parties and I am tossing up between using HttpClient and ServiceStack.Client to consume them.
I'd love to stay unified and use ServiceStack.Client, but I'm not sure if it's targeted more to support the patterns & practices of a ServiceStack REST API or whether it is flexible enough to be used to consume any arbitrary HTTP REST API.
Specifically, the APIs I am consuming have their own custom authentication methods (not basic or digest etc) and require the client to accept cookies. Is ServiceStack.Client appropriate to use in these scenarios?
Following on from what #mythz said, I ended up using the ServiceStack HTTP Utils library.
To handle cookies and custom authentication requirements, I hooked the 'requestFilter' parameter that is available in most of the extension methods, to manipulate the post's header prior to it being sent. It's just a simple Action.
It's covered my needs quite well and been quite elegant.
I am trying to implement OAuth in a web service such as:
http://www.codeproject.com/Tips/372422/Secure-WCF-RESTful-service-using-OAUTH
Each time, when the Authenticate method is fire, WebOperationContext.Current.IncomingRequest exists, but UriTemplateMatch is null. This is even the case when using the WCF Test Client, so my client app isn't the problem. Ultimately, I need to access the QueryParameters under UriTemplateMatch.
In the Authenticate method, this is where the code breaks:
NameValueCollection pa = context.UriTemplateMatch.QueryParameters;
Looking for a different solution than this so everything is processed in one request:
https://stackoverflow.com/questions/7344478/using-the-wcf-http-web-api-uritemplatematch-is-always-null
Also, just as much as a solution, I am looking for a reason why the UriTemplateMatch would be null only in the case of a WCF Service. There are hundreds of articles on the presence of this problem, but I haven't found a good solution and/or explanation. I think I may be missing something in my web.config.
It seems that this solution is expecting incoming calls like :
http://localhost:49262/TestProject/Service.svc/user/123?oauth_consumer_key=key&oauth_nonce=10a33ed37b549301644b23b93fc1f1c5&oauth_signature=cUobFDxVB5wjPe9X2XICJ6awmnE%3D&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1289976718&oauth_version=1.0
There are two ways to attach oauth parameters, one is through headers, another is through query string, both are valid, so I choose to attach oauth parameters in query string. There is not any problem to retrieve them from IncomingWebRequestContext.Headers if those oauth parameters are in headers
This solution is not from me. Check this link.
So bear with me, i am new at MVC and WCF. I already have a set of services (WCF) that exposes my BLL and I am trying to consume those from my MVC.net web application but i am unsure on how to perform security operations here.
These are my app requirements:
Be able to consume WCF services using different credentials for every user on the web application
My BLL (WCF) needs to know what consumer is calling it (right now I only have the MVC app but i am planning to add iOS and Andriod calls to it, so later on i will add REST services to the WCF endpoints) Is there any design pattern for this out there? (or should i just use the soap header to include the caller ID? should i use some sort of caller secret or something?)
I need a security mechanism like Tokens or something so I dont have to pass the username and password on every call of the service method (WCF)
What i have so far:
WCF uses a certificate and and with a custom username validator.
I have manually coded proxies using the contract interfaces instead of generated proxies: But I hate the fact that i have to validate username and password every time a call is made to a WCF service. How in heaven can i use Tokens here? like to know if a given token sent on the soap header is valid or not yet expired? i have searched a lot and no tutorial/code/example is clear enough for me to actually start coding that ;(
I am trying to cache the ChannelFactory but should I? i mean, i will need to cache a channer factory per logged in user per contract ;( is that ok? what can i do here?
Thanks in advance!
Should you cache the ChannelFactory per user per contract?
It depends. There are a couple of considerations. Instantiating a channel factory could take up to 70ms. If you are doing this repeatedly, you will see a noticeable performance hit if you are not caching the ChannelFactory and instantiating one (or more) each time a user makes a http request to your MVC app that results in controller actions calling web services. This would indicate that caching the channelFactory would be beneficial for speed.
On the other hand, depending on the number of users you have, if you are caching a lot of channel factories (in a static dictionary for example), you are going to start to use a non-trivial amount of memory - this may become an issue for you.
You have to decide if the cost of instantiating channel factories on the fly (and correctly closing / aborting them and their contained channels) is too high a price vs increasing memory utilisation in the application pool hosting your MVC app.
Either way, I strongly advise to profile your app before you deploy to production.
I'm building a WCF SOAP service at the moment. I will, of course, need some authentication on the service.
Reading this very helpful blog post says that to use the built-in authentication points requires that the endpoint use the wsHttp binding.
This would be fine if I could guarantee that users would be communicating with the service through a client based on the meta-data exposed by WCF (basically, something like a client written in C# with a web service reference). However, I can't guarantee this!
I will still need to allow users to communicate with just raw (unencrypted) XML.
So, questions:
Does the wsHttp binding still allow for raw XML input?
If not, would I be wiser to
Implement two separate authetication points? One for raw XML input and one for encrypted input
Or
Allow input from wsHttp to fall back on some in-method validation that would be shared with the raw XML input?
Is it wise to allow users to pass their credentials inside a raw XML request?
EDIT: It sounds like I miscommunicated or misunderstood something in my original post, so here I will clarify what I mean by "raw XML".
By raw XML, I mean just the SOAP packet and the accompanying HTTP headers - as I might send from soapUI or Fiddler. As I understand it, messages over the wsHttp binding are encrypted when a client is generated from the WSDL (for example, in C#).
If this is not the case, then how would I go about attaching the same sorts of credentials to a raw XML (for want of a better term) request as I do a request run through a client? Are they attached as HTTP headers? XML elements in the SOAP envelope?
wsHttp is a SOAP binding, which means that your content gets wrapped in a SOAP envelope, possibly with headers relating to the message and various WS-* specifications being used.
I would ask why you need to support raw XML? Most platforms today support SOAP messaging and the whole idea of SOAP is to provide interoperability between different platforms. On most platforms it is as easy to develop a SOAP client as a raw XML client. In most cases, it is simply a case of taking the WSDL and generating a client. If you want to use standard facilities like authentication and message encryption then this is a much better way to go.
There are currently no hooks to do interoperable authentication for raw XML. You will have to come up with your own mechanism to do this and it will be non-standard. For your web service users, this means it will be probably entail more development effort than if you just went with SOAP.
I created a WCF project with one simple method that returns a pdf in a byte[] and a int (id #) and has username+password with a custom validator for message security and a SSL for transport security. Now the client tells me that he was assuming I was going to create a RESTful API instead. I don't have any experience with REST, but I've seen that you can create a REST project in WCF (which is what I'd prefer for interaction with the rest of my solution).
First, can you deliver a pdf the same way in a RESTful API? I set the int as an out parameter in order to return it to the client, can I assume an out parameter will function the same as well?
Second, can I use the same kind of security setup? I'm assuming the SSL will still protect the transport, but I cannot seem to find a good example or tutorial on basic security. I can use a different method of security if needed.
REST is different than SOAP or even WCF in that you aren't using cumbersome "envelopes" unfortunately those envelopes provide you with functionality like the authentication scheme you're using (and out params, etc.)
See Best Practices for securing a REST API / web service
You can go /w basic authentication + SSL for authentication. You must encrypt basic authentication though or else it is insecure. As for the out parameter, it seems that a composite XML based result like the following is one way to go:
GET
could return XML like:
<result>
<intValue>4</intValue>
<pdfByteString><![CDATA[bytestring...etc.]]></pdfByteString>
</result>
It actually does look like WCF does have some built-in functionality to help you out, this white paper should provide a decent intro:
http://msdn.microsoft.com/en-us/library/ee391967.aspx#Y1720