I want to build my web services serving JSON data utilizing RESTful architecture.
But I want my own client apps only that can request from my web services.
Basically, my web services contain sensitive data that is not for public consumption, but I wanted to build it that way so I can build many different client apps that connects to my web service.
Would appreciate any ideas for this, thanks.
The fact that it's RESTful or uses JSON isn't a relevant factor when it comes to securing a web service. Any web service would need to be secured in the same manner. There are a few things you should do:
If possible, don't host your web service on the Internet. If the web service is hosted within your company's LAN, for example, it won't be exposed to public consumption unless you specifically exposed it through your router.
Set up authentication and authorization rules. If you're hosting your web service inside of a Windows domain, you could simply use Windows authentication and set up rules based on Active Directory users and groups. Other options are to use HTTP authentication, client certificate authentication, or if you're developing in .NET, forms authentication.
Use encryption (HTTPS), especially if your web site is hosted on the Internet.
You just need a couple things in place to do this. First, the service client will need to authenticate against your service (over HTTPS) to make a request. Once the client is authenticated, you can return a private token which the client has to include with this token. As long as the token expires after a reasonable amount of time, and a secure algorithm is used to generate it, this should do what you want.
If you have more strict security requirements, you can follow Jakob's suggestion, or have the client start a VPN session prior to making requests.
Related
I believe the short answer to my question is "No", but allow me to describe the context.
We are currently using IdentityServer to authorize access to our APIs (via client credentials). All of the API clients are computer programs which run in our data centers and are under our control. In order to minimize our attack surface, our IdentityServer is running from an internal/private network, reachable from our APIs, services, and other apps. No problems.
We now want to leverage the IdentityServer installation to provide user authentication for our public-facing web applications. These applications run via ASP.NET MVC and will consequently require user interaction with the IdentityServer for password validation (implicit or hybrid grant type). This appears to be a hard requirement, but I'm curious if there is a simple way to maintain the private installation of IdentityServer.
Can we proxy requests from the ASP.NET middle-ware for handling the authentication handshake, and does it even make sense to do so? I'm leaning towards a public-facing STS to eliminate any proxying, but thought I would ask to see what other patterns are employable.
For what its worth, we would ultimately use cookie-based authentication with the hybrid flow, but would be able to start with the implicit flow too.
The user's browser must be able to access the identity server. This can be via a proxy though.
We are developing an application in a microservice architecture, which implements signle sign-on using Spring Cloud OAuth2 on multiple OAuth2 providers like Google and Facebook. We are also developing our own authorization server, and will be integrated on next release.
Now, on our microservices, which are resource servers, I would like to know how to handle multiple token-info-uri or user-info-uri to multiple authorization servers (e.g. for Facebook or Google).
This type of situation is generally solved by having a middle-man; a single entity that your resource servers trust and that can be used to normalize any possible differences that surface from the fact that users may authenticate with distinct providers. This is sometimes referred to as a federation provider.
Auth0 is a good example on this kind of implementation. Disclosure: I'm an Auth0 engineer.
Auth0 sits between your app and the identity provider that authenticates your users. Through this level of abstraction, Auth0 keeps your app isolated from any changes to and idiosyncrasies of each provider's implementation.
(emphasis is mine)
It's not that your resource servers can't technically trust more than one authorization server, it's just that moving that logic out of the individual resource servers into a central location will make it more manageable and decoupled.
Also have in mind that authentication and authorization are different things although we are used to seeing them together. If you're going to implement your own authorization server, you should make that the central point that can:
handle multiple types of authentication providers
provide a normalized view of the user profile to downstream resource servers
provide the access tokens that can be used by your client application to make authorized requests to your microservices
We have implemented several intranet web applications in my company. They all:
are built by ASP.NET MVC 3
use CAS(ticket in cookie policy) and a shared LADP server to single sign on
have role based access control logic according to current logon user
expose many RESTful(like) web apis for page's ajax usage
Now we find those web apis for ajax requests can be used as services for other web applications(like employee info, client info etc). Which means we need to access those apis at backend(with C# code). The problem is the authentication and authorization.
I don't know how to go with the existing authentication mode to access those web apis. I can only think of a way that use an shared service credential among back end servers but it means this credential must have a full access authority. Is it a security risk? And as I metioned, we use ticket in cookie policy with CAS. Which is OK for browser but seems difficult for C# code. How to use a credential with CAS from backend? Use a WebClient and handle 302 manually?
Has anyone met a similar case and have some good experiences with this? Please give me some advice. Thanks a lot.
What you need here is to use the CAS proxy mode to access backend web services : https://wiki.jasig.org/display/CAS/Proxy+CAS+Walkthrough.
I am starting a new product that will require a .NET based server (using WCF) hosted on Azure. I would like to have basic authentication and security features. The clients are all "rich" UI but are not neccessarily microsoft ones.
We intend to have the first client application written in Silverlight, but we want to keep our options open to implement clients for iOS and Android in the future. So we do not want to use WCF specific features but rather protocols that are easily available on other enviroments.
Of course, with the Silverlight client, we hope to get as much done for us automatically as possible. We intend to only communicate through web services.
Which bindings are recommended for such a scenario?
How would you implement security? (assuming we need basic security - Users being able to log in with encrypted user and password and perhaps some built in basic role management althouh this is optional).
Suggestions?
You could use WCF to implement a REST interface
The binding would have to be a basicHttpBinding (to be open to all platforms) and using SSL to secure the line.
Managing credentials could be done using tokens to be passed back and forth after authentication. Much like a http session. You could pass the token using a cookie but the token could be part of the API or Headers as well. See this Best Practices for securing a REST API / web service
This would grant you the power of .NET and WCF without losing interopability.
I am currently developing a distributed application using Ruby, Ruby on Rails, Sinatra and pure Rack web services.
I will have few services (RESTful , not SOAP based) which will communicate using JSON and I would need a way to secure and verify the identity of each of those services during the communication between them, so no one could pretend to be a service and make requests to the other services.
The core idea is to treat other services as "users" and be able to verify their identity and limit their access to data if necessary.
So the question is how to do this using only Ruby and how to manage effectively the service identities and their access rights.
Should I build some additional authentication service usable by the services ?
Should I build internal gems to provide some connection middleware with keys/shared secrets ?
Is there maybe some other way to do this?
I would generate an application id and secret that you could pass with each request. Since you are not dealing with other users and just applications try looking into authentication tokens with devise.
I think OAuth is a protocol that is commonly used for web service - to - web service runtime authentication, especially with RESTful APIs.