How is the session key/token is maintained for Resful web service, when the main microservice is crashed and the backup service has to run? in otherwords, how the backup service (all) will get the session details?
Best practice for microservices is, to be stateless.
That means, the service should not cache the session key or token. Session details should be maintained in a caching service like Redis.
And each instance of the microservice is equal. There should be no distinction like "main" and "backup" instance. All instances will have access to the redis cache.
A service request should include the token. BTW, the browser can do this for you.
The servicing instance, which could be any, first query the cache for the session details and then proceed accordingly - redirect to login if none found; validate session validity, access rights etc, if a valid token is found.
Related
I am currently building a microservices based application in spring boot with the following services
Auth server (Distributes access tokens)
User service (User info like username, password, email, etc.)
Various other unrelated services
When a user sends their credentials to the auth server, the auth server should verify that they are correct and then return an access token.
My question is, should I combine the auth server with the user service so looking up credentials is a simple database call, or should I keep them as separate applications and have them both point to the same shared database? Is there a better alternative?
What I usually do is keep them separate. Account information (first name, last name, contact data, affiliation, sex etc) is not related to authentication/authorization. Also, an account can have multiple authentication methods (i.e. OAuth, uname-pass, private key), which isn't really related to account data. So, I take them as separate entities. I know auth and account data seem the same, but they represent two very different things, with very different responsibilities, so I keep them separate. If one user should have to see some other user's first and last name, I wouldn't like to get other user's credentials out of the database (a lot can go wrong).
If you are thinking of UserService from Spring Security, it goes with Auth server.
From security stand point, having a single point of truth (auth server) and be able to fix an issue in one place is a huge advantage.
Anyhow, IMHO, account and auth can share some properties, but they are two different things - hence I keep them separate.
Hope this helps.
You should keep them separated, oauth is not related to identity management but to authorization delegation.
In oauth2 there are 4 roles (resource server, resource owner, client and authorization server) you are currently asking if the authorization server must be part of one microservice of the resource server which has absolutely no sense.
If I correctly got your case what you name a user corresponds to the resource owner role in oauth2 terminology, some oauth2 flows (e.g. client_credentials) directly allow a client to get an access to the resource server and there will be no users implied in any way.
I was wondering that session management in cloud environments are available in many options for Microsoft azure/ Amazon Web Services / any private cloud. What I was looking that which is the best session management technique which will fit in all the cloud environments.
I have gone through many site but could not decide which is the most suitable in all cases. I read somewhere that Sticky sessions are also one of the option for session management. So looking for an answer which states that is Sticky sessions are different from cookie based session management?
If yes then how to use it?
Thanks
Ravi
Sticky session are likely to stay on same server when the first request comes and provided from same server for each request. Where as cookie based session are nothing but keeping the data on client machine in browser. can be served from any server which is available.
Yes Sticky Sessions are different than cookie based sessions.
As sticky sessions are nothing but handled by load balancers which handles to get sessions in request from client and passes it to the same server where the first request came to that server. E.g. While loading an website request goes to server A, then sessions get stored on server A, while next request comes from user the request sent to the same server i.e. Server A, irrespective of how many servers present in the farm.
Whereas cookie based sessions are stored on client machine, and it gets added with each new request. So it can be read and supported on any server in farm irrespective which server generated and stored session while first login.
Why sharing session to implement SSO is not good? I'm learning SSO system.
Thinking about this scenes:
Assume that all http requests to business services is required Login, the business services need verify the requests is login or not by asking SSO service in CAS or SAML. If there are 10 business services, and each service's request is 1k req/s, so the SSO service's request is 10k req/s. It's hard to image the SSO service can hold on.
SO, may be there is a cache mechanism in the business services to verify login token. But when user logout, the SSO service need remove the verify info, and the business services need remove the cache verify info also. I think that's too complicated. The SSO service need tell the business services some people was logout. So why don't all service sharing the login token verify info? Let SSO service write, and other business read. It remind me the sharing the session to implement SSO. And I thought if I can sharing the login token verify info by redis distributed cluster. But I have hear sharing session is not good? So why?
Whether the SSO server can handle that many requests depends on your deployment of it. There are very large deployments of CAS that handle hundreds of thousands of requests. It varies.
In general, the SSO session is entirely separate from your application session. Once you have logged onto the application via SSO, you have established a session for that application that will last for as long as you configure it to last. When it expires, your application may decide to authenticate against your SSO server again. If the SSO server has still an SSO session, it will simply re-issue the appropriate data and your app will recreate the session. If not, it will challenge the user for credentials, whatever they may, and redo the same.
Session concerns of the application are entirely yours and application's concerns. The SSO server should never get involved. If your application has a requirement to share sessions because it's clustered, then you should share sessions. Nobody said it's a bad idea. However, you generally want to make sure your application is as stateless as possible since that will make clustered deployments easier.
When you log out from your application, your app session is gone, but the SSO session may still exist. As a result, you will get right back into the app because there is no need to provide credentials. If you wish, you could log out of the app AND your SSO server.
If you have all other applications logged in via SSO, and you wish to log out of all by logging out of one, this is called SLO. Your SSO server will need to reach out to every app that it has created a ticket for and contact them to logout. Or, you could destroy the shared sessions for all apps assuming they are all part of the same suite.
I would like to use Spring OAuth2 with a load balancer.
I was thinking that if I use
authorized-grant-types="password,authorization_code,refresh_token"
I will just need a JdbcTokenStore and am good to go because each spring server has access to the same DB.
But now I am reading in this github link
Even with these (Jbc) services ... needs to be fronted by a load balancer with sticky
sessions
Why do I need Sticky Sessions with a JbdcTokenStore?
Any session-based interaction would need sticky sessions, since the session data is not shared between servers. For example, when you authenticate the user during the authorization code flow, they are authenticated and a session is created. If you weren't using sticky sessions then the authentication information might be lost between browser interactions with the authorization server. The session will be used to cache their initial request while they are logging in, and will also retain the authentication information while the user checks and authorizes the scope requested by the client.
First this app works perfectly fine in a non-clustered environment.
The problem we have is when the ELB routes first to one server in a cluster during a session, then to a second server. The second server can't find the session. e.g.
An iOS app passes a login call to a Glassfish 4 server cluster (we're using oAuth/Facebook tokens, so no Glassish security realms).
The Amazon Elastic Load Balancer (ELB) sends to server 1.
Session is authenticated and user logged in and a session cookie passed back to the app.
Immediately the app sends another request which needs authentication (is this a valid session).
The ELB decides to send the request to server 2
In our authenticate servlet filter, server 2 can't find a session with the id passed in with the cookie
The servlet says the user is not authenticated and the call fails.
Our code is pretty typical for finding the session (if no session immediately return fail):
HttpSession session = req.getSession(false);
//psuedocode
if session == null then session not authenticated log and return
else session authenticated, log and return
If the second call gets routed to the same server as the login, the second call works fine. Whenever a call (be it the second, third, fourth, whatever) goes to the second server, authentication fails because it can't find the session on the second server.
I'm looking to see if anyone has encountered something like this and how you have resolved the issue. Is it better to use sticky sessions on the ELB, or is Apache web server using JK or AJP a better choice?
Two potential issues off the top of my head:
Have you specified <distributable/> in your web.xml?
Could be a multicast issue. EC2 does not support multicast, which is what GlassFish uses by default. Check out this stackoverflow thread that discusses the topic, including non-multicast clustering.