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
Related
There are 2 WebApi Projects on different servers. One of these servers (WebApi-A) has OAuth2 authentication workflow setup with Authorization Server and all.
The another WebApi project (WebApi-B) has an end point that I would like to Authenticate through [Authorize] attribute. I don't want have a new authorization server but to utilize (WebApi-A's) authentication process just to validate the token.
From what I understand if the machine-key is same across these server. We can essentially replicate the authentication process from WebApi-A in WebApi-B without having to call WebApi-A at all.
How do I achieve this?
You could, in theory, pass through the JWT token and if your OAuth setup uses the same client secret and data store it should just work. You would have to ensure that you add the JTW token when requesting and to use some distributed cache to verify.
I would rather ask whether or not you should rather create a gateway that can handle and authenticate the requests and delegate them to the separate APIs? This feels like an identity server (http://docs.identityserver.io/en/latest/topics/apis.html) would solve your problem. Anything you do other than moving the authentication from web api A would just be a stopgap.
Duplicating the setup could work but that will mean that you have to now maintain it in two places. So I agree that doing that is less than ideal.
This is a great article that may aid you:
https://www.scottbrady91.com/OAuth/Delegation-Patterns-for-OAuth-20
This will have a lengthy answer so I will just leave you this diagram showing multiple Resource Server, Client, and a separate Authorization Server
Taken from this article Single sign-on across multiple applications (part II) which I hope could get you started.
you can use your token when login in web api and then you add the token to the header "Authorization" with bearer "your token"
First of all excuse my bad english.
I'm a newby in oauth2 and I'm trying to setup an authorization server with JWT tokens.
The server is running in a Owin self-hosted environment.
At this moment I've setup the token generation and it seems to work properly, I've also setup the refresh token provider and it seems to work (but it's just a minimal implementation); I didn't change the RefreshTokenFormat in the OAuthAuthorizationServerOptions leaving it to default (I don't know what is the default format), so the access-token is clearly a JWT token and the refresh token is something else.
All of this seems to work correctly, but I will need to run this authorization server in a microservices environment, so the authorization server service might be moved at any moment from one machine to another, so it needs to be stateless or at least to save needed informations on a shared storage (DB) or replicated local storage (I'm on Service Fabric) or some kind of distributed cache.
Testing I noticed that if I generate a refresh-token on a machine and then I try to use this refresh-token on another instance of the authorization server (on another machine) to get a new access-token, it fail with a generic invalid_grant error. My guess is that the auth server just keeps some token-related information in memory but I don't know exactly what and how.
I also would like someone to point me in the right direction to solve this issue.
Thank you very much.
I solved the situation using a JWT token also for the refresh token.
This way the authentication server seems to be completly stateless.
I’m building a webservice and having some troubles witch option I should choose. Therefor I was hoping someone could point me in the right direction. I found many articles but none of them have more or less the options then I want.
What I want the webservice to do:
Client should get a WSDL derived from the ASMX file. Within that service there is one unauthenticated webmethod called “Authenticate(string Username, String Password)” that returns a custom AuthenticationSoapHeader. The AuthenticationSoapHeader is exactly and preferably same as the System.Web.Security.FormsAuthenticationTicket class that is used in the webapplication.
http://www.codeproject.com/Articles/4398/Authentication-for-Web-Services-using-SOAP-headers
http://www.codeproject.com/Articles/27365/Authenticate-NET-Web-Service-with-Custom-SOAP-Head
I’m thinking of using the articles above to implement this and changing the username password combination for a ticket that will be encrypted including a datetime stamp to expire the ticket. My questions.
Would this be considered a best practice? If not, what better option do I have.
Is using WSE3 “Microsoft Webservice Enhancement” necessary?
Is WCF a better option if your kinda new to webservices?
The soap requests go over Https SSL and do not need further encryption on the client side. Thank you in advance.
Best regards,
Danny
I can't answer all these questions, but I can answer a few: IMO WCF is all you need as a tool set for this project, based on your description. WCF has a number of different flavors (http, TCP, etc.) and each has several different options for how you implement security.
WCF has options for user/pwd authentication, or you can construct a custom method, or you can construct a Login() function that takes a UserID and Password as parameters, returning a boolean. There are also options that allow you to authenticate BEFORE the main program receives the request. That's what the built-in UserID/Password authentication does.
If you implement SSL on the host, assuming you're using an http-centric binding, you won't need anything on the client side for encryption as the WCF software will take care of that, once you have both the Host and Client software configured properly. In effect, your WCF client app will behave like a browser, handing all the nasty cert stuff under the covers.
WCF also lets you a) run your web service as a stand-alone windows service (called "self hosted"), or b) allows you to configure your web service behind IIS, which has some advantages. WCF will also provide a WSDL for your clients if needed.
There are some other nice things about WCF; if 10,000 concurrent users hit your web service at 8 am on Monday, WCF automatically queues the requests it can't handle, processing them in order as it can. I've slammed our testing web service with numbers like that, and the program never broke down, processing >150 logins and file uploads / second. WCF is also works fine with Java, iOS and Android.
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'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