I´ve started using spring session successfully with one nginx, two tomcats and one redis server to implement clustered sessions and some questions have arisen.
First of all, I mean two completely applications when I talk about different applications, I don´t talk about two instances of the same application.
May I use two or more different spring-session applications to store sessions with only one redis server in production?
These applications can run in different tomcats instances?
How Spring session avoid session id conflict between different applications with one redis server?
Is it necessary to append suffix or prefix id to avoid this problem?
Spring Session does not natively support for scoping sessions at this time. See gh-166 for details on tracking this.
Spring Session generates a secure random id with high level of entropy for session id's so there is extremely low probability that you will get collisions.
This means that you can use the same Redis instance for multiple applications using Spring Session so long as you are ok with the following statement:
A malicious user can use Application A's session id with Application B. Why is this important? Consider the following scenario:
Application A is a public application which any user can create an account for.
Application B is a private application which only users who are invited can sign up.
The malicious user creates an account and authenticates with Application A
The user copies their session id for Application A. They navigate to Application B and paste the session id into their cookies for Application B and are now authenticated.
This might not be a problem for you. For example, good security practice would ensure that the user is properly authorized by looking for an ADMIN role in Application B. Application A would not populate that role, so while the user is authenticated with Application B they are not authorized to use it.
Related
I have a spring boot application, I'm not really sure how users and threads work
The number of users depends on the application itself or tomcat?
Can I have more than 100,000 users at the same time in the application? What does it depend on?
How can I control the application so that there are no problems with the number of users at the same time?
It depends, my mate!
There are basically 2 most common ways of securing your web application: stateless and stateful.
If you're using stateless (For example JWT, which contains all authentication & authorization information), and every single request is re-authenticated & authorized when it reaches your application, and you don't have to store it anywhere, then you can basically have an infinite number of users logging in at the same time.
If you're using a stateful way to do this (For example the session-id, which is just a random string), then, in this case, you HAVE to store the session data somewhere, so that when you see that session-id in the request, you can use it to retrieve the current state of that session. In this case, it depends on your storage.
I have 2 applications : the first one is written with ruby (It's redmine) and the second one is a Spring boot app and both are hosted on the same tomcat server.
How can i do that?
Sharing sessions is not allowed. By (servlet spec) definition, a session belongs to a single web application.
Reference: Servlet Spec 4.0, section 7.3:
HttpSession objects must be scoped at the application (or servlet context) level. The underlying mechanism, such as the cookie used to establish the session, can be the same for different contexts, but the object referenced, including the attributes in that object, must never be shared between contexts by the container.
There are ways you can probably work-around this limitation by setting-up shared caches, etc. but it will always be brittle and potentially dangerous from a security or resource-usage perspective.
User database or user data file(nosql) with use of a unique-user-auth-token, accessible by two apps (or 3, 4, 5 ...)
Global concept :
App request connection :
is exist "old auth token" in app storage ?
yes -> app send old and request new or same if not expired
no -> continue
is exist valid auth token on server ?
yes (an app is already connected) -> send validated auth token to app
no -> set new auth token and send to app, new AT is ready for other app
server store what app request connection and is connected
apps are now able to exchange datas via the server.
Sharing Web applications is, at a minimum, Bad Practice (TM): Web Applications are completely separated by design. If both applications easily could reach into each other's session: Imagine what would happen if one would overwrite values that have been set by the other, and both applications expecting different data under the same key name.
If you only need single-sign-on, there's a SingleSignOnValve available that will make sure you'll only need to sign in once (provided that you authenticate through the container, e.g. a Tomcat Realm). Check server.xml for the commented-out-default-value, or the documentation for more information on authentication and the valve.
You might work around it by implementing the UI in both modules and refer back to a common business logic, but this is a level of architectural change too broad to fit into this answer.
I have 3 laravel Applications with 3 databases.
Application 1 is the Login for authentication (Registrations and Login) and is only connected to the users Database .
Application 2 allows user to perform some basic operations and is connected both to user and App2 Databases
Application 3 allows users to perform some other operations different from application 2 and is connected to users and App3 Databases
Now my problem is to allow a user looggin once through Any of the applications and is automatically logged in to other application
More like having a single google account that works in all apps.
Application 1 will be access through the main URL
www.kokoka.com
while others will be access through
health.kokoka.com
school.kokoka.com
I have tried
https://github.com/awnali/SSO-laravel-5
I have also changed the Domain in session.php
'domain'=>'.domain.dev'
all to no avail
You need to set the session file to database and everything related to sessions should be identical. Basically the session.php file should be the same between both, they should have a common database, and the key and cipher type should be identical.
If they have the same domain name (ex: server1.mydomain.com, server2.mydomain.com) but different hostnames/subdomain names, then the cookies should still work fine as long as you set the domain correctly (ex .mydomain.com). If they are on the same server, you can still use a common key-value system. If they are on separate servers, you either need a common storage location (like S3) or a replication enabled key-value system like Redis or Memcached. You could also use MySQL if you need to replicate other data types, but it's very heavy for just key-value pairs.
If they have completely different domains, then cookies will not work. In that instance, you would need to reference cross-site session ids through GET query strings, and perform session migrations in the back-end using either common or replicated systems, or via some secure API. This is a very difficult system to setup and only works if you are moving between the domains using links embedded in the sites. Bookmarks or manual address input will loose session data.
Another way to acomplish what you need is to use the new funcionality of laravel passport.
Laravel already makes it easy to perform authentication via traditional login forms, but what about APIs? APIs typically use tokens to authenticate users and do not maintain session state between requests. Laravel makes API authentication a breeze using Laravel Passport, which provides a full OAuth2 server implementation for your Laravel application in a matter of minutes. Passport is built on top of the League OAuth2 server that is maintained by Alex Bilbie.
This will let you share data across multiple domains through an API so you can share the session and user information. This is the way most people prefer.
The stateless web application seems promising. How to make one? Especially with Spring WebMvc? Any guidelines?
Here are a few things on my mind:
Avoid creating session
Use a centralized storage for state info and share that among web application instances.
ADD 1
I think it is not a question of whether to keep state info or not. State info is always necessary if you want to do something useful. It is actually a question where/how to keep the state info. This article is useful. It mentioned in-proc/out-of-proc session, data cache, and why not to use session.
Related:
Use Spring MVC for Stateless web application development (no response yet)
Stateless Spring MVC
How to make a java web application fully stateless
How do I make my Web Application stateless yet still do something useful?
http://brockallen.com/2012/04/07/think-twice-about-using-session-state/
Here are some contributions. I'm not familiar with Java and Spring, but I believe these guidelines are valid regardless of your technology stack.
Stay away from sessions for authentication
As you anticipated in your question, avoid using a session to authenticate users. Sessions are peremptory and it's very difficult to replicate it consistently in a distributed, scalable infrastructure.
Also, load balancers don't work well with sessions: see Problem with Session State timeing out on Load Balanced Servers.
Use a token-based authentication system
A stateless app will preferably use a token-based authentication system. Firebase is a good example. Map the immutable user ID extracted from the token to the user data persisted in whatever storing mechanism you want to use. Since this user ID won't change, you'll be fine in a distributed database.
Don't confuse stateless with 'data persistence'-less
Sometimes people think that, by mapping a user ID to user data in a database, you are making a stateful app. It's not true. Let me make it clear:
An application that persists user information in a database and has dynamic responses for authenticated users IS NOT NECESSARILY STATEFUL. Stateless means the app won't have to distribute mutable authentication sessions across multiple servers and won't change its internal state to a particular client depending on session data.
The trick of stateless is: once a user validated its token by logging in, the server don't have to distribute anything new across the database servers and it won't change its state to that client. It can extract user info from the token and carry out what's needed to answer the request. If the token expires, the client will require a new authentication, which will generate a new token, but this is isolated from the app server, since the user ID will remain the same.
Use cookies for caching while remaining stateless
If caching in cookies some frequently requested data will improve performance, that's fine, go ahead and cache. Just make sure the cookie isn't connected to any server state and your app will not break if the client loses the cookie.
I am trying to setup an control server application with Spring-JPA back-end and Restful web services to expose the back-end methods. My user sessions and authentication/authorization has to be handled through the back-end control server. The entire application has to be setup in clustered environment with user session replication.
I'm not able to figure out which mechanism to use to store the sessions, since the Restful Web services are stateless. I will generate a unique session token for each user session and store the session token and user attributes map as key-value pairs.
I cannot use static Maps and ServletContext to store the user session because the session replication is not possible.
One alternative is to store the user session in the Database.
Please suggest me if there is any other way by which this is possible.
Thanks,
Hari
You probably can use Cookies to store/read the session attributes. Other alternative might be to set them as URL parameters (if feasible).
on separate note, idea to store the session in DB and pass the session id across requests sounds like good plan.