So, I would like to implement complex session management in my application. Essentially, I would like to store user sessions both in the postgre and Redis.
So, the algorithm should be the following:
A request is sent to the app, the application parses incoming request cookies and extracts a session parameter;
Spring server tries to retrieve respective session object by id from Redis
If the previous step succeeds, then the server verifies the session and lets the request pass through if the session is active and valid. Otherwise - unauthorized path.
If the session object isn't present in the Redis, then the server tries pulling a member session from the postgre. Does the same verifications and caches the response. If the session isn't valid or isn't present in RDBMS - go to the unauthorized path.
Is there any elegant way to implement the following mechanism using existing packages? Or will this require custom logic?
So, I watched this video - https://www.youtube.com/watch?v=TggWLDAXmb4
And I was able to get a gist of how basic security mechanisms work in Spring and implement the workflow described above;
Basically, you will need to have:
Custom security filter that will be preparing specific Authentication;
Custom authentication provider that will be performing authentication (checking session)
Related
I'm currently trying to implemente some basic security structure to my Spring Boot project, but I can't find an really concrete answer to what is going on in the authentication process. Basically, I just followed this tutorial:
https://leaks.wanari.com/2017/11/28/how-to-make-custom-usernamepasswordauthenticationfilter-with-spring-security
An it seems to be using the default Spring Security protocols and stuff, i really only implemented a custom filter where my code checks MongoDB for an existing user, and the thing works as expected.
The thing is, Postman tells me that whenever I do a successful login I receive a JSESSIONID cookie, and this cookie is used on get requests, for example. If there is a SESSION ID, I assume that Spring somehow knows how to map ID to users, but how? I haven't set up any DB configuration for that, and Spring seems to store that state somewhere. How can I access it, or change to a DB on which access I have control of?
if you want to save sessions to database, you can add org.springframework.session:spring-session-jdbc dependencty. You can choose sql file from here for your database and create tables.
We want to configure our service with OIDC authentication against a keycloak server.
We are using spring security 5.2.0 with spring boot 2.2.0.
There are multiple instances of our service and we do not want to share any state between them with central storage (e.g. databases, distributed caches, ...), nor use sticky sessions. That's why we already implemented two custom cookie-based repositories for authorization info that would normally reside in the server-side session. (CookieBasedRequestCache and CookieBasedAuthorizationRequestRepository). That way the oidc redirect flow works except for the last step where the user is redirected to the original url:
After successul login, keycloak redirects back to our instance with a code. This instance (let's call it 'A') validates the OAuth2AuthorizationResponse against the initial keycloak authorization request. It gets the information from a cookie we saved earlier in the login process to avoid Spring Security's session management.
Now, if the authorization response is successfully validated, instance 'A' sends a final redirect to the original URL that the user requested before logging in. If this request is answered by the same instance 'A', everything works fine. But if a different instance (say 'B') answers the request, it doesn't work because B doesn't know anything about the user's authentication state.
Questions:
Is there a cookie-based JWT repository we could use to save the access token across instances? Or how would one implement it?
Where in spring security's code (filter chain?) is the check whether the user is authenticated? This would be helpful for answering the final redirect to the original url.
Background:
We are building system that required login information for all pages. the application is designed to be Restful application using codeigniter as Phil Sturgeon library.
Scenario:
- username & password is required when a user called any page [Client]
- Authentication is needed where any Api call is fired
I a bit confused how to migrate or do the above scenario, And what are approach to authenticate the application.
A simple way to authenticate users in a RESTful API is using HTTP Basic or Digest Auth. In this setting the user credentials are sent via the Authorization header in a form of username:password as Base64 encoded hash to the server.
As the principles of REST state that the communication between client and server should be stateless, the client has to sent the authorization on every request. In practice this means that you often store the credentials in a session on the client side (as you don't want to the user to enter his credentials on every request). Please note that you should only do this via an secured connection using HTTPS!
To authenticate the application you could use a token based system, such as an API-Key. This means any request would be signed using additional request parameters. If the number of applications is finite and known, you could alternatively simply identify them by their IP.
You could also take a look at OAuth.
Request the login and password for every page is more suitable and more secure(that what I do in my projects), using 'virtual' and stored session in the database may be a second solution but not a good because it will be an additional charge for the DB.
I used Spring and Apache CXF to create a REST webservices application. I'm using x.509 certificates to authenticate the users, and then a custom authorization service to get all of the user groups and details. I've implemented a custom UserDetailsService that extracts the user information and populates a UserDetails object. Part of the process of populating this object involves a request to the corporate authorization service. The authorization service is unfortunately a proprietary system, but at least they provide a Java API. The authorization service, among other things, returns a list of groups that the user belongs to.
I'm still in the development stage, but my observations so far seem to indicate that the UserDetailsService is called once upon initial connection. Then each request uses a cached authorization object.
So my question and potential problem are this... Corporate policy states that applications are only allowed to cache the users authorization details for a set period of time. So, how long does Spring keep these UserDetails objects cached before refreshing them? And, how can I control this cache time to make sure I comply with policy?
There was a ticket submitted for something similar to this request:
https://jira.springsource.org/browse/SEC-898
The advice in the ticket is to create your own filter than periodically sets the Authentication.setAuthenticated property to false, forcing a look up of the user. You might be able to achieve the same by setting a smaller session timeout
I am starting a new project where we are planing to build a restful back end and an AJAX font end. I am approaching the problem by focusing on Identifying all the resources that I have and what the various HTTP verbs will do them, their URI and the JSON representations of those resources.
I am looking for the best design for securing the backend. Here is the list of designs I have considered. I am looking for alternative designs not listed below, and pros, cons recommendations. The system will be implemented with Spring 3.0 and possibly Spring Security 3.0, SSL will be used for many parts of the system but not for all of them, so some requests may come on SSL and some might not.
Option 1: Use the HTTP session
Show a standard login screen, create a server side session and let tomcat send back a jsessionid cookie and have the ajax client include the JSESSIONID cookie on every XHR request. This options just feels like it's the wrong approach for the following reasons.
The connection becomes statefull which is against the rules of REST
I want to be able to split the bakcend into multiple seperate WAR files which means i could have multiple HTTP sessions on the backend, if that is the case then this approach does not work. While I don't need the ability to split the backend into multiple apps today, I would prefer a design that allows for that possibility.
Option 2: Find an open source Java based security library that does this
Other than Spring security I have not found any other Java libraries, any recommendations are highly appreciated.
Option 3: Try to use an existing protocol like OAuth
In my very brief look at OAuth it seems that it is designed for authentication across sites where each site has it's own user database. In this system i want a global user database shared across all the backend ajax services.
Option 4: Use SAML and Shiboleth
This options seems over kill and hugely complex to setup and maintain.
Option 5: Send the username and password with every request
This requires that user sends their username and password with every request, which means that the front end AJAX app must store the username and password as a JavaScript object and if the user navigates away from the page then back the username/password combo will be gone and the user might be forced to log in again. I don't want the front end to try and put the username and password into cookie as that would comprise security.
Option 6: Implement my own authentication / Authorization protocol
Create a REST service that users can present their username/password combination to and then get back and security token, which they must send back to the service with every request. The security token would be digitally signed by the service and would have an expiry time. The token would be only good for most operations high security operations would require a new login screen as port of confirming the operation.
Problem with this approach is I have to invent yet another security protocol which seems like a total waste of time.
I am sure I am not the only person up against this problem, I hope the stack overflow community can point to some options and tools that I have not found yet.
Take a look at Apache Shiro. It is an authentication system that has a session management feature that can be used to share sessions across applications. This may be the easiest thing to do.
Or you could use Spring Security (or Shiro) with a Remember Me cookie that is shared across the webapps (as long as they are in the same HTTP domain). The remember me cookie would be analogous to your token in option 6. You can set the expiration on the cookie that so it is short lived like a session cookie or long lived like a regular remember me.
You might also want to take a look at Jasig CAS - Single Sign-On for the Web. It has a REST API and a protocol (Proxy Tickets) that allows services to proxy user AuthN to backend services like you described in option 6. http://www.jasig.org/cas
Briefly...the application that serves up the AJAX client is protected with Spring Security (supports CAS out of the box) and gets a Proxy Granting Ticket that you embed in the AJAX client. The AJAX client uses the PGT to get Proxy Tickets for your REST services...protected with Spring Security too. The REST services get an authenticated userId without every touching primary credentials.
Alternative, you could keep the PGT on the server and use AJAX calls to retrieve Proxy Tickets that are then used by the AJAX client to call you REST services.
As I understood you are going to secure a rest application, to preface you must know that a security provider consisd of three concepts (3A):
-Authentication
-Authorization
-Auditing
to implement these three together you must provide bunch of tools such as :
-SSO provider
-Session Store
-Open Id pattern
-user credentials integration
....
I have used ACL(Spring ACL) to provide authorization services and oauth2 for authentication.
there is one channel to connect these two together and its scopes(oauth2 scopes) but the problem is scopes are not flexible(pure strings) enough to implement authorization modules such as role_voter, cache_strategy, black_list or,Role_base strategy, exceptional permissions, white_list... (but you can use #EnableGlobalMethodSecurity)
In my case I used authorization server as a resource for oauth2 authentication server(take a look at http://projects.spring.io/spring-security-oauth/docs/oauth2.html), then I considered two spots to check authorization, the first I issued ACL to front-end and forced programmer to design her page dynamically up to ACL concept, the second is in back-end on service layer(BLL) using Aspect when one rest is going to be called. I sent the service key as an actee to check if current user has enough access control to do that. and for auditing you must monitor all requests I mean you must use an listener in your gateway or broker...