12 Replies Latest reply on Nov 19, 2014 5:27 PM by aziz

    Social groups with access control

    aziz

      Hello all. I am new to Jive and have the following question.

       

      We are using Jive 7.0.0.1.

       

      We would like to allow a well-defined population to collaborate using Jive. All of the features we want are provided by Jive’s social groups. Users can create their own (open/membership/private/hidden) social groups and invite others. However, we have a hard requirement that an additional access control be applied when accessing these social groups: at the time of creation, a social group owner would indicate the permission group(s) to which all users must belong in order to access the social group, regardless of membership status to the social group. So, it’s not enough that a user has been invited to the social group in order to access it, the user must also be in the permission group(s) allowed to access the social group.

       

      Option 1: Use Customized Social Groups

      We could not find out-of-the-box Jive functionality to allow for this. Jive does allow permission group access control for *all* social group. However, we don’t want such a universal approach. We want to be able to selectively apply permission groups to social groups on a case by case basis. So, we thought about customizing Jive’s social groups as follows:

      1. Allow a social group owner to indicate the permission groups required to access a social group
      2. Add checks within Jive to enforce this access control

       

      How easily can the “create social group” web interface be customized?

       

      For access control enforcement, we were thinking we would implement a plugin, via a servlet filter, that checked every social group related resource request URL on the server to ensure the user belonged to permission group(s) (if any) that protected the social group. One issue here is recognizing all the various URLs that are related to a social group (e.g., using the context path in some cases, “container id” in other cases, etc.). How feasible is this?

       

      Option 2: Used Customized Spaces

      As a second option, we thought about using Jive spaces, since they provide for fine-grained access control on a case by case basis while also providing most of the same features as social groups. The idea would be to designate a space to which this user population has admin permissions, and underneath which users can create their collaboration area as subspaces. The problems with this approach are:

      1. It is undesirable for users to have admin permissions to spaces (even if in a limited fashion in the form of this one designated space)
      2. We would still require customizing the web interface for setting permission groups for this space (for example, we would want to remove the individual user override capability – long story)
      3. We lose the membership and invitation features of a social group, something that is undesirable.

       

      The ability for self-service in order to create these sub-spaces on demand is also an important requirement, so we cannot simply place administration responsibilities for the subspaces on community manager(s).

       

      Option 3: Use Separate App to Create Spaces

      As a third option, we would create a small app (not sure if it can be a Jive app or an altogether external web app) that would allow users to create their subspace, under some designated space for this purpose, on demand and handle invitations to users also. None of the users in this case would be space admins, only participants. The app would have to proxy through a backend service we create in order to send requests to our Jive instance with designated (“hard coded”) space administrator credentials and utilize the v3 REST APIs to provision subspaces and set their permission groups. One issue with this approach is that it does not allow the user creating a subspace to customize and manage the home page for that subspace (Overview/Activity), which is an essential feature.

       

      Is there a way to provide a space/subspace participant with the ability to manage the subspace home page without giving them space admin permissions?

       

      Thanks in advance for any input!

        • Re: Social groups with access control
          whoiskevin

          We implemented option 1.  Customized interface to apply permission groups to social groups (admin, collaborate, read only).  This fits your requirements as well I think so it is the direction that works in that type of environment.  I favor spaces from an organization view but self service and ad-hoc organization needs social groups and you need groups in my opinion instead of individual user management.  Ours is synchronized with LDAP as well.

           

          Unfortunately I cannot share that code with you so this is something you should engage with professional services or take on in house.  It is a larger project.

          1 person found this helpful
            • Re: Social groups with access control
              aziz

              Glad to hear we are not the only ones who faced this problem. Without necessarily divulging code, can you describe the approach in a bit more detail? For example, we though we'd create a plugin that provided a servlet filter that intercepted every incoming request and, if it was a group resource, would look up the access control for that group and enforce it for the current user. The question here is what is the full set of such URLs to intercept and are there edge cases where this approach does not work?

               

              On the UI side, do you simply disable the Jive provided widget to create social groups and insert your own customized one? Or, do you customize the Jive provided one?

               

              And I assume you expect to potentially update your custom code on Jive upgrades?

               

              (I tend to agree with you that this can't be done with only the REST APIs, which also appear to be favored now by Jive over more heavyweight Plugins on the server side, which to me raises a question of "API gap".)

               

              Part of the problem is that our dev team, while experienced, is completely new to Jive and we have a pretty aggressive deadline to implement this feature. Over the next few weeks (and with help from the community) hopefully we'll have a better understanding of Jive's capabilities and the extent to which we can customize it, but atm we're just trying to understand the feasibility of this approach by leveraging the experience and advice of those who have been down this road.

               

              Thanks!

                • Re: Social groups with access control
                  whoiskevin

                  Our customization is around the social group permission manager.  We are synchronizing with LDAP so the approach here was a complete customization of the social group interface (one I think Jive should incorporate).  When a social group is being created we create groups in LDAP and Jive since the security groups are federated.  The groups correspond to admin, collaborate and read access.  The customization adds all the users from the security (LDAP) group to the Jive social group with those particular rights.

                   

                  So in short (and there is not that much that is short in this customization) we have the ability to manage the social group membership by access level (admin, collaborate, read) and by security group.  On login we synchronize users with their groups which includes adding them into the social groups that their group memberships allow.

                   

                  I don't think a filter would be able to accomplish everything but it may be possible.

                  1 person found this helpful
                    • Re: Social groups with access control
                      aziz

                      Thanks for the follow-up, Kevin. This helps but I don't quite get how you overrode the default SocialGroupManager in Jive.

                       

                      I can see how within a plugin, where you would create your own project with backend logic that overrides SocialGroupManager and an associated custom front-end widget for creating social groups (even in this case, how do you disable the default social group creation widget)?

                       

                      I've also been perusing docs like this https://community.jivesoftware.com/docs/DOC-111844 and it's helping, getting there slowly.

                • Re: Social groups with access control
                  it2000

                  If the REST API has all the needed features I'd use it. It is likely more stable than the internal API. It's not as user-friendly as a fully integrated solution but much more (Jive-)update friendly.

                  • Re: Social groups with access control
                    sliebler

                    Ryan Rutan do you have any thoughts about Aziz's question?

                    • Re: Social groups with access control
                      Ryan Rutan

                      Hopefully not chiming in too late here, but based on what I'm seeing above..but given the specificity of the requirements, the only way I can see this working is to make an App Experience that envelopes a new Group creation experience.  This experience would enforce any business rules that might need to be put in place, but I would recommend that all groups created by this process be created as SECRET.

                       

                      Assigning membership / visibility could be done after-the-fact via the REST API and the securityGroups end-points ... you could possibly create a better on-boarding experience with inbox notifications as well.

                       

                      The only snag I see here is keeping the group memberships in-sync, but that could be done via the ExtProps end-points and a cron-job.

                       

                      Does any of that stir up the conversation? =)

                        • Re: Social groups with access control
                          aziz

                          Thanks for following up, Ryan.

                           

                          I was curious though why you recommended access control be applied only to SECRET social groups (vs. membership, private and secret ones). The scenario is basically someone create a new social group and they are given a choice of access control via, say, LDAP for the social group, much like you can do with spaces. Then, regardless of the social group's visibility, you can only browse access controlled social groups, invitations would be restricted to people in those LDAP groups, content moving would be restricted such that the access control of both the source and target is respected in some fashion and content sharing is similarly restricted. These are some of the cases we have identified (there may be more) to which we have to extend the access control to avoid information leakage outside of the allowed LDAP groups.

                           

                          The after-the-fact application of membership/visibility is interesting, we'll definitely look into it, although we still need a way to allow the user specify the access control (LDAP group restrictions for the social group).

                           

                          Also, what did you mean by "keeping the group memberships in-sync"?

                           

                          Thanks!

                          aziz

                            • Re: Social groups with access control
                              Ryan Rutan

                              The primary reason I suggested SECRET groups was due to the fact that it would allow you to have absolute control over who joins the group.  Private/Open/Members only are a bit more loose in their rules, and could generate scenarios of people entering/leaving that shouldn't be in the group per your desired AD business rules. 

                               

                              Hope that helps explain my recommendations.

                                • Re: Social groups with access control
                                  aziz

                                  Ah I see. That would satisfy the requirements still, although our idea was to propagate the access control through all operations allowed for a social group, including browsing (i.e., you could only browse those social groups  whose access control allowed you to). Thanks for the follow-up!

                                  aziz