views:

478

answers:

6

I'm looking for a way to pass some sort of credentials or Authorization token from a VB.Net Client to an ASP.Net web application that allows the Client to auto-login to our Forms-Authenticated website. If a user is logged into a local application, I want them to be able to view some web pages without having to login to the website as well. The credentials are not the same between the apps, but I would just like to pass some sort of encrypted token or key to the web page so I know they are coming from the desktop application. Is this possible without requiring a username and password login?

I also need to make sure this URL that is used cannot be simply copied and used from another location, so I'll need to include some sort of information in the encrypted value to know where it's coming from.

I know how to login the user with Forms Authentication and all that, just need to figure out the best way to secure this. Thanks!

A: 

Is your desktop app running on machines that are in the same domain as your web server (i.e. all in the same company)? If so, Integrated Windows Authentication is your easiest solution.

ProKiner
No they'll be anywhere transmitting over the internet.
Shawn Steward
+1  A: 

You can share credentials between the applications using ASP.NET Client Application Services.

Here are some resources:

Client Application Services

Client Application Services with Visual Studio 2008

Rob Windsor
Thanks, that looks like a possibility. However, the main thing I'm looking for is to be able to pass in some sort of encrypted token behind the scenes to auto login without any username and password. That's what I'm still struggling with.
Shawn Steward
+2  A: 

You might want to look into issuing client-side certificates for these applications. Basically, you generate a certificate that you install with the client application and then on the server side, you check the ClientCertificate property of the HttpRequest instance exposed by the Request property on the current context.

Note that what you are doing is really a very bad idea, in that applications should never be assigned identity, only users. To that end, you should be authenticating each and every user that is using your app, not considering the application to be the identity. It's commonly considered a bad practice to do such a thing.

casperOne
Thanks casper, I agree that this is not an ideal solution... but I'm not being given much to work with. We do not have access to the user information on the web server to validate against. However, I think I may be able to use the user info to help restrict the access to only the current user. I will do some testing and get back to this post. Thanks.
Shawn Steward
+1  A: 

I think its best idea to use a web browser control inside the desktop application . Then use the WebBrowser1.Document most probably

WebBrowser1.Document.Cookie

get if the user is singed in.

Thunder
A: 

I also need to make sure this URL that is used cannot be simply copied and used from another location, so I'll need to include some sort of information in the encrypted value to know where it's coming from.

If you store the encrypted value in a cookie or as a field in a form (POST request), then the credential is no longer in the URL and so it can't be easily copied (note that I said "easily").

jdigital
+2  A: 

OAuth is commonly used to allow desktop applications to access a user's private data on a web site. Since you're using .NET, I suggest you check out DotNetOpenAuth which includes sample OAuth web sites and client applications. It allows for this secure token to be passed that can tell your web site that the desktop app is the one making the requests and (usually) whose data is being accessed.

The best part about the OAuth solution is your desktop app never has to ask for the user's credentials. No credentials are in the URL. And if the desktop application is ever compromised (perhaps by the computer being stolen), the web site can kill the secure token the desktop app was using to cut off access without requiring the user to change their password.

Andrew Arnott
That sounds like the perfect solution for this scenario, thanks Andrew!
Shawn Steward