Supporting single user with multiple concurrent logins

[alon]

As what I am trying to do is pretty specific let me briefly outline the use case.

We have a CMS framework that can be embedded in a web application to manage the content for that web application. The CMS uses ACEGI to manage user authentication/authorization through both form (user with web browser) and BASIC auth (user via remote client/webdav).

We would like to also use ACEGI to manage security for the non-CMS web application features - e.g. I log in as a customer of Foo Corp to see my account details.

The use case I want to support is:
1. I log in as a CMS admin and make a change to the Member News page
2. I view the webapp homepage as a non-logged in user
3. I log in as Joe Member to check my change on the Member News page
4. I go back to the CMS to tweak my change

In the webapp, /cms/* contains all CMS features and requires login as a CMS user. All other URL prefixes require no login or require login as a site user (not CMS user).

I've investigated doing this with ACEGI (0.8.2) and it appears that this is not possible without at least customizing HttpSessionContextIntegrationFilter to allow storing the SecureContext in a different place for the CMS and site.

It seems that this would work since user requests would be either to URLs that deal with the CMS secure context (/cms/*) or the site's. Since each request is a separate thread, the SecureContext stored in ContextHolder and used throughout the application would be either the CMS SecureContext or the site's depending on what the user was doing.

Our application would end up with 2 ACEGI configurations - one for the CMS and the other for the site.

Any obvious gotchas to this approach?
Any recommendations for alternate approaches?

This would mean making a lot of changes to HttpSessionContextIntegrationFilter.doFilter() simply to make the value configurable for the session key under which the SecureContext is stored. Is this a change that ACEGI could use as a feature? I'd be happy to contribute it back though it's obviously not a tough one for the developers to support themselves.

Alon

[Ben Alex]

Do you really need to modify HttpSessionContextIntegrationFilter? I would suggest you could get by with a more intelligent AuthenticationDao that distinguishes between CMS logins and Joe Members. Different GrantedAuthority[]s are then returned reflecting the principal's authorities.

You then use the standard FilterSecurityInterceptor.objectDefinitionSource to define the URLs that are allowed be accessed. As a CMS, you'd probably want to make the objectDefinitionSource available from a database instead of solely the Spring IoC XML. In that case you'd write a custom FilterObjectDefinitionSource implementation that retrieves the authorization requirements from the database.

[alon]

In this case, the CMS needs to run without interaction with the 'site' authentication. The CMS is not responsible for managing the authentication mechanisms of the deployed content. Writing a class (such as AuthenticationDao) that understands both the CMS and the 'site' structure or content breaks the model of the CMS providing content management services but nothing more.

We are moving toward having the CMS run entirely as a hosted CMS interface with content delivery through remote services which will take care of most of our issues managing separation.

I have gone ahead and made the HttpSessionContextIntegrationFilter change I mention above and it is working very well for our needs at this time.

Alon

[tortuga]

Why don't you simply store the users in the DB with a 'cms_' prefix to their names, and prepend that prefix to the user name when the user logs in? That way, a user can log in with the same user ID to both CMS and the rest of the site, but underneath your app prepends 'cms_' for the 'cms_' login? This creates the separation of sites you sound like you want, because really you then get two separate accounts.

[Ben Alex]

Why don't you simply store the users in the DB with a 'cms_' prefix to their names, and prepend that prefix to the user name when the user logs in? That way, a user can log in with the same user ID to both CMS and the rest of the site, but underneath your app prepends 'cms_' for the 'cms_' login? This creates the separation of sites you sound like you want, because really you then get two separate accounts.

We do something similar in one of our apps. Our "party" table has separate subscriberId and a loginName columns. Our AuthenticationDao then tokenizes the username String based on a "/" separator between the subscriberId and loginName. We use Luhn numbers to do a bit of a sanity check on the subscriberId before we check the backend database, and also consult a ThreadLocal to ensure the request is currently being rendered by a virtual server assigned to that subscriberId. We've found it a practical solution which requires next to nothing apart from an intelligent AuthenticationDao.