I'm at the beginning of developing a new web service that will be consumed by a potentially wide variety of clients, ranging from Compact Framework apps to Java apps. I would like some guidance on securing the web service such that consumers will be able to implement the required security protocol quickly and easily.
My security needs are simple: I just need to prevent the web service methods from being called by anyone who has not been previously authorized. Since there is a prior authorization step, I can use shared secret authentication.
Many of the guidance docs from Microsoft direct me toward WSE 3.0, it's implementation of WS-Security. I believe that WSE 3.0 is not an option for me because it is unsupported by the Compact Framework (CF). It seems that the best I can do on the CF is to use OpenNetCF's 2.0 beta implementation of WSE 2.0. In addition, I cannot assume that all of my non-CF clients will be .NET 2.0 so that too limits my ability to use WSE 3.0. Am I correct in eliminating WSE 3.0 as an option on these grounds
At this point, I'm looking at implementing WS-Security using WSE 2.0 on .NET 2.0 as a fallback option and wondering if this is viable.
Also, I'm wondering if I really need what WS-Security offers. Can I home-roll my own shared secret security implementation so that a token is passed with every request And can this be done in a way that does not affect the web method signatures Will a home-rolled option be a pain to consumers of my service I'm too ignorant of WSDL at this point to know.
Ken
Securing web services without WSE
vineetjaiswal
I take your requirements to be;
1) Interoperability across platforms notably .NET CF.
2) "I just need to prevent the web service methods from being called by anyone who has not been previously authorized. ". You have to explain what "anyone" represent here. Is this a single application, a group of people using a certain application or a set of machine. I take this to be a set of users. The choice here affects the type of credential you use to authenticate.
WSE 2.0 SP3 is supported and runs on .NET 2.0. This looks like an option if you use the opennetcf implementation for CF.
However your best option is probably to use https:// since this is supported on .NET CF and you can simply authenticate user with a username/password combination using a server certificate for encryption.
Thanks. Mark Fussell
WSE program manager.
Josh Petrie
My need to support Compact Framework applications leaves me with few options. I would really like to implement WS-Security to pass usernames and passwords in cleartext at the message level. Can I use OpenNetCF's WSE support to consume a WSE 3.0 web service
Ken
Bruce Bukovics
Ken,
in the early days of web services we used the following mechanism. There is a method that accepts username and password, authenticate the user and returns security ID (SID). You pass this SID on every consecutive call to a method of the service as an additional parameter or custom SOAP header. It is simple and has one major flaw: the password is sent in clear text on the first call. But if you can consider using SSL only for this first call, then you are fine.
Regards,
Martin
Phil à la patte
I was able to install WSE 3.0 on my existing web application/service and configure it in such a way as to not affect existing web services that do not need/want WSE. In addition, I was able to add a new web service to this same web application that uses the the UsernameToken assertion of WSE 3.0 and have its methods be callable from a Compact Framework application using the SecurityHeader object of the OpenNetCf 1.4. This particular assertion apparently requires clients to be WS-Security 1.0-capable.
gpr111
Hi Ken,
I would avoid creating your own security protocol if possible. Creating a secure security protocl is a non-trivial task.
Daniel Roth