Reputation: 41745
I'm trying to let two machines with the same base domain (subdomains differ) to share session.
spring-session-jdbc seems to be a solution I could use to achieve the goal.
When a user logs into server-a
, session info is stored in SPRING_SESSION db.
What worries me is the fact that custom org.springframework.security.core.userdetails.UserDetails
class is stored in that db as well.
When server-b
tries to read session data from the db, it has to use the same custom subclass of the org.springframework.security.core.userdetails.UserDetails
.
So I'm copying codes that relates to the UserDetails
class from server-a
to server-b
.
I'm feeling a little awkward doing this, because server-a
and server-b
might want different UserDetails
in general.
Is this really intended way of using spring-session-jdbc
?
Another question is, is it mandatory to use spring-security
for both server-a
and server-b
?
Upvotes: 2
Views: 4972
Reputation: 48893
Default mechanism to persist and load session is through the SecurityContextRepository
(Spring Security) or SessionRepository
(Spring Session).
If you use Redis for session sharing the repository implementation could be RedisSecurityContextRepository
(spring-security-redis
) or RedisIndexedSessionRepository
(Spring Session).
The latter one for sure serialize UserDetails
so you cannot share the session unless you use same Frameworks & user classes versions.
I would use custom SessionRepository
and store shared user info in portable Json or XML, or whatever you like, not the Java object serialized ))
Upvotes: 0
Reputation: 21
In line with Vedran Pavic's answer it sounds like you should be using sso. That said there are instances where different code bases may want to share the same session such as in micro-service clusters. In this case you should simply put your UserDetails into a base jar/module that the other jar/module's are dependent upon. You can use a build automation tool to make this packaging easier to accomplish.
To answer your final question, if these two applications are regularly communicating with each other then I'd recommend either using spring security everywhere or nowhere.
Upvotes: 2
Reputation: 2389
Spring Session is meant to easily enable session clustering, i.e. have the multiple instances of the same app share the external session store therefore making it easier to scale your app.
For the problem you are trying to solve it might be a good idea to use an appropriate higher level protocol such as OAuth 2.0 and OpenID Connect and implement single sign-on without coupling you applications through the session store.
While the idea of sharing session store between different apps might seem convenient initially, such arrangement is usually very problematic, as you noted yourself with the UserDetails
example.
Upvotes: 3