Where should authentication be done: "Webserver or AppServer"? - java

Consider the following architecture that has two web-servers(for balancing) and around 10 java app servers for servlet processing.
Where do you think is the right place for doing authentication. In ApacheWebserver or custom code at one of the app servers?
If I do authentication at Webserver how should we handle custom things like OPenId?
EDIT: Also what are the implications of choosing either on Performance, Scalability and Security?

As usual with architecture question the answer depends on many things.
Do the web servers do anything that needs protection (like serving static content. Then you'll have to do authentication on (or before) the webserver
are the web servers or the app servers close to maximum capacity? Try to do authentication on the side
Can the web server handle all the authentication requirements? Or is logic/information needed that is not available on the web server (like the reputation here at SO which affects, what user may do). The requirement to support OpenId might be such a limiting factor.
Finally note that there are not so obvious attacks which might be affected by where you do authentication. e.g. if the web server handles 404 (not found) but the app server handles authentication (401) an attacker can find out if a resource is available or not even if he doesn't gain access. Since replying will take longer if the app server needs to be accessed this information might even leak to the attacker when in both cases an identical response is returned.

Related

SSO - Central authentication Service (CAS) - for production?

Do people use Central authentication Service (CAS) on Banking / financial service projects ? Is it a reliable framework for production use.
Updated:-
The user details are stored on Active Directory but it is not related to windows logon.
We have around 5 different related web application (separate wars) which may have common users. We are planing to implement one common web application which takes care of the login mechanism using spring security. And this application would pass the Spring security context to all other web apps which would also use spring security.
Along with this we also use 2 factor authentication.
After making some searches it seems CAS would help to achieve SSO (along with Spring Security) but I am just trying to ensure if it can be used in a Financial services projects production system ??
Note there are two major types of Single Sign-On (SSO).
There is what I call "Enterprise SSO" which uses the Mircosoft Active Directoy credentials the user used to log into their workstation to also access other resources like websites using the builtin SSO feature of browsers like IE. The underlying protocol used is Kerberos or NTLMv2 (aka SPNEGO to NEGOtiate Kerberos or NTLMv2). This makes it true "single" sign on because the user only enters their password once when they log into their workstation. There are not many solutions that can do this type of SSO. Obviously IIS with IWA turned on is one.
Then there are numerous other solutions for websites that actually redirect the client to another central website that authenticates the client and then redirects them back to the original site with some kind of token. This type of SSO is commonly used on the Internet (like when you log into stackexchange using your google credentials) but it is also not entirely uncommon in an enterprise environment. It is popular in academic institutions where students use whatever computer they can find and aren't logged in with domain credentials in the first place.
So in an enterprise environment like a bank / financial institution my opinion is that "Enterprise SSO" is the most direct and therefore superior solution. With the non-Enterprise SSO solution the authentication step usually requires a password so it's not really true SSO. You have to log into the workstation and then also login to the SSO central website and then you have access to any sites that participate in that particular SSO solution. And it requires running an extra service.
But don't Google for "Enterprise SSO" because everything is marketed as "Enterprise". Use search terms like "Kerberos", "NTLMv2", "Active Directory" in concert with "SSO" and your server programming environment.
I work for a huge company in Germany (not the one currently listed in my profile), with 300k+ eployees. We use CAS for a number of applications but our main strategy is SAML. The main reason for SAML is the "front channel" - you can reliably pass assertions via browser.
This has huge advantages in a large enterprise since very often parts of the network are firewalled so the "back channel" solutions (like CAS) don't always work.
With SAML, you could for instance use a completely external service like Salesforce with your company's SAML identity provider. Almost out of the box.
Please note that my production knowledge of CAS is ~4 years old. I might be wrong about the "back channel" for CAS, please recheck that.
Ok, few further insight related to your question update.
We use AD as user directory too.
Our identity provider (basically where you login) implements x-factor auth (SMS and token services).
We use standard SAML solutions, we don't implement proprietary things.
Sorry I did not mention it before - I'm not in finance/banking but we have apps in a very wide range of security requirements.
I know peopla who use CAS in the financial sector. Howere, it's not the subject area that matters, it's seqcurity requirements that matter.
I have had positive experience with Spring Security in the past, but it is not the tech of choice in the current company (more JBoss).
CAS is surely a good thing and will definitely work. However it's normally not the technology which fails it's how you use it in context. If you don't have extensive experience, in the area, get a consulting or a professional pentest. Too many things can be done "a little bit wrong" and lead to severe consequences.
I'm writing all this - and I'm even not a security professional, I'm an architect who designs these apps to fulfill (among magnitude of other things) their security requirements.
I'm the Chairman of CAS and founder of CAS in the cloud (https://www.casinthecloud.com).
CAS is a web SSO and it supports Kerberos and SPNEGO. So yes, it can be an Enterprise SSO as well.
CAS is production ready: for a big company, I use it for millions of users and hundred of websites.
I'm not sure to fully agree with the "back channel" / "front channel" stuffs. SAML is a standard for federation so if you have two main organizations with their own SAML IdP, you'll be able to federate identities. For other use cases, I prefer CAS which is far more simple and has a large community with a lot of CAS clients.
You normally use a SSO inside a large organization. It allows members of the organization to login into any internal application with same credentials with a single place for password management. But in this use case, the organization has full control on the CAS server and can be confident in it.

Best practice implementing security on an Extjs / Java application

So I had an ExtJs / Java application deployed on a private server and network and didn't need to implement security, but now I had been requested to deploy that application on the cloud, choose OpenShift (Red Hat Cloud) so far so good... but I've been wondering how to implement security ...
I used to work with spring security core (with Grails) but my application database is CouchDB (actually using CloudAnt service) and it doesn't seems to be nor easy or natural to connect it...
What would you recommend ?
right now I have let's say http:re-hat-something-else/myapp/mybussinesinterface.html which I don't want to show unless you are logged, so lets say I already have mylogin.html and lets say I already have a business method that authenticates users, would it be right to store in localstorage a token that would tell me if the user went through the log in page to validate if someone is trying to open directly http:re-hat-something-else/myapp/mybussinesinterface.html
Of course I would also have to add extra security to all my back -end methods to validate nobody is trying to execute them directly ...
Any ideas ?
thanks in advance
Generally, it's the server's job to protect its content from unauthorized users. If the JavaScript is served up to an unauthorized client, all bets are off. Same goes for the Java REST API: if it is exposed to unauthorized clients, all bets are off. Clearly the server needs to protect both the Java and the JavaScript resources.
You're running your application inside of some sort of container (Tomcat, JBoss, etc). The questions you're asking are best answered by implementing some sort of security at the container level. For example, if you use shiro with JBoss, it's as simple as implementing a servlet filter that would deny access to your application for unauthorized users. I'm sure you can do something similar with Tomcat.
Oh, and make sure you know the difference between "authorize" and "authenticate". Chances are, no one else really understands it and you'll need to explain it to them. (If they do understand the difference, count yourself lucky.)

Tomcat and flood protection

We are using Tomcat 7 for our web application. We provide an XML based API so that our customers can communicate with our server in a machine-to-machine way (no web browser needed). The requests are processed by a servlet.
We need to prevent users from sending too many requests in a row. Some of the services we provide involve polling for results and users may make requests in a loop without any pauses, making dozens of requests per second for nothing.
How can we protect ourselves from being flooded with useless requests? Is there a simple way to block requests at the servlet entry level when there are too many requests originating from the same IP? Is there something built-in Tomcat to deal with this problem?
Assuming that you are using an apache reverse-proxy in front of tomcat (if you aren't you should be), use mod_cband on the apache layer.
You could code your own.
Starting points for looking at this would be the Servlet API, in particular the Filter interface and the getRemoteHost() method of the SerlvetRequest interface.
Should be easy enough to write a Filter implementation which stores a count of requests from each host and takes action if a limit exceeded.
Spring Security has a lot of the features of Apache httpd's mod_security if you want a Java-only solution.
Apache's mod_evasive
or mod_security
could cover for your need here. You may consider Cloudflare for more complexly serious attacks that will require hardware protection.

How to implement rate limiting based on a client token in Spring?

I am developing a simple REST API using Spring 3 + Spring MVC. Authentication will be done through OAuth 2.0 or basic auth with a client token using Spring Security. This is still under debate. All connections will be forced through an SSL connection.
I have been looking for information on how to implement rate limiting, but it does not seem like there is a lot of information out there. The implementation needs to be distributed, in that it works across multiple web servers.
Eg if there are three api servers A, B, C and clients are limited to 5 requests a second, then a client that makes 6 requests like so will find the request to C rejected with an error.
A recieves 3 requests \
B receives 2 requests | Executed in order, all requests from one client.
C receives 1 request /
It needs to work based on a token included in the request, as one client may be making requests on behalf of many users, and each user should be rate limited rather than the server IP address.
The set up will be multiple (2-5) web servers behind an HAProxy load balancer. There is a Cassandra backed, and memcached is used. The web servers will be running on Jetty.
One potential solution might be to write a custom Spring Security filter that extracts the token and checks how many requests have been made with it in the last X seconds. This would allow us to do some things like different rate limits for different clients.
Any suggestions on how it can be done? Is there an existing solution or will I have to write my own solution? I haven't done a lot of web site infrastructure before.
It needs to work based on a token included in the request, as one client may be making requests on behalf of many users, and each user should be rate limited rather than the server IP address.
The set up will be multiple (2-5) web servers behind an HAProxy load balancer. There is a Cassandra backed, and memcached is used. The web servers will be running on Jetty.
I think the project is request/response http(s) protocol. And you use HAProxy as fronted.
Maybe the HAProxy can load balancing with token, you can check from here.
Then the same token requests will reach same webserver, and webserver can just use memory cache to implement rate limiter.
I would avoid modifying application level code to meet this requirement if at all possible.
I had a look through the HAProxy LB documentation nothing too obvious there, but the requirement may warrant a full investigation of ACLs.
Putting HAProxy to one side, a possible architecture is to put an Apache WebServer out front and use an Apache plugin to do the rate limiting. Over-the-limit requests are refused out front and the application servers in the tier behind Apache are then separated from rate limit concerns making them simpler. You could also consider serving static content from the Web Server.
See the answer to this question How can I implement rate limiting with Apache? (requests per second)
I hope this helps.
Rob
You could put rate limits at various points in the flow (generally the higher up the better) and the general approach you have makes a lot of sense. One option for the implementation is to use 3scale to do it (http://www.3scale.net) - it does rate limits, analytics, key managed etc. and works either with a code plugin (the Java plugin is here: https://github.com/3scale/3scale_ws_api_for_java) which pushes or by putting something like Varnish (http://www.varnish-cache.org) in the pipeline and having that apply rate limits.
I was also thinking of the similar solutions a couple of day's ago. Basically, I prefer the "central-controlled" solution to save the state of the client request in the distributed environment.
In my application, I use a "session_id" to identify the request client. Then create a servlet filter or spring HandlerInterceptorAdapter to filter the request, then check the "session_id" with the central-controlled data repository, which could be memcached, redis, cassandra or zookeeper.
We use redis as leaky bucket backend
Add a controller as entrance
google cache that token as key with expired time
then filter every request
It is best if you implement ratelimit using REDIS. For more info please look this Rate limiting js Example.

What should I do to make my Java web application to use HTTPS?

By default, the Java web apps that I develop runs on http.
Suppose, if I want my web app to run on https, is there something specific that I should do as a developer? Or it it totally a network-guy task and un-related to developer?
Basically I want to know the steps to host a Java web application on https.
You don't need any programmatic changes in your web-application, You need to configure SSL with your web/app server
Glassfish SSL Conf
Tomcat SSL Conf
Jetty SSL Conf
JBoss SSL Conf
It depends on what J2EE(Web Container) you are using,
But there should be no developer changes required.
For tomcat you can click here.
The other answers are correct, but I want to add just one tip: sometimes a website serves some pages as http and others as https, usually in the mistaken belief that this will somehow improve performance since https is supposedly harder on the server, best to serve as much un-encrypted http as possible.
Don't do this! It's such a waste of developer effort since you now have to plan all your http -> https transitions, and perhaps even your https -> http transitions. You risk introducing security holes with the transitions (oops, anyone with session cookie can make the transition!). I recommend just doing all 100% https in this scenario. Crypto will never be a significant performance bottleneck, since it's perfectly scalable (more servers, more processors, more threads, etc, always help crypto, you won't be so lucky with the database!).
To enable HTTPS on sever and to make specific application accessible only through secured mode i.e https please do following
Create KeyStores and Add Certificates to the key store [ Links can be found from above answer :) ]
Add the following to your web.xml
Restricted URLs
/appname/*
CONFIDENTIAL
you can add various patterns like /appname/login*,/appname/service* etc..

Categories