How can i secure Web Service calls from a desktop application (winform) ?
I first think about pass login/password to each web services methods and then check from my database of user is authorized, but i'm looking for a better way to secure that.
Thanks.
If your web service is written in WCF there are lots of security scenarios already built-in and which can be manipulated as easy as web.config settings.
Related
I have developed a web site that requires user registration and authentication for some sections. Now I'm looking for a best practice to implement registration and authentication from a mobile app connecting to the server. This app will communicate using json with the server. I was thinking about HTTP digest, but I'd like to hear some one else opinion.
Just for the records, server is written in Grails (groovy) and uses spring security for authentication.
Basically you should post "j_username" and "j_password" to "/j_spring_security_check?ajax=true".
The spring-security plugin installs a LoginController, check it out to see the default exposed actions for ajax-based login.
For more in-depth information about the flow and code examples: grails-spring-security-core
Is it possible in WIF to combine active and passive federation? We currently have multiple Silverlight clients that communicate with 1 or more WCF services. The problem is that some of these services are hosted on a different domain. This means that, when we are using passive federation, calls to those services will fail when the user is not yet logged in for that domain (WIF will try to redirect the call). So is it possible to use passive federation when logging in to the website/Silverlight client and active federation when communicating with services? And has anyone done this (with Silverlight...)?
Your scenario sounds like this: You have a website that authenticates the user using passive federation to obtain a token. You hold on to the issued token, and pass it down into your silverlight client. The silverlight client uses that token to do active federation with your backend WCF services.
The most common way I've seen to achieve this is through RIA services. I've found this article which provides a nice introduction to this. Also, the identity developer training kit has an end to end sample. Look for the one titled "Developing Identity-Driven Silverlight Applications".
You say that WIF will redirect you WCF service call. This seems to be exactly the same problem as in this StackOverflow question: Passing SAML Token to WCF service from Asp.Net, and therefore my answer to that question might apply to your situation as well.
I m building a multi-tenant mvc application hosted in windows azure.
I would like to leverage access control service to allow user to get authenticated thanks to google, facebook, live id etc...
I managed to get a simple authentication working with a postback url that is configured in the Relying Party Application Settings.
but in my scenario it is more like that:
client1.mydomain.com/login or client1.com/login will go to the the providers pages select let's say google then he will sign in and then he will be redirected to client1.mydomain.com/Admin or client1.com/Admin
how can I achive that for any clients? should I add a relying party application for each client? can it be done by code? Is it ok with facebook?
I would like also the admin panel to be in silverlight, once the client is authenticated will he remain authenticated in the silverlight app?
Thank you by advance for any help or links that can help.
Fred
To answer your questions I would say yes to all. Each application would have to be set up as a relying party. So you would need to configure your app to use WIF and point to your Azure ACS.
All of these scenarios are covered in the Microsoft identity developer training kit.
Hopes this helps.
I have spent many hours trying to get my Silverlight Business application to run on Azure. My findings so far (open to correction)
Asp net authentication works with a Silverlight web application but not if Ria services is added. This is because Azure only allows one form of authentication per hosting and WCF will not work if the authentication mode is not Anonymous. This mean using WebContext is out of the question.
For the same reason passive federated claims authentication (either OpenID or custom STS) will not work with Ria services.
There is some good stuff in the Identity Training Kit. Active federated claims should allow a login popup to by used. Again there is an example in the kit. I initially didn't look at the "Out of Browser" example until I realised that it should work In Browser as well. I created a custom STS which the Web app called successfully, but I got "service not found" - I assume on the return leg.
I have now decided to pull the plug on all this as I need to get my application up and running. The Silverlight client already communicates with my database via Ria Services - why do I need to create extra pipelines when the authentication data is going to be in the same database? Would security be comprimised by simply checking a user name and password against my database? Would the System.ServiceModel.DomainServices.Client.ApplicationServices namespace be useful in this?
Second statement in your list is not accurate. You can use claims based identity with Ria Services. See here:
http://blogs.msdn.com/b/eugeniop/archive/2009/11/22/updated-ria-and-wif-samples.aspx
http://blogs.msdn.com/b/eugeniop/archive/2009/11/25/ria-services-and-wif-part-ii.aspx
I have WPF client consuming WCF service hosted in IIS. For authentication I am thinking of either certificate or user name authentication. Client calls couple of methods in WCF and passes some message.
For every call that comes to WCF, I
want to authenticate the user.
To place message in db, I have to know who is the caller, what is their username and few other properties about the user. How to pass these info[may be a small object] on every call?
This is the recommended default behavior - each call to the WCF service gets a new instance of the service, and each call is authenticated and authorized.
Just make sure not to enable things like session mode in WCF, and don't go down the path of a WCF singleton.
Just keep a regular, standard "per-call" WCF service - no issue there.
If you're on a corporate LAN, you could also think about using Windows credentials for authentication (which is the default for wsHttpBinding and netTcpBinding).
There's a really extensive WCF Security Guide which has tons of samples and how-to guides on how to set up certain scenarios of WCF security.
I would also recommend you check out The Fundamentals of WCF Security for a great intro to WCF and its security mechanisms.
A bit more advanced is the idea of Declarate WCF Security in which Juval Lowy introduces five security scenarios (that's a very worthy read!) and encapsulates them into security attributes to be applied to your service contract(s).