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.
Related
I want to create a game within the Unity game engine in C# with .NET where I can securely connect out to a private server, and read and write data from/to the server. I understand how to do this in a non-secure way, where I would setup a private SQL database with a webpage interface between the two.
My problem comes here, I know if I want the web interface to be public, I need credentials to connect to the server, such as an Auth key, or username and password. However, in order to use those, then the auth-key would need to ship with the game as a file, or would need to be written directly into the codebase. I know that users can decompile games, and access these files and get the credentials if I include them, which means that option is off the table as far as I am aware.
It is my understanding that even with this layer between the database and the client, someone could still find the url for the interface between them, and then send custom function calls to this url as I will be doing in the game program. Wouldn't this lead to the same conclusion as having the database be open?
If anyone has answers to this, or resources where I can learn about this process, please let me know! I have never done server-side programming before and have also never thought about security before in my life.
You're correct in that you should not embed authentication keys into your apps. Where you're falling down is in exposing your database to the world. Don't do this. Instead, hide it behind a web server that serves only json data files. This way you can take advantage of the web server's authentication and session protocols.
Since you're already working with C#, I would suggest looking into ASP.NET Core MVC and specifically about WebAPI. But I would probably recommend node.js for lightweight microservices.
I have to come up with an integration process to allow existing system to use external data providers. The system is a medical timetable web site, using ASP.NET MVC, that allows the patients to schedule their appointments to doctors.
As far as I go you can see on a figure below:
All the providers must expose my contract ISuperIntegration which will be develop by me. I won't be developing External service 1 and External service 2, they will be developed by other companies.
Here the issue comes: basing on the concept of that I could require the way providers should setup their services to communicate with my website properly, I want to forbid for another third party clients consume "External Service 1" and "External Service 2", Or at least make it difficult to do that.
Here is a list of stuff I am setting:
ISuperIntegration interface. It contains operations related to my domain such as GetSchedule, GetDoctors and so on.
Transport protocol. I don't want it to be complicated so I'm thinking about using HTTP.
And could define some general recommendations but they could be easily avoided.
At the moment I'm thinking of using HTTPS with certificate authentication. It would require the implementer to setup their infrastructure so my web site could properly consume the data.
If I would go with basic HTTP, the implementer would just leave their service to be easily consumed by anyone else, which I don't want.
I hope my question is clear. Will be happy to give any other explanations you want.
I'll really appreciate any your responses, commits. Thank you!
I'd always use HTTPS for things like this. Let's just say that's the cost of doing business. You simply cannot have anyone with a sniffer grab that kind of traffic out of the sky. There's a reason why all banking etc. use HTTPS for things that should be secure.
Apart from that, web services have pretty standard mechanisms for security, I'd recommend looking at OAuth over HTTPS. There are plenty of implementations for that.
If your talking about basic web sites, I'd use a standard security mechanism as well like group based security (which boils down to a username + password). Again, there are plenty of implementations for that.
Basically my main word of advice is: don't go inventing stuff when it comes to security. If you're not an expert, you're probably going to get it wrong, and end up with something that can be intercepted by a third party or (much) worse.
You have several options:
Basic authentication over HTTP.
PRO. Easy to implemet
CON. UserCredentials was going in clear text throuh the network
Implement WS-Security with WCF. For example, they can sign their requests.
PRO. Easy to implement with WCF
CON. Java clients can faced with problems
You can force clients to use HTTPS.
CON. You should setup your web server.
You are like Oracle, they want people to develop in Java language but they also want to forbid competitors to run the Java compiled code on non Oracle's virtual machines, or at least make it difficult to do that :)
So you can do the same by protecting your interface with patent or copyright law. However, I doubt that it is patentable or copyrightable :)
Considering the privacy sensitivity of the data, IMHO it must be encrypted while in transport. Hence HTTPS not HTTP.
Authentication of your service to those providing services to you: well essentially it's up to them, not up to you who they expose it to, similarly how they want it protected is their call. Now assuming you do have a way to make them do the right thing...
Client certificates aren't that expensive nor prohibitive in setup to get up and running. But you do need to register the client certificate (every time it is renewed!) with the server in order to get the needed authorisation (just recognizing it's a valid cert isn't enough: anybody can apply for a (validly signed) certificate ...) .
But all that is relatively painless and rather well documented around the web, and it can be done on almost any platform of choice.
As several people mentioned these earlier you can't guarantee that those external companies will expose your service with specific security settings, it's up to them.
If you are responsible for developing MVC application and WCF service you can only force someone to use specific security settings on the layer between your WCF services and those External 1 and 2 providers.
Btw, here is a good tutorial that can be useful if you want to improve your knowledge about how to configure WCF security.
How External Services expose your service it's up to them. Just image that this is normal web 'proxy' behavior.
Maybe the architecture which your company adopted it is not the best for this solution
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've got a website which contains the profile of users. I am now working on a mobile app and I would like to access the profile details from via the app. My idea is to simply create a webservice which returns the relevant fields (some of which might be password protected). How can I ensure that the web service is being request only by my application and not by anything else (desktop, other app etc..)? Initial idea was to have a secret key embedded in the program which is used to encrypt the data sent over to the web service, but I'm not sure how difficult it would be for someone to find that key since it's on the client side app.
Any suggestions on what the best approach would be for this type of situation? (I assume the technique would be the same regardless of phone model)
Thanks
Microsoft now considers ASMX web services to be "legacy technology". All new development should be done using WCF.
WCF has many more abilities in terms of security than ASMX does.
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.