Crowd SSO seems to require that users be exposed via the same Crowd-Directory. Is there a way around this?
In other words: Can the same user which lives in LDAP under a single account but exposed through different Crowd-Directories still have SSO work?
The reason:
We run multiple Atlassian apps - 5 Confluence instances, 1 JIRA, others apps like Alfresco which all use Crowd.
We want to centralize users into a single LDAP instance but allow only certain users to use certain apps.
Our solution to this was to create a separate Crowd-Directory for each application which can see only users that are part of certain groups. This filtering is done through LDAP filters.
This solution means we have a different Crowd-Directory for each app.
The problem here is that Crowd SSO doesn’t work for user ‘clark.kent’ when that user logs into Confluence but then switches to JIRA because those Crowd-Apps are using different Crowd-Directories.
I’ve tried to explain that as clearly as possible but it’s a bit complicated as the picture demonstrates.
To reiterate the questions:
Is there a way around this or a different scheme which would achieve SSO and user silos (users span one or more apps)?
If no answer to #1 then how might we customize Crowd to achieve this?
In this example Clark Kent can access App1/Confluence only
mary.jane can access app2/JIRA only
peter.parker is a member of both groups and can access both
peter.parker does not have SSO because he is exposed to different Crowd through different directories.
-----------
Hi Colin, Thanks for having a look. I'm adding more explanation here since answers.atlassian.com wouldn't let me write what I needed to - char limit.
Yes there are several reasons that groups alone don’t cut it but here are the top three that come to mind:
* Controlling access at the application level (which is what you would have to do) means that any admin of that app can see all users and groups and subsequently access all applications.
* Doing this would mean you’d have to set up artificial conventions so that group names between applications don’t accidentally overlap. You couldn’t have “cool-users” group for application-A and “cool-users” group for application-B since all members would inherit access to both apps possibly unexpectedly.
* We have many Confluence instances and the Confluence people directory can see all users in a directory.
Bonus reason: Confluence hardcodes the group name “confluence-users” to have special properties. Because we have multiple Confluence instances this would mean we can’t have separate sets of users. I did experiment with database-updates to change this but it’s messy and could break upon upgrade to change that way.
Does that make sense? It’s not a particularly obvious issue unless you’re dealing with multiple applications and want sets of users shared across some but not all of those applications.
I’m attaching an image for another view of our ultimate goal - to have a single user base and be able to select which applications know about which users. Perhaps there is another way to do this, but we’ve not found one.
