securing SPA multi-tenant SaaS application - authentication

I need some help with securing a single page multi-tenant saas application.
Questions:
1) What is the best way to implement it? I am trying the build the application using angularjs, spring mvc and REST.
2) Can this be done using Spring Security? Any example with creating login page and securing REST, calls will be helpful?
I have found a sample for implementing spring security with Spring JPA (http://krams915.blogspot.com/2012/01/spring-security-31-implement_3065.html) but it is not for SPA and SaaS.
I understand this a very broad question but i am new to SPA, REST and SaaS so any pointers will be helpful.
Thanks...

I have already participated in two projects with SPA and security aspects. Last of them was GWT + Spring Security. I am sure that you can use successfully Angular and Spring Security together.
Unfortunately there is no built-in config parameter 'we are in SPA mode' in Spring Security AFAIK. So some tweaking / conf from Spring Security side will be necessary. Example:
imagine that during login you call built-in into Spring Security login controller. In a case of successfull authentication by default user will be redirected to index page, where in a case of failure it will be redirected to corresponding error page. It is a normal behavior for standard web applications that will be not so useful for SPA web applications. In a case of SPA you need to detect AJAX call and print JSON with username / roles for successfull cases or send 401 code for failures (then detect 401 in JS and show corresponding error). You can use corresponding extention points from Spring Security to do so: AuthenticationSuccessHandler and AuthenticationFailureHandler.
Some another thing to tweak: by default after session expiration user will be redirected to login page (and SPA app receive login page as a response to the next AJAX call).
Looking into my personal exprience general guide will be like so: after login load list of roles into JS. Use it to show / hide corresponding components on UI side. Apply the same list of restrictions on server side too. To make sure that user do not edit JS in browser (although in a case of minified JS of some medium size app it will very complex task). On the server side you must choose between:
Secure URLs of AJAX calls
Secure some Java methods.
I prefer second one (secure business methods on services). I think it is more convinient because normally we want secure business operations, not some endpoints. As adwantage you will be able expose your business logic via some other protocol, and security will be there already. From other side I can imagine some business requirement to have different permissions for different endpoints / protocols. So it depends more on your actual situation.
Lage size JS applications must be splitted into modules. To decrease direct dependencies it may be better to use events insted of direct calls to cummunicate between modules. There are interesting thoughts of Addy Osmany about how to do security in these coditions. I did not found good link to it, maybe this or this will be helpfull (search "permission").
Feel free to post any questions. Good luck.

Related

Sharing user login between Blazor WebServer and ASP.NET Core API

I am building a service-oriented system for personal use (plus few friends may have limited access as well) - the aim is to have a dashboard for controlling my apps running on various machines such as Raspberry Pis (and potentially to be expanded to a VPS or few in future).
The architecture itself is pretty simple. For authentication I want to use AWS Cognito. Services would communicate with WebAPI (and potentially with eachother) using gRPC within a VPN, and dashboard would be served by Blazor server-side (may move to Blazor WASM Hosted model if I find a need for it). Each of the processes may or may not be on the same machine as any other (depending on the purpose). Blazor server may or may not run within VPN (I might want to move it to a separate web hosting later).
I created a simple diagram to visualize it:
The problem comes with authentication. I want to have Blazor server-side and API as a separate processes (for now they're going to run on the same machine, but I may want to move it elsewhere eventually). Ideally authentication should be handled by API, so authentication is client-agnostic, and the API can use it to verify if the logged in user can perform an action - which by itself is simple.
However, I want Blazor server to use and validate that token as well in order to determine what to display to the user. I want to do with the least amount of calls possible - ideally avoiding querying API for every 'should I display it or not?' choice.
I could easily do it by sacrificing possibility to move API elsewhere, and just merge Blazor Server and API Gateway into one project. For my current purpose it would be enough, but it's not an ideal solution, so first I want to look into how could I achieve my original vision.
How could I achieve this (with minimal amount of Blazor server to API queries)?
I was googling for solution a lot, but so far only found either examples of using Blazor server and API as one project, or using client-side calls to API directly.
Thank you good folks in advance.

Multiple client views/UIs with Jhipster

We are planning to have multiple client views/UIs (E.g. Customer facing UI and Internal UI) on one (same) set of web services which perform end-to-end operation needed for both views/UIs including login. I am assuming this is possible with minor modifications to the out of the box code generated by Jhipster. Mainly around ..
- enabling CSRF
- changing WebConfigurator, ???
- decoupling web services from UI into separate wars/apps
- pointing to the new web services url in the client side
- ???
I would like to know experts opinion on achieving the same, and kind of changes and effort involved.
CSRF will work with JHipster 2, be careful as currently Spring Security and AngularJS don't use the same CSRF cookie (and thus, don't work!)
I would limit the URL access, maybe by IP adress, either in the Spring Security configuration or per endpoint (by adding security annotations per endpoint)

authentication and authorization design in RESTful web application

I have an web application built using RESTful services (JAX-RS).
There are REST calls, and simple JSPs with js files to handle data.
Now I want to implement authentication and authorization in service. What I did earlier was to implement simple filter and inside each service check for #HttpRequestContext for if session has user object. Since it I want to expose service to say, external webapp, I will have to hard code system as there is no standard.
I feel this is not good design. Is there a design pattern to solve this common issue ?

Zend - Creating an PHP API for a mobile application

I'm currently planning the creation of a mobile application for ios and android.
The application will permit to the end-user to manage and see the progress of its projects. (Web creation company).
The application will have:
Project management (multiple)
View progress
View tasks
View hours
View files
View messages
Login/Logout form + Profile/Edit Profile section
Send/Reply Messages
Add comment on tasks and files
The question is: What is the best way to create an API (Restful or something else) using the Zend Framework?
This API must and will be integrated to a custom-made Projects Management System and a MySQL DB.
I just working on PHP API (no matter if API is for mobile platforms or another webs) and after realizing between SOAP and REST I chose a RESTful API and I can recommend it...
Zend Framework has components for both of mentioned approaches, but REST is easier and more understandable in comp. with SOAP...
The one thing what you have to think about is logging, you can use HTTP Auth or OAuth (HTTP autentification is easier), but better approach according to me is generate unique API KEY for your users (each user should have own KEY) and this KEY ensure you can recognize user and a security risk is minimal because user do not have to send login and password inside HTTP request (security risk) and in case of KEY is catched on WIFI or infrastructure, hacker do not get user logins to web application, only for API where propably will not be all features what main web app offer.
And if you set some time expiration for you KEYs or IP restriction for KEY, than you can make it more safe:)
Some tip for the end: Implement API as new separated ZF module.
One of the best stuffs I have noticed so far is http://getfrapi.com/
It makes use of everything from Zend to Pear. May be you should checkout the video http://www.youtube.com/watch?v=vJVQi7ZFSaQ

Strategies to secure a WCF service, returning Json data requested by jQuery

I'm having a hard time getting my head around this, and Google just isn't being helpful.
I'm looking at converting some legacy code to use the following technologies: ASP.NET, WCF, jQuery.
The ASP.NET conversion isn't an issue, nor is accessing the WCF service for data, on the server-side.
However, what I'm having an issue with is potentially being able to secure the service so that I can return JSON-formatted data, requested via jQuery on the client-side, but lock it down to prevent external access.
For this particular implementation, it's not that big of a deal, since the ... quasi-Ajax-like functionality has been in place for quite a while, and there hasn't been abuse.
But, once this project is complete, I'd like to take what I've learned and convert another form, which is often abused, and allow for a slicker display.
If I want to do client-side calls to a Web service, am I stuck making my Web service open to anonymous access?
Short of securing the Web interface down to a specific subset of users (I see no issue with securing the added functionality to logged in users), are there any other strategies on securing a Web service in this scenario? Am I just overlooking something obvious?
Require an authenticated session for both the server-side page and its caller via ajax, with both behind HTTPS.
Another strategy is to use a token that is bound to the session during the last page load to confirm that the session itself has not been high-jacked. This is done when the client loads the page. The server tracks what the next token must be to confirm a valid request.