I'm developing a mobile app, the server side is REST using Spring 3 MVC.
I was trying to integrate Spring Security with it to secure resources. I've read through a lot of material to get information on how to do it. I understand the architecture, however, when it comes to implementation I am still confused.
I referred a SO question; I have the same requirements. I understand the code, however, I am confused about when the first authenticate request comes in; at that time a token will not be present as the part of the header, so the same filter won't work.
So I was wondering how should I implement it. I was thinking of implementing it as follows:
A separate filter that authenticates user using username password from the request
After authentication the filter sets the authentication info in the context
And another filter that works with tokens for authentication for all API URLs
Is this the correct way to implement it?
No need to add another filter. Whatever the authentication result, the system will try to call handler for corresponding mapping, as you have chain.doFilter() outside if(validate_token).
You must tell Spring security that your request /login MUST NOT BE AUTHENTICATED. You can configure it in xml/java config.
Related
I am new to Play framework and Scala. I know Json Web Tokens and concepts of authorization. I have done a Spring Boot app that does user role authorization with JWT. Basically, I put my custom key value pair while creating the JWT and it has something like this "authorizations":[role_employee, role_user]
When a request comes, I intercept it, parse the token, and create a spring security context and use the annotation on the spring controller method and the authorization works perfectly. I tried finding this concept in Play framework, most examples are talking about how to intercept the call and verify the validity of the token, but no one is talking about how to make sure the authorization is also correct. Basically, by merely verifying that token is fine, how do I create a binding that for a particular controller to be allowed to execute, what roles are permitted?
The most powerful framework for authorization in the Play environment is the Deadbolt
https://github.com/schaloner/deadbolt-2
You can also find simple authorization parts in the other frameworks. For example, I often use Pac4J for Play. It has authentification and simple authorization parts:
https://github.com/pac4j/play-pac4j
I am building a RESTful API application with Symfony2.
The app will consist of two parts.
JavaScript front-end - everything the user will ever be able to see and do will reside here.
Symfony2 back-end API - every resource and data the user will be able to reach from front-end will be served in standard JSON via endpoints.
I have never built a fully RESTful application before. My main concern is how to authenticate users.
I imagine REST authentication like this:
A user enters his credentials in a form generated in the front end, then the request is sent to the server where authentication logic happens and if the user is authenticated, a response with "token" is sent back to user, that he will add that token to every request url or authorization header (I don't know which of these options is preferable).
Then with every request, the server will check if the user token is valid and if the user is authorized to access that data (roles) and if so serves request data. (I don't want to allow users login with Google, Facebook or anything like that. I want my users logging in to other application using my app)
Now this seems quite simple, but then there's OAuth2 that got me confused because I jumped into developing without research. I downloaded FOSOAuthServerBundle and started messing around when I started to get a feeling that something is not right.
What I would like to know is the difference between RESTful authentication and OAuth.
What are the recommendations for implementing the described login mechanism?
You've got it pretty spot on. You use OAuth just for the authentication and all the following requests will have to provide that HTTP-Authorization header. You would need to create your custom authentication provider to handle that. Also use something like FOSRestBundle to create your resources.
What is the best practise for authorization and authentication of users in REST spring boot?
I am building web app with standard pages + REST API for mobile. I looked at many articles about Spring security and basically most of them goes with some sort of fitler approach that will allow or block REST calls. In my case, however, I have some auth logic based on who the user is. For example, there is a /update API that updates user information, and user can update himself, but cannot update other person.
Initially I thought to use next auth schema:
User calls auth API and pass name/password or cookie
System generates short life token, saves in it's database.
User get this token, updates his cookie (so JS in web application can read and use it)
When REST call is being make cookies are passed. At Controller, token is extracted, checked for expiration, query is done to database to validate token and get user id.
Based on user id, REST will be permited or blocked.
Is this the right approach to implement? I have a pretty big mess in my head after reading articles about spring boot security.
At least: session auth will not work for me (REST is stateless). I want to make auth for mobile device without storing login/password there.
Does it make sense to pass this token in the REST body itself? What in case of GET method?
Many thanks for sharing your knowledge.
Did you find a solution to your problem?
I have answered this problem elsewhere, if you are sure you won't want to open up the API to other developers/clients in the future (if you do then you should look at OAuth) then a simple token based solution will work.
Something basically along the lines of this:
Setup a standard html login page, that you can use for user login to the app
setup spring security to return a cookie on sucessful login with an authentication token
in your mobile app, embed a WebView (or equivalent) and load this login form - allow the user to login via that webview, on response grab the cookie and store the token (as mobile is generally single user, you can keep that pretty long to save mobile users having to keep logging in)
Add a security filter to the the REST API to authenticate against the token (from the mobile app pass the token in the header for example) - then you will be able to use normal spring authentication context for current users etc.
This approach is suggested by Google here: (EDIT: Google seems to have changed the page I originally read to be about using Google+ sign in and OAuth2.0 - I can't see a link to their general Mobile/API docs so here it is in the web archive :) )
I have also written up my implementation here:
Overview of the approach using Spring security
The code & details
Although this was really just an experiment/Proof of concept, it might be useful in your thinking.
Cookie approach seems perfect for the use case. Token can be tied up with user id. Filter can extract cookie and pass user id for example as header to apis - that should take care of GET...
Using OAuth 2 I need to limit user access to permitted resources only, where the connection to the API is made through an ext.js REST proxy. The ext.js proxy takes care of data retrieval and maintaining the model relationships. I haven't found an elegant way to make different calls from the proxy to the backend depending on the user logged in.
I am wondering if the proxy has to be different for each user logged in to my application because each user has their own access token.
Another option would be to make the proxy know about the logged in user during the proxy initialisation process and save this information in a persistent way.
Has anyone solved a similar situation before?
The article gives a detailed explanation on how to use OAuth2 with Sencha Touch.
http://www.sencha.com/blog/meetcha-using-sencha-touch-to-build-a-mobile-app-for-meetup-com/
There are several ways to use OAuth. One uses redirects after the initial authentication (for this you might use an iFrame inside a Sencha login view). The other uses your backend server as an intermediary to the OAuth server that can avoid the iFrame solution but requires more logic on your server.
You can then use a session cookie which will be resent with all HTTP requests including your REST calls. Most back ends support session cookies and so all you need to do then is look up the user ID you stored in the session object as part of your REST API code.
Another option is to set a custom HTTP header in each REST call that requires authentication. To avoid duplicate code, create a derived class from the Sencha proxy class to set the header containing the access token. You can store the access token in a Store or on the Application object or as a static value on the proxy. I've done this for both REST proxy calls and Sencha Direct proxy calls.
AJAX Proxy header property:
http://docs.sencha.com/touch/2.3.1/#!/api/Ext.data.proxy.Ajax-cfg-headers
First, let me describe the application: we are working on a web-based software which is some kind of custom help desk application. It requires the user to login (we use FOSUserBundle). After login the user is redirected to the dashboard. From the dashboard there is no more page reload, the frontend is build on Angularjs and the user can get anywhere within the application without page reload. You could speak of a single page application.
So the data that is presented to the user, is fetched from a rest api (we use FOSRestBundle). This works quite well at this point.
There is some kind of dilemma. Only our staff will access this application (for now). So a staff member needs to login to access the helpdesk. The data that is pushed to the frontend via angularjs is called via api, so the user that has just logged in needs to authenticate again on every request because of rest.
Problem: Since the backend runs on symfony2 let us just try to get the user object of the currently logged in user when an api call is made:
$this->get('security.context')->getToken()->getUser()
returns anon. that stands for anonymous, or
$this->getUser();
returns just null.
So the authenticated context seems to be gone when using the rest api. However when I call an action directly without rest, I can get user information.
So what we need is to secure our rest api and get user information on every api call. We don't want third party people to access our application, just staff. I am not familar with OAuth, but the user will be redirected to a third party page to Allow/Deny access to his data? This would not be an option for us.
Based on that information, do you have any suggestions or ideas how to secure the api and transport the user data so that getUser does not return null or anon. but the actuall logged in user?
there's another way to resolve your problem.
It's by using Certificates.
you can generate certificates then use Http tunneling (https obviousley), the server will ask for a certificate (you've to configure Apache for that but it's not a big challenge).
with this in place, you've to add a CertificateManageron the server side to ensure that the certificate is valid and to know who's calling the service (to be able to authenticate the user at each request), the CertificateManager(or what ever you'll call it) will probably have to be configured within you filters chaine (as known in the java world), et voilà
Hop that help you,
Abderrazak
REST is stateless so you will have to send some kind of authentication/authorization in each request. You can use HTTP BASIC AUTH or something like OAuth.
Have a look at https://github.com/FriendsOfSymfony/FOSOAuthServerBundle
I'm kind of building our application in exactly the same architecture (RESTful API with Symfony2 back-end and AngularJS frontend.
Another way is to duplicate the api routes, so that you have the api routes protected by OAUTH and the api routes protected by the session, both of them pointing to the same controllers. The method was explained here: https://stackoverflow.com/a/22964736/435026