I'm looking for some guidance on the best way to authenticate to my WebService. Right now, I have a standard WebService on .NET 3.5, and a MVC website that sits on top of this WebService.
The MVC website uses OpenID to authenticate users, and during the development phase, we have simply been passing the user's OpenID Claimed Identifier to the WebService to authenticate. Obviously this is not what we will be releasing to the customer when we go live.
So my question is this: What's the best way to authenticate to the WebService?
Some of the API's I've played around with use Authentication Tokens. Another idea we had was to, upon connection to the WebService, pass the client an encryption key which they could use for all transfers.
I'm thinking out loud here, and again, any help is greatly appreciated! Thanks!
...
UPDATE: Right now I have created a custom SoapAuthenticationHeader which has an OpenIdURL property. This is used on all service calls to authenticate the user. The problem is two-fold:
If a hacker know's a user's OpenIdURL, they can easily gain access to the WebService.
The OpenIdURL is currently passed in plain-text.
So I could pass an encryption key to the client upon connection to the WebService, and have the client encrypt the OpenIdURL in the SoapAuthentication header. But I'm not sure about how to best go about that...
You might want to take a look at OAuth:
http://oauth.net/
(Use http://oauth.net/code/ for coding.)
As it is geared specifically for this scenario (Open ID isn't, really).
There is another question on SA which asks about the best way to secure a web service, and Open ID and OAuth are both discussed:
Web Service Authentication using OpenID
ASMX web services (which Microsoft now considers to be "legacy") have no ability to use OpenID for authentication. They can only use what IIS provides to them. You could possibly add a SoapExtension that would do OpenID authentication for them, but I wouldn't spend time there.
I don't know enough about OpenID to be certain, but I suspect it can integrate with WCF through federated security. I'm sure someone else will answer with details on that.
This isn't really an answer, but I can't leave comments...
You say "I have a standard WebService on .NET 3.5, and a MVC website that sits on top of this WebService".
I might be way off base here, but the language implies that these two sit on the same server. If so, why can't you just share the users database and the cookie token?
James
Related
I would like to add a password protected page to my WPF modernUI application and could use some help with it.
First of all I don't really have a clue how to handle this stuff correctly in my case.
My application is used on several machines. The protected page should be some kind of admin-page to edit a database that is used by the app.
My idea is, that there is only one Admin-account. But this account can be used from any machine. The admin should be able to change his password. So there must be some kind of encrypted password file on the server which can be accessed from any machine. I don't want to store the password within the application, as this would mean that the admin has to change his password on every machine.
So my question is: What is the best/safest solution for my idea? I'm just looking for hints as I don't have a clue what to search for.
The best Practise nowadays for distributed client applications who share a Database is indeed not to have direct access to the Database.
What you need is a WebService. A web service can be anything. It just has to be hosted somewhere. It can be an ASP.NET application, a WCF Service, or even something not .NET related like a PHP or Java application.
The communication between your application and your WebService depends on what you decide to use. Today a lot of people are using so called REST APIs which use either XML or JSON as data transfer format and use the HTTP protocol.
Its not hard to implement such an API since there are ton of Libs and Solutions out there.
You could use RestSharp for the communication at your client side. Which is straight forward and simple. You could also consume a WCF Service. Which is hosted in IIS somewhere.
However your Problem is nothing special and there are several solutions available. The decision is on your side since it depends on a lot of things such budget, available infrastructe etc.
Your question is quite broad but as far as WPF is concerned you could implement custom authentication and authorization in your application by creating classes that derive from the IIdentity and IPrincipal interfaces and overriding the application thread’s default identity. Please refer to the following blog post for more information an an example.
Custom authorization in WPF: https://blog.magnusmontin.net/2013/03/24/custom-authorization-in-wpf/
The actual credentials should be stored on some remote server that may be accessed through a web service, WCF service or some other kind of API. The details of how to actually get the credentails would be implemented in the AuthenticationService class in the sample code from the above link.
I am building a client program that interacts with a WCF Service via Internet. Everything works as intended but I am wondering how I can protect my services so that only my client program can make use of it?
Right now everyone with the correct URL to my services can use it with WCFTestClient (e.g).
What is the best way to make it private so only my clients can make use of the service? Rotating token strings? Certificate? Password?
I have no idea and haven't found anything useful on the Internet.
Best regards
UPDATE: The client program is intended to be downloaded for the public (everyone). So it is not for internal use, it will be a service we are gonna provide, ones in official production.
My own thinking was like: Bind a certificate in my client programs (if thats possible even?). On the IIS where the WCF service is running, check for valid certificate. Is that possible? Or better solutions out there?
Protect .net Web Service URL
Along with the other answers, that can't be bad too,
and if you want to be super careful you can implement a token system, where the clients get the first token from you, each request returns a new token, and you always check a client vs it's current token (but that's being over careful in my opinion)
Update - because it's for the public, the client can have a way of generating a valid token to check on the server, you can have a token be valid for an interval of seconds, so even if people caught the request and found the token, it will not be valid after ..15 seconds or 30,etc
If you are using Form Authentication then you can leverage the ASP.NET to check for FormAuthentication Cookie by enabling AspNetCompatibilityRequirementsMode to Required
Or if your service is stand alone i.e is consumed by everyone then you can use oauth authentication you can read more about it Oauth Authentication
What you could do is there would be a consumer secret key which would be shared to all authenticated clients. The caller would sign some info using this key and server would also sign it using the same key and then compare it.
Hope it helps
I am currently building an authentication server for a game. Basically how I have it planned out is a client will connect to our servers and they will authenticate the client and then issue the client a ticket. As long as the ticket is valid the client is able to join servers. Besides authentication I would like to display user stats and other stuff on their profile. I have not done anything with ASP.NET before but I think that is the right way to go on this. I was wondering if anyone knows where I might get started with communication with an ASP.NET web app. Is that too big of a step since I haven't used ASP.NET before? Should I start with something smaller?
EDIT:
Ok so I have a simple WCF Service now but I am having trouble understanding exactly how to use it. How do I actually use the service I created to exchange data between a console app and a ASP web site? Anyone know of a tutorial that creates a WCF service then actually shows how to implement it into a project?
Another option is to use someone else authentication server. I.e. Facebook, Messenger (Live.com), Google all provide OAuth authentication if you can agree to use their list of users.
Side benefit is that you don't need to worry a bit less about personal information (i.e. child accounts require much more care that you want :) ).
What kind of game? Is it a game played on your website or a client application? If it's a website then all you really need is a Login page. Otherwise, yeah WCF.
I need to call a .NET SOAP webservice in a secure way. It must be secure in such a way that others can't call the WebService methods, and also it should not be possible for "the middle man" to understand the content of the messages.
The caller will also be a .NET webapplication installed on another IIS.
I can design the webservice methods as I want, so no restrictions there.
I have been researching HTTPS/SSL with certificates, but I don't know if it actually solves my problems in a good way? For example, it would be anoying if the certificates has an expiration date, although it's not a showstopper in any way.
So how would I go about this in a good way..?
Thanks for any help.
As #BrokenGlass said, SSL only encrypts the traffic between points. It doesn't handle securing individual functions from usage without authorization. Here is a good article on just such a topic using SOAP headers:
How to: Perform Custom Authentication Using SOAP Headers
This can be mixed with any form of authentication except Windows Integrated. To use Windows authentication, you'll need to have a separate library which accesses the Active Directory through the DirectoryServices namespace.
Assuming you control the infrastructure then keeping the server that is providing the web services behind a firewall so it's accessible only from the web servers and implementing IPSec should provide the necessary security.
From the software point of view, this article contains all you need to know about protecting the service interactions.
HTTPS/SSL works fine. Just make sure to renew your certificate in time to avoid warnings and messages for your client.
I need to call a .NET SOAP webservice in
a secure way. It must be secure in
such a way that others can't call the
WebService methods, and also it should
not be possible for "the middle man"
to understand the content of the
messages.
HTTPS/SSL only solves the "middle man" part of what you want to achieve. You would still need proper authentication in place on your web service. You could do this i.e by using the built in Forms authentication and providing a Login method that returns your authentication ticket.
I am relatively new to the WCF world so my applogies for the newbie question. I am currently designing a layer of WCF services. One of them is an authentication service, so I came up with the following authentication mechanism:
IUserService.TryAuthenticateUser(string username, string password, out string key)
Basicly the user tries to authenticate and if successful - he/she receives a sessionkey/securitykey/whateverkey... the key is then required for every other "WCF action" e.g.
IService.GiveMeMyFeatures(string key);
IService.Method1(string key);
This mechanism looks extremely intuitive for me and is also very easy to implement, so what bothers me is why I cant find similar WCF examples? This unique key (which is practically a session key with wcf-side expiration and all) can then by used from the various applications, according to the application's architecture: for ASP.NEt it can be stored in a cookie, for Winform/WPF/Mobile I guess it can be stored in the form-class in a field and so on...
So here comes question number 1: What do you think of this method?
I also read, that I can use the build-in ASP.NET Authentication Services (with membership providers etc... if I understood correctly). From architecture point of view I dont really like this method, because when authenticating from an ASP.NET page the workflow will be like this:
ASP.NET -> WCF -> ASP.NET Authentication Service -> Response
In this scenario one could also bypass the WCF layer and call the auth. service methods directly from the asp.net page. I know that by going thru the WCF layer for every authentication request I will lose some performance, but it is important for me to have a nice, layered architecture...
And here is question number 2: What are the advantages/disadvantages of this method over the first one, and why is it so popular, when from architecture point of view it is kinda wrong?
I also read, that I can send user credentials for every WCF method call and use the built-in mechanism to authenticate and respond properly to the request.
Q3: What do you think if this method?
And to sum up - obviously there are many authentication methods, but which one do you think is best and most generic (considering that the WCF services will be called from asp.net/wpf/mobile/etc...)?
Thanks is advance :)
The reason you can't find examples it's not best practice - it's turning something that should be stateless, web services, into something stateful, and something that will not load balance well at all.
As web services already have standard username and password facilities, supported by almost every SOAP stack (excluding Silverlight) that's the way to go. You can use the standard .NET role based security model to protect your methods with this approach as well.