I need to authenticate a username and password input against a Remote Desktop Services Gateway before connecting the user using the normal windows RDP client because I need to override the default UI behavior of the RDP client in event of invalid credentials and I cannot use LDAP or another service as it has to work from outside the network where only the RDS gateway is available.
I haven't been able to find much in the way of documentation for the RDS Gateway API exccept for this: http://msdn.microsoft.com/en-us/library/ee672219(v=vs.85).aspx but there are no examples or much of anything.
Has anyone had any experience doing something similar?
Well, one option would be to write your own RDG client: see the Terminal Services Gateway Protocol Reference and the authentication handshake section. It doesn't actually sound too difficult to do, since the handshake is implemented entirely with basic HTTP requests.
Related
I have a website with architecture (HTML + JSON + webservice (C#)) installed on a server which is open to internet. Now, my webservices are opened to the whole world so anyone can access it and may try to malfunction.
What I would like to do is to make my webservice to work limitedly to my application only instead of other applications. Like when a website is on open internet but its web services are private to the website only and not to the whole internet.
Right now there's a big data security concern.
The primary way would be to add some sort off login/account system. That then of course needs to be managed and all that.
The other posters' approaches of just putting some key or certificate into it will only work if it is not that important. Anything you store in the application is invariably reverse-engineerable. So if someone is decently determined, that level of protection is easy enough to overcome.
If the number of possible consumers is small enough, another approach might work:
Make it only reachable from the local network (IP adress ranges associated with Local Networks). Then use a approach like VPN so clients can connect to you local Network. Basically you move the account part to another System. But such a approach can have security issues, especially if that VPN connection goes straight into your DMZ.
In the end it really depends how critical that is. Security exists in flavors from "anybody reading his computers network traffic with Wireshark can break it" to "reasonably secure for high grade private data". We have no idea what level of security you need and what level of skill you have, so we can not give a useful answer just yet.
I would suggest you look into using Certificates to encrypt your webservice, then your application will call it using that same loaded certificate. Only an entity with your server certificate key will be able to decrypt your calls.
Accessing a web service and a HTTP interface using certificate authentication
Calling a rest api with username and password - how to
Edit: If you cannot use the certificate method because you are calling from say the browser directly, you might want to look at an authorization cookie of some sort, So that lets say on your login pages the request might be open to public but on all subsequent request you require authentication and once the user has logged in you rely on the authorization cookie or token to validate whether they have access.
Another method: IdentityServer for instance has provider token stores, so you can request a token from the store, then only with the issued token you can access the API. And your API would also then query the store to check the token is valid.
I found a very easy solution to it.. by getting ip address of the remote client's in web service i can validate whether the request is coming from my webserver or not
so anytime if any spamming client try to request my web service i will retrieve its ip on every request inside webservice and reject the request for ex :
if (HttpContext.Current.Request.UserHostAddress.ToString() == "127.0.0.1")
{
return "my server";
}
else
{
return "invalid client or spammer"
}
I have a c# .net wcf web service on a windows server with iis. I need to know if there is a way to tell the web service that it can accept request only from specific URL.
example:
ApplicationA call ApplicationAwebService = should work
ApplicationB call ApplicationAwebService = should be denied
Right now, they are all on the same server, but I need a solution that works even if they are on a different server (3tier applications).
thanks
If you are using WCF then its possible to use mutual authentication between services and clients. Mutual authentication achieves not only security for the server to accept connections from legit clients but provides the ability for the clients to verify that they are talking to a legit server.
Mutual authentication can be achieved through Message security (Encrypting the data sent between the client and server and vice versa) by using certificates, kerberos (Windows auth), tokens and a username/password configuration.
Mutual authentication can also be achieved in WCF through rolebased authentication, identities, and resource based authentication
Reference from msdn: https://msdn.microsoft.com/en-us/library/ff647503.aspx
I have a WCF Service which I need to call from a monodroid app. I want to prevent users from using a tool like fiddler to read the data. I tried using TLS with server- and clientcertificates but it seems that monodroid doesn't support clientcertificates. Is there another option I could try to secure the service?
Edit: To clarify the question: I'm looking for a possibility to encrypt the communication between the app and the service to prevent man in the middle attacks like using fiddler or another proxy. The best thing I found so far is using a basicHttpBinding with transport security and a server certificate but this doesn't work against man in the middle attacks.
You can secure the WCF service with username and password, the below url's provides how to create wcf service with username and password feature
http://www.codeproject.com/Articles/96028/WCF-Service-with-custom-username-password-authenti
http://www.felinesoft.com/blog/index.php/2014/02/securing-a-wcf-service-with-username-and-password-using-message-security-and-the-channel-factory-pattern/
My question is about a WCF (Windows Communication Foundation) application I'm working on. I've checked a lot in internet and I've realized that WCF handles authentication through transport security by specifying credentials in the Credentials.Username property of the client. I would just like to know how I would be able to actually show the user a log-in screen and validate credentials before setting the client credentials. What I am trying to achieve is a lo-gin behavior on the client like the one in applications like Windows Live Messenger.
I don't know if what I'm asking is kinda dumb or makes no sense, I'm a WCF starter and is really confusing since I used to work only with ASP.NET.
Also, Membership and Authorization providers are available on non-IIS hosted services? If not, how you implement this on WCF?
Thanks.
You can get the user's name and passw, set the Credentials then you can call any function. If the validation fails an exception occurs, that you should catch this exception to show an error to the user.
Here you can find a complete example: http://msdn.microsoft.com/en-us/library/aa354513.aspx
I have a C# web service on our website and I only want to be able to call it locally where its hosted - restricting access from the outside world. Whats the easiest way to do this without a login form? We cannot restrict the web service directory per ip (because I don't believe its static)
Alternatively, you could also host them on a separate website, which you only bind to localhost (127.0.0.1)
PS: You should really get a static IP for your webserver. Or at least reserve an IP address for the server's mac address in your DHCP server configuration.
You can setup windows authentication on the web services and require the authentication be a local account to that machine. You'll have to modify your code calling it by providing network credentials, but that will prevent people from the outside calling it.
This article should explain how to do it.