SSO for users that come from different Crowd directories but are the same user?
Asked by Brendan Patterson:

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?  

<br />

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.  

<br />

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?

![](https://img.skitch.com/20110623-bgnd79ws15m5ukjfyyarspihra.jpg)

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](http://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:  

<br />

\* 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.

![mockup](https://img.skitch.com/20110628-xrhakg3u4bu3q64j4iae5etgb2.jpg)


Answers:
author: Masiuddin Mohammed
body: Did you got answer to your question? If yes, how it was implemented?

comments: author: Brendan Patterson
body: No, never did. We had to live without SSO


author: Colin Goudie
body: 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\>  
\</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!

comments: author: Brendan Patterson
body: 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.


author: Colin Goudie
body: Also, what are you using for crowd alfresco.


author: Colin Goudie
body: 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

comments: author: Brendan Patterson
body: 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.


Tags: directory

sso