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.
Did you got answer to your question? If yes, how it was implemented?
No, never did. We had to live without SSO
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sounds like your concerns are mostly valid. However with this
<address> 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. </address><address>Apart from the admin of an app seeing all the users/groups, he still can't access or allow any user to access another app as that would still need to be done via crowd.
However, to fix the user/group visiblity issue we need lots of people to vote on https://jira.atlassian.com/browse/CWD-432
I have no idea why it is implemented the way it is. Bizarre!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Colin, Good points. Thanks for that issue - it's similar to mine except that 'per user' allocation would be ideal as it is what we are trying to achieve.
Apart from the admin of an app seeing all the users/groups, he still can't access or allow any user to access another app as that would still need to be done via crowd.
Actually an admin for any app could potentially do things like reset a password for users of other apps, add themselves and others to groups, etc. if they can see everyone.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Brendan, Is there a reason why you can't just use groups for this? Using 1 directory but only certain groups from LDAP are able to 'use' the various applications? Or am I missing something
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Colin, I had to add my answer to the question itself since my answer blew through the a.a.c. character limit by 857 characters :) So you can see the answer in the second half above.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.