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.
Related
We have an in-house OAuth2 server used by our applications. Now we want to use Windows SSO for our applications but without them to change anything: they'll still reach our OAuth2 server for an access token and the authentication part will be delegated to Kerberos (which Windows use, if I understood properly).
Is there a way to do that?
That is a standard setup and should just require configuration changes in the Authorization Server (AS) - with zero code changes in applications.
Most commonly:
The AS might be hosted in the cloud
It will redirect browsers to an on premise Identity Provider (IDP)
The IDP can connect to Active Directory
You may also need a fallback option for when users are not joined to the work domain. See this Curity guide for an example and some infrastructure factors to think about.
If the AS is in house it may even be able to make a direct Kerberos connection via an LDAP data source, though the preferred architecture is a separate IDP.
Of course you need an AS that supports the ability to make this type of connection, so would need to check the vendor docs.
REQUEST FLOW
Kerberos has always been the simplest protocol conceptually but the deepest to understand - here is a bit of a summary:
Your apps will make a standard OpenID Connect authorization redirect to the AS
The AS may then present an authentication selection screen to the user, unless there is only a single option
Alternatively an app can send the acr_values query parameter to say which authentication method to use
The AS will then redirect the browser to the next stage of processing, that uses a 'Windows SSO authenticator'
The redirect to the Windows SSO authenticator does not have to use OpenID Connect - it could be any vendor specific HTTP request
The browser will send an encrypted Kerberos ticket automatically by connecting to AD - a prerequisite for this to work might be that the domain in the URL is in the Local Intranet zone on end user computers
The Windows SSO authenticator will need to be able to decrypt this credential, which typically requires a Service Principal Name to be configured
Once the Kerberos ticket is decrypted, the authenticator will make an LDAP connection to an Active Directory data source via its standard LDAP endpoints, to verify the received ticket
I'm planning to make a microservices architecture using Laravel as the backend and VueJs or maybe ReactJs as the frontend. The microservices will consist of
User authentication service (For authenticating user)
User management service (To manage organization member database)
Event management service (For creating organization event)
Etc.
All of the services will require user request to be authenticated, but using central user database, which is located on User authentication service. Eventually, on each web application, it will use at least 2 of the services.
How am I able to authenticate the user before making the request to the specified services? Thanks in advance!
Think carefully about your reasoning for developing a distributed system with a microservice architecure. Developing such a system can be complicated and might introduce more problems than it solves for you. You should consider things like code base management, data synchronisation and service availability for example. A standard monolithic architecture with the frontend (Vue/React) and backend (API) as separate projects will be simpler and may provide the flexability you need. Should the need arise in the future to develop a service orientated architecture arise, worry about it then.
That said, typically you wouldn't allow direct access to your services. There would be an API gateway which users access and it proxies requests to the relevant service. So your users would make a request to api.domain.tld/auth/login which would then be forwarded by the gateway to your auth service, process the request and then provide a failure response, or a success response which would include some sort of auth token which would be used to authorise subsequent requests to your other services. Sometimes services are aware of each other and can communicate directly if require, other times they use the API gateway for service communication.
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.
I have developed a web app that does its own user authentication and session management. I keep some data in Elasticsearch and now want to access it with Kibana.
Elasticsearch offers a RESTful web API without any authentication and Kibana is a purely browser side Javascript application that accesses Elasticsearch by direct AJAX calls. That is, there is no "Kibana server", just static HTML and Javascript.
My question is: How do I best implement common user sign on between the existing web app and Elasticsearch?
I am interested in specific Elasticsearch/Kibana solutions, but also in generic designs for single sign on to web apps and the external web APIs they use.
It seems the recommended way to secure Elasticsearch/Kibana is to have an Apache or Nginx reverse proxy in front that does SSL termination and user authentication (Basic auth). However, this doesn't play too well with the HTML form user authentication in my existing web app. Ideally I would like the user to sign on using the web app, and then be allowed direct access to the Elasticsearch API as well.
Solutions I've thought of so far:
Proxy everything in the web app: Have all calls go to the web app (server) which does the authentication, and have the web app issue the same request to the Elasticsearch web API and forward the response back to the browser.
Have the web app (server) store session info that Apache or Nginx somehow can look up and use to authorize access to the reverse proxy.
Ditch web app sign on and use basic auth for everything.
Note that this is a single installation, so I don't really need any federated SSO solutions.
My feeling is that the proxy within web app (#1) is a common generic solution, but it seems a bit heavyweight to have everything pass through the possibly slow web app, considering that Kibana uses the Elasticsearch API directly.
I haven't found an out of the box solution designed for the proxy authentication setup (#2). My idea is to have the web app store session info in memcache or the like and use some facility in the web server (Apache or Nginx) to look up the session based on a cookie and allow proxy access if authenticated.
The issue seems similar to serving static files directly using the web server (Apache or Nginx) while authenticating using a slow web app. Recommendations I've found for that are however very specific to that issue, like X-Sendfile.
You could use a sessionToken. This is a quite generic solution. Let me explain this. When the user logs in, you store a random string an pass him back to him. Each time the user tries to interact with your api you ask for the session Token you gave him. If it matches, you provide the service he is asking for, else, you just ignore his call. You should make session token expire in a certain interval of time and make a new one each time the user logs back in.
Hope this helps you.
I' new in implementing a RESTful web service. I need your opinion to understand if my idea can work. I want take separate the authentication database from the resources database (the main one, with all the user stories). I put them in two different web servers. The clients ask their token to this primary interface (the auth server) that replies the generated token (if login is valid) and at the same time the authentication server sends the userID and userToken to the resources database server.
The client has received the token, it means it's logged in and it can makes requestes of resources to the resources database server. It appends its userToken to prove its identity. The resources database server checks the userToken and if it's not expired, it replies with the requested data to the client.
I've tried to explain the concept with two images.
I would like to understand if this is a good implementation of an authentication process. I really care about the security, performance and flexibility. What do you think about this?
Do you have any suggestions related on this? Thank you very much.