My application will be:
- Single Page App (say in angular/backbone)
- Spring MVC based Server.
I find many examples about using Spring-Security where the login page, logout page etc.. are all HTMLs. And Spring Security directs to appropriate pages based on Session State.
But in my case the login/logout page will be in JavaScript - All interaction with the server for login/logout is over HTTP(REST style URLs), and response JSON. There is no HTML in play here.
Question
How can i use Spring Security in this case? In other words - How can i expose login/logout behavior as a API?
Since the front end is Browser based app... i guess usual cookies etc. should still work for identifying session.
Yes Cookies still work in your cases. But you need to tap on the ajax urls instead of normal urls. I had an experience with a mobile based - single page application and I managed to do it with a grails backend. When logging in tap on /j_spring_security_check?ajax=true if http response is 302 and it redirects you to /login/ajaxSuccess it means that you have logged in successfully. Otherwise you failed to login.
Related
I am curious if anyone has a solution to this unique situation as I have a solution currently, though I feel it is not the most optimal.
The Situation.
I have built an MVC style web application that talks to a web API through http (authenticating via JWT). My web application is secured by appending authorization to its view controllers and redirecting to a Microsoft login endpoint - then directing back to the view where whichever given controller/function handles the request, connects to the API, appends data to the view, etc.
Preferably I would like to use JQuery/Ajax to submit http requests client-side and update a given view with whatever data the user may wish to see relative to the webpage they're on. This way I could control exactly what the user should see landing on the page any which way and submitting requests from web app to API. Also would enable better continuity between requests as there isn't actually a full refresh of the view. All in all it is my line of thought that this execution would lead to a nice user experience.
The Problem.
So the big issue that I have had to circumvent is CORS Policy. I initially attempted to use JS just as I said above but requests would be redirected to the login endpoint and blocked due to there being no CORS header appended to the request.
'So include a policy in your application and append an authorized header to your Ajax outgoing request' you might say, well... you cannot override CORS security around Microsoft's login endpoint.
My Solution.
What I have done simply instead is create HTML Forms around fields the user would pick and chose to specify what data they wanted from the API. Then carry over input data to the returned view via 'ViewData'
and using razor pages of course I can actually initialize JS variables via C# input.
Side Note
I use JS to transform the API data into graphs for the user to see. I am doing this with a JavaScript Library.
My Question to you.
This all leads me to ask then, is there a way to dynamically update a view without using JS? I require a method that can hit the login redirect without being blocked because the request initiated client-side.
Every solution I am aware in some way, shape, or form utilizes JS to make the request. So I am at a loss for how to truly get the functionality I am after without having my requests get blocked due to CORS Policy.
Thanks in advance y'all.
I am trying to implement CSRF protection in an existing application. We have Spring MVC on backend and a mix of HTML, CSS and Apache Velocity Templates on frontend.
I have tried configuring the Spring CSRF functionality as shown here - https://docs.spring.io/spring-security/site/docs/current/reference/html/csrf.html. After reading through this Spring documentation, I get a feel that after configuration, Spring Security would automatically send tokens with all requests but that is not happening in my case - perhaps something is wrong with my configuration.
As an alternative, I am creating an instance of Spring Security's CsrfTokenRepository and calling generateToken and loadToken methods on it in my front controller which intercepts all HTTP requests coming to the server. This way, I am able to deliver a new token for every HTTP request and then send it back on the next one.
The mechanism fails though if I click different links within my page too frequently - by the time a page is rendered and the new token is set in hidden fields, the browser has already sent a request to another page with an old token. It also fails when I open more than one tab since the token received by the latest opened tab wins over tokens from tabs opened before it.
To overcome this issue, I changed the tokens to be generated only per session. However, now I run the risk of tokens being exposed - via get requests or referrer fields for example. Is there a way to improve the performance of per request tokens? or make the approach more secure with per session tokens?
we have a problem in our web application and I'm looking for some opinions.
The following scenario:
We have a Java EE Server Application deployed on a JBoss Application Server
Our Web Application is also deployed in the AS
The Web Application communicates with the server via JAX-RS
The Web Application needs authentication
Currently we are using 'form-based authentication', which is directly provided by our Application Server.
The advantage of this approach:
List item
We don't have to do anything, but just specify the auth-method 'FORM' and specify a login page
We can design our login page by ourselves -> the page looks awesome
The disadvantage and also the problem I'd like to discuss:
Our webapplication makes calls (inital-page-load/ajax) to our server application.
If the user is authenticated, it will receive JSON responses. But if the user is not authenticated, the form-based auth will intercept the call and return a html page.
(this looks fishy: WebApp makes a ajax call and expects json, but will receive a http redirect to a html page [login.html]).
The current problem:
At some point the session cookie (of the form-based auth) will timeout, and then the complete application breaks, because each ajax request will not receive any json (as expected), but will receive the login.html page.
Would be really thankful if people who solved that problem could report about their approach and architectural design decisions.
Current Ideas:
Switch from form-based to something else (and provide a /login rest resource)
React on the client code on possible wrong responses (if http code 301 -> redirect on login page)
Something else I can't think of right now
I am implementing Spring Security login and I am trying to understand something, here is the scenario I want to implement:
For initial login show login page and let user in.
If after some inactivity session expired and user makes some action show him popup window to authenticate (js-based popup in browser). Continue with the action like there was no login form.
Implementing form is easy, but how do I make the popup work - let's say I make the request to some protected URL after session expired, how do I make sure it's not forwarded to login page, but to my login handler that shows popup window?
Another issue - I need to integrate with SiteMinder, so I would need to read the Login/Password combination and after it's read, forward to SiteMinder for authentication, after that's done I want to return without forwarding.
Answer to SiteMinder issue:
Siteminder is generally installed on a Webserver behind your servlet container.
Also, Siteminder manages the authentication and an application does not have access to a user password at all.
To integrate with Siteminder use this filter:
http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html#d0e6295.
Answer to the login with the popup issue: since you need to integrate with Siteminder, I would not recommend to implement the login via the popup.
The sample given on the above springsource website is quite primitive and can break in several use cases. Using the SM_USER header alone has several caveats, see my answer here: How to validate SM_USER header in Spring Security preauthentication for siteminder
CA SSO aka SiteMinder, as well as other traditional html-form-request-response SSO systems, have a hard time dealing with Single Page Applications and protecting the web services that you invoke via AJAX, without breaking the flow of your application.
I've tried to debug this without any success. I have a working Spring Application with GWT and Spring Security, but when I change the security-context around to use CAS authentication, I do get redirected to the cas page (usually), but after successful login, I get redirected to the correct url, but I get a "page not found error" at the browser level. After refreshing the page (same url), I'm logged in, and application loads as expected. No errors in the logs, as far as I can tell, no differences in what's happening in the application when using CAS vs normal spring security form login.
I believe this answered my question:
http://static.springsource.org/spring-security/site/faq/faq.html#faq-cached-secure-page
which basically states that if you're securing html pages, you're in charge of configuring caching, so that a cached page can't be accessed. In my case, this wasn't entirely clear, as the gwt services were still getting secured, so I wasn't seeing secured content, but still, that was the problem-