Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

SSO for users that come from different Crowd directories but are the same user?

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.

mockup

4 answers

Did you got answer to your question? If yes, how it was implemented?

No, never did. We had to live without SSO

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

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.

Also, what are you using for crowd alfresco.

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!

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.

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Data Center

Introducing Data Center Community licenses

I'm Alison Huselid, Head of Product for Data Center at Atlassian. As we shared in our last post, we’ve been working on a solution for those of you who work for charitable non-profit organizations tha...

770 views 10 45
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you