I maintain a plugin (driver) for interfacing with the Ecobee servers for the Indigo Home Automation system (https://www.indigodomo.com). We have many users using the plugin, with no problems. Except for one...
This particular user is the only one (that I know of), that has two separate instances of the Indigo system, at two different locations, both using the same Ecobee account. So there's two "clients", both installing the same "app", using the same credentials. The plugin uses the PIN based authentication method.
He randomly looses authentication at one location or the other. When that happens, it's usually with an invalid_request return code. We've been digging into this for a while, and it appears that both installations are getting the same access_token and refresh_token, and then one of them does a token refresh, gets a new refresh_token, and the old token doesn't work at the other location.
So my question is, is multiple instances of the same "app" with the same user account supported? Or is the server not differentiating between the two and providing the same credentials to both clients?
Related
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 a single web application that's used by multiple customers that have their respective URLs.
We're in the process of integrating google accounts via Google API with OAuth2.
Right now we have a single project/application registered that's used by all systems.
The problem is if same account is connected on multiple systems, token is overwritten since there is a single project. Same thing if account is disconnected from system A and it's also connected on system B, system B stops working because Google API project/application is the same.
I'm wondering if there is a workaround to have multiple tokens/connections per account with a single application, or the only way to accomplish that is having one project per system and I'll need to programmatically create a project and setup everything accordingly when a new system is built.
So, I have multiple grails apps, but I'd like to package them into a single mega app that manages user login, permissions, which appscan they access, etc. I can already links to the other apps depending on the logged in users role.
I'm using Spring Security with all of the apps, and they already share a database for users and roles. The problem I'm having is that I want the users to be instantly logged in on all of the apps when they log in into the "mega app", I want them all to share a login session.
Right now, I have a login for the users to access the "mega app" where they are linked to the other apps, but they have to manually log in again for each of the different grails apps they are linked to. And I don't like this, I want all apps to share a session, atleast for login. Any way to do this?
Having all the source from all the apps inside one single grails project is not a possibility here, it would be too heavy and some users don't even install all of the apps, since this is installed on their own private servers for them to use in their own local network. Also, login sessions time out after a while of not being used, making the problem even worse.
Help would be greatly appreciated, thank you in advance.
The spring-security-cas plugin is one option; it uses the open source CAS single sign-on server to let you authenticate to any server and be automatically authenticated on all of the others.
I'm trying to use the Social Business Toolkit in Java code on a Connections server to post to users' Connections activity streams.
By default, Connections doesn't allow any user to post to another user's stream, and this restriction applies to my code.
I already know how to configure the WidgetContainer application in WAS to trust individual users to post to other users' streams, but that requires either that all users are trusted or our code is somehow made to run as a special trusted user. The former is undesirable due to the potential for spam, and the latter is undesirable because we have to configure login details for the special user in the application.
Instead of trusting users, is there any way (either through the SBT or with WAS/Connections features) to make Connections trust our application to post to users' streams, even when it authenticates as a user who is not otherwise trusted to do so?
No. Generally, you need an Application Specific User as you noted in your WidgetContainer reference. What I do is create a new Connections User, MyApplication, I grant that user the trustedThirdParty Applicaiton role.
Today, this method is the only one promoted.
We are working on a service that will have website access for stats and other tasks, but the majority of use will be through a client gem and rake tasks. What is the best way to handle authentication for both pieces.
It looks like fiveruns_tuneup, getexceptional, New Relic and others have websites with username and pass, but use API keys stored in ./config/serviceName.yml Any reasons it is better to have API keys opposed to user/pass in the config (do they use keys because often the key is checked into SCM and used across the project, where ours would not be checked in and would be a per user setting)
GitHub has you put your public key on the github servers and uses that, but I think git supports public/private key by default.
Would it be preferred to keep a ./config/serviceName.yml or since we have to create a subdirectory with other information have ./serviceName/config.yml? (does the per user, not stored in SCM mean it is better to keep it all in one excluded directory?)
Just looking for some thoughts and ideas on best practices before starting implementation.
I recommend that you use username/password combos for website accounts, and API keys for any web services. Here are the advantages of this technique:
By linking API keys to an account, you could have many API keys for the same user. Perhaps this could be used for many remote web servers that consume this data service, or to perform unique tracking.
Attaching API keys to an account also lets you keep the user's username and password uncompromised since an API key will not contain them. Many users use the same username and password on many services, so you are helping to protect them.
You could limit access to portions of functionality for each API key, but give their username access to everything their account should have access to. Additionally, you can even give them the ability to limit how much access an API key might have.
Most of the major services (Yahoo! API, Flickr, Google API, etc) use accounts with a username and password to login to the web account, and API keys for integration points.
Never use user/pass when you can help it. The security issues are horrible. If the user/pass leaks out, you have to change your password or they get access to your whole account.
API keys are better because they're easier to change and can be limited to only the part you need access to with the APIs (ie, if someone has your password they can change your password. They can't if they just have an API key).
Different API key per client or secure token exchange (such as OAuth) is the best solution if you'll have more than just your client on the API.
The github approach is bootstrapping on top of existing git practices, however it's not a bad idea since presumably each user will have their own private key to match a published public one in the central authority. Since key-agent's already furnish a means of safe authentication this seems like a very safe approach. Public/private keys are a well thought out authentication scheme, which has unfortunately been reinvented many times to limited success.
The problem with the API key is that anyone who gets a copy of the API key can do whatever that authorizes. Storing the API key somewhere in the project begs the users to share a key. If you are associating public keys with a user, it is possible to grant rights to the client on a per user basis, and a proper key-agent approach suggests that those will not be stored in an SCM anywhere.
I'm not sure I follow what the distinction between config/serviceName.yml, or serviceName/config.yml is. It doesn't seem as if it would be pertinent if you have public/private keys as an authentication method for the client.