Uploaded image for project: 'Crowd Data Center'
  1. Crowd Data Center
  2. CWD-1348

Client applications should only see principals which have been authorised to access the application

    • Icon: Suggestion Suggestion
    • Resolution: Duplicate
    • None
    • Core features

      Currently, a client application can "see" all the principals in the directories configured for that application.

      Ideally, if Allow All To Authenticate on a directory is set to False, only the principals that belong to the configured groups should be visible to the application. If Allow All To Authenticate on a directory is set to True, then the current behaviour of retrieving all groups is acceptable.

      In addition to the SSC findAllPrincipalNames() method, there should be some sort of findAllAuthenticatablePrincipalNames()

            [CWD-1348] Client applications should only see principals which have been authorised to access the application

            Hi folks,
             
            Thanks for your continued support and feedback, we wanted to give you an update on the status of this issue.
             
            Back in April 2011, We closed this feature request as "Won't Fix" as it was not the direction that our product team was heading then.
            Recently, we reviewed this feature request and it seems like something our product team would like to explore on.
             
            For the sake of preserving the ticket history, we will keep this feature request ticket closed and ask you to cast your votes in the newer ticket, so we can measure the impact and interest of this feature more accurately.
            Here's the newer ticket:

            Regards,
            Monique
            Atlassian Support Team

            Monique Khairuliana (Inactive) added a comment - - edited Hi folks,   Thanks for your continued support and feedback, we wanted to give you an update on the status of this issue.   Back in April 2011, We closed this feature request as "Won't Fix" as it was not the direction that our product team was heading then. Recently, we reviewed this feature request and it seems like something our product team would like to explore on.   For the sake of preserving the ticket history, we will keep this feature request ticket closed and ask you to cast your votes in the newer ticket, so we can measure the impact and interest of this feature more accurately. Here's the newer ticket: CWD-5145 Only users who have access to applications connected to Crowd should be synchronized from Crowd to those applications   Regards, Monique Atlassian Support Team

            This absolutely needs to be reviewed, I am shocked that this will not be fixed.  I echo all of the previous comments made on this subject!

            Simon Dixey added a comment - This absolutely needs to be reviewed, I am shocked that this will not be fixed.  I echo all of the previous comments made on this subject!

            Oliver added a comment -

            As described in our support ticket (which was closed), the current implementation is an issue and we are not requesting an enhancement but a bugfix.

            Atlassian does not seem to be aware that we have a GDPR?

            https://gdpr-info.eu

             

            Oliver added a comment - As described in our support ticket (which was closed), the current implementation is an issue and we are not requesting an enhancement but a bugfix. Atlassian does not seem to be aware that we have a GDPR? https://gdpr-info.eu  

            This is an absolute blocker for us as well. I'm not sure how it can be set to Won't Fix

            Craig Castle-Mead added a comment - This is an absolute blocker for us as well. I'm not sure how it can be set to Won't Fix

            We are trying to transition from the external/cloud instance of Hipchat to an internal Hipchat server for HR/auditor compliance reasons and this issue with Crowd is killing us.
            Back in 2011 you put this issue off for 18 months while you worked on "scalability, reliability and performance" (thank you for keeping us in the loop). Crowd, for our needs, meets all three of those and we're trying to maximize it's capabilities for more products (like HipChat Server).
            HipChat, which is an Atlassian product, does not support the concept of groups or user management in any meaningful way, so using Crowd to determine which users can be seen by the application is a requirement to manage the application, not a want-to-have. Right now we're doing a kludgy work-around suggested by Atlassian support but this feature request in Crowd is the favored fix by Atlassian. So, Atlassian right hand, meet Atlassian left hand. Please re-open this issue (so we can upvote it at least), and hopefully it can get put in your backlog & prioritized (and communicated to us users!). Thanks!

            -Kelly

            Kelly Schoenhofen added a comment - We are trying to transition from the external/cloud instance of Hipchat to an internal Hipchat server for HR/auditor compliance reasons and this issue with Crowd is killing us. Back in 2011 you put this issue off for 18 months while you worked on "scalability, reliability and performance" (thank you for keeping us in the loop). Crowd, for our needs, meets all three of those and we're trying to maximize it's capabilities for more products (like HipChat Server). HipChat, which is an Atlassian product, does not support the concept of groups or user management in any meaningful way, so using Crowd to determine which users can be seen by the application is a requirement to manage the application, not a want-to-have. Right now we're doing a kludgy work-around suggested by Atlassian support but this feature request in Crowd is the favored fix by Atlassian. So, Atlassian right hand, meet Atlassian left hand. Please re-open this issue (so we can upvote it at least), and hopefully it can get put in your backlog & prioritized (and communicated to us users!). Thanks! -Kelly

            shihab added a comment -

            Crowd allows a client application to query for all users that exist in directories mapped to the application.

            In some cases applications (such as JIRA/Confluence/Bamboo) need the ability to see all users and groups, not just those that are allowed to authenticate, so that the user interface in these apps can allow admins to grant access to users.

            Since FishEye 2.6, it's possible to define the groups of users that FishEye will synchronise from Crowd so that FishEye only "sees" users that are members of certain groups.

            We understand that server-side group filtering may make sense for some applications, but we will not be looking to implement it in the near future.

            We recommend implementing the filtering on the client-side by only requesting known groups. If server-side filtering is critical for your connecting application, it is possible for you to write a plugin that exposes such an API.

            shihab added a comment - Crowd allows a client application to query for all users that exist in directories mapped to the application. In some cases applications (such as JIRA/Confluence/Bamboo) need the ability to see all users and groups, not just those that are allowed to authenticate, so that the user interface in these apps can allow admins to grant access to users. Since FishEye 2.6, it's possible to define the groups of users that FishEye will synchronise from Crowd so that FishEye only "sees" users that are members of certain groups. We understand that server-side group filtering may make sense for some applications, but we will not be looking to implement it in the near future. We recommend implementing the filtering on the client-side by only requesting known groups. If server-side filtering is critical for your connecting application, it is possible for you to write a plugin that exposes such an API.

            Hi everyone,

            Just letting you know that we've updated the current Atlassian status in the description of this issue, and you should go check it out!

            Eugene Mak
            Atlassian Product Management

            Eugene Mak [Atlassian] added a comment - Hi everyone, Just letting you know that we've updated the current Atlassian status in the description of this issue, and you should go check it out! Eugene Mak Atlassian Product Management

            Ryan Maki added a comment -

            Voted, I agree with Sarah, the text is clearer if you stop to read it but it's a confusing situation. This started me on a red herring chase after the last FE upgrade trying to figure out why all of my users, even deleted users with no *-users groups associated were showing up on the Users tab. So I spent time on that instead of finding the root cause of my authentication errors.

            Ryan Maki added a comment - Voted, I agree with Sarah, the text is clearer if you stop to read it but it's a confusing situation. This started me on a red herring chase after the last FE upgrade trying to figure out why all of my users, even deleted users with no *-users groups associated were showing up on the Users tab. So I spent time on that instead of finding the root cause of my authentication errors.

            It's a core feature of a central identity management software.
            We realy need this feature, too! Voted.

            Wolfgang Fellner added a comment - It's a core feature of a central identity management software. We realy need this feature, too! Voted.

            I agree, this is a necessary feature of central identity management software. The user base for confluence and jira is naturally larger than fisheye would be (everyone vs developers) therefore we have a much smaller fisheye license than confluence. Because of this limitation my business wiki users are taking up fisheye seats when they aren't even able to authenticate (since I made the fisheye user group only allowed).

            Jason Brito added a comment - I agree, this is a necessary feature of central identity management software. The user base for confluence and jira is naturally larger than fisheye would be (everyone vs developers) therefore we have a much smaller fisheye license than confluence. Because of this limitation my business wiki users are taking up fisheye seats when they aren't even able to authenticate (since I made the fisheye user group only allowed).

              Unassigned Unassigned
              pkamal Partha
              Votes:
              36 Vote for this issue
              Watchers:
              37 Start watching this issue

                Created:
                Updated:
                Resolved: