Does AWS QuickSight limit a single author user to a single session at a time or can they have concurrent sessions?
I am not developing yet. I need to understand if there is a concurrent session limit for my firms security purposes. I'm not sure why it would matter if AWS scales, but I don't want our users to be able abuse the relationship. I see nothing in the documentation regarding concurrent sessions. We could limit user sessions in our SSO process. Maybe that is the answer if having concurrent sessions is a problem.
Related
I need to create a scheduler for my own SaaS, and I'm trying to understand whether Google Calendar API is a fit for that. Basically I could have hundreds of thousands of calendars. Each calendar may be a user of my service, but not a Google user. It seems that perhaps I could use resource calendars under my Google Cloud service account. My biggest concern is whether my usage will fall within the Calendar API's service quotas, either automatically or by requesting a quota increase?
Yes service accounts will fall within quota usage limits. There is also a limit about creating more then 25 calendars in a day causing the user to end up in read mode for the rest of the day.
pricing
Google Calendar API Usage Limits
The Google Calendar API has a courtesy limit of 1,000,000 queries per day.
To view or change usage limits for your project, or to request an increase to your quota, do the following:
If you don't already have a billing account for your project, then create one.
Visit the Enabled APIs page of the API library in the API Console, and select an API from the list.
To view and change quota-related settings, select Quotas. To view usage statistics, select Usage.
On the one hand, you could work around the quota issues by sharding your users across multiple Service Accounts. You would probably also want to shard them across multiple App IDs.
On the other hand, don't do it. In my experience, using Google APIs outside their intended use case doesn't end well.
I want to design a database for a student portal. I want to create a student role, so for every student I need to create a user and assign the users's role. It seems like many users will be created. Could there be any problem such that large resources will be needed.
The number of user accounts is not the issue - you can create as many as you think you need. The issue that is of more concern is how many concurrent user sessions - users logged into the database at the same time - will there be? Each user needs memory to do their work and this must be allocated. If you have more simultaneous user session than memory can accommodate, this can be a problem. Read more here and here. If you will have a huge number of concurrent users, consider a shared server connection setup, rather than the default dedicated connection.
Another thing you need to be aware of is the financial cost implications depending on whether you have a per user licence.
However as others have already mentioned applications usually connect to the database using a single set of credentials, end users are not usually defined as database users, and therefore you would not be able to use the database defined roles to differentiate between the permissions.
You could likely have two database defined roles DBA or SYSADMIN, and PORTAL_APP.
The end user roles would need to be handled within the portal application, and this should be consistent on the front-end and the back-end of the application.
My server needs to log-in to another server (for accessing payment API). Result of successful log-in operation is a session token that is valid for 25 minutes.
Where can I store this session token so that it is available across multiple requests and multiple users? (i.e. user session is not an acceptable solution).
I need some sort of an application state or cache storage.
Just to demonstrate the problem - a file could be used to store this value, but I don't want to deal with concurrency, and security implications this solution comes with. I would prefer an in-memory solution.
You could use either the core JSession or JCache framework objects.
http://docs.joomla.org/JFactory/getSession
http://docs.joomla.org/Using_caching_to_speed_up_your_code
http://docs.joomla.org/Cache
I have three client-facing web applications all on different subdomains (one of these web applications actually has 700+ different subdomains that are changing all the time). I've written an oAuth server that I was going to use to allow users to login to each of these systems; this works, but I've begun running into differences between what's happening and what I would like the behavior to actually be when writing the logout code.
Some of my requirements for single sign-on are:
If logged in on one system, you are logged in on all systems (obviously).
If logging out of one system, you are logged out of all systems. Even across subdomains.
If you are logged in on two different machines, for example -- a cellphone and a desktop. When logging out on your cellphone, do NOT logout on your desktop.
We already have written the oAuth provider and we'll be using it for projects not coupled to our domain (API's, etc.), but I'm not entirely convinced that oAuth is the best solution to use to meet the requirements outlined above. I'm thinking that maybe a shared session would be better. The shared session idea would involve a cookie stored on the main domain that has information about the currently logged-in user.
What are the pros and cons of either approach? Are there other approaches you might take? Are there security risks to consider? Concurrency and scalability considerations? Please help!
I would have taken oauth route with a variance.
Oauth :
The approach I would prefer is - access token issued at a device level (User- Application/Device) .
Ie there will be a process for registering your device and granting access for it.
This will result in the generation of an access token specific to the device and stored in it as the case may be. (For eg:- for mobile you may need a longer expiry access token and webpage a lesser duration one).
This way you can decouple the login/log-out across devices.
However the con of this approach is:
More complicated implementation, as it involves device registration
Tracking the action of each user will be difficult as you have two or more access token tied to a user.
Pros :
This is a fairly standard way
The Con 2 can be worked around (Adding access token attributes etc).
Session based SSO management
Pros :
Simpler than OAuth
Cons :
Security constraints around -session/cookie handling
Extendability at later point to add more use-cases is limited
I've had 2 sysadmins from 2 large hosting organizations tell me that Varnish will handle session sharing between web servers. I can find nothing online to support this and in fact found this where the guy specifically says it does not. I cannot tell if the guy is a Varnish employee or just a contributor or what.
Just looking for more verification on this point.
A session allows you to store many things (shopping carts, logged in user, etc), and is commonly identified by a cookie (e.g. sessionid). A web server knows how to get a session using this sessionid (and can access/update your shopping cart), but varnish only handles cookies. Varnish can do load-balanced lookups to backends, regardless of the cookie values or based on some rules (you need to write you own varnish config).
However, a challenge in session sharing between web servers is whether a web server can access sessions created/updated by another web server. In many Java Web Containers, sessions are by default stored in memory (of only one web server), with load balancers implementing some kind of 'sticky session' mechanism (sending a user with a session to a specific back-end all the time, can be easily setup with varnish). Another option is to store the (serialized) session values in a shared database, so they can be retrieved by any backend (and will keep working if a web server goes down). A third option is to completely serialize the session into a cookie and stop using sessionids, but this is complex (limited size, bandwidth, security requires some signing mechanism, but scaling is great).
All approaches have advantages and disadvantages. You have to choose, varnish supports any option but will not 'automagically' do what you want, so prepare to write a bit of varnish configuration...
If you would describe how you want to load balance, or what you try to achieve, you could get a more specific answer.