Jive and SharePoint Permissions

Because SharePoint has a different permissions model than Jive, you need to understand the permissions of Jive places in order to correctly set up SharePoint-side permission groups.

CAUTION:
After you set up your Jive and SharePoint connection according to the permissions recommendations described here, be careful about making changes made to permissions outside the automatic provisioning of the system. You should also block regular users from being able to modify the shared permissions of files within Jive-associated document libraries.

When you connect SharePoint to Jive, you're connecting a site collection to a place. Jive has three types of places that can be linked to a SharePoint site: groups (sometimes called social groups, to distinguish them from permission groups), spaces, and projects. Groups have a different permissions model from spaces and projects.

Jive Space and Project Permissions

Access to Jive spaces and projects is governed by associating it with a Jive permission group (not to be confused with a social groups, which is a Jive place)There are three types of permission groups in Jive. A single Jive instance may contain all three kinds of permission groups.
  • A custom permissions group configured in Jive.
  • A custom permissions group provisioned from LDAP or another directory server.
  • The built-in Jive groups Everyone and All Registered Users. Everyone includes all users in Jive: All Registered Users excludes external and anonymous users.
Note: Spaces and projects exist in a hierarchy and are subject to permissions that are set in the Jive admin console: spaces and projects inherit their permissions from any space that contains them. For example, if people belonging to the All Registered Users permissions group in Jive have access to a space, they also have access to any subspaces and projects located in that space, unless a permissions override is created. If you create a Jive project or space linked to SharePoint, you may want to make sure it is a restricted space. A project that inherits permissions from an unrestricted space could grant access to every member of the community.
On the SharePoint side, each site created on the Jive side is provisioned with the following three SharePoint permission groups:
  • [site name] Jive Contributor Users
  • [site name] Jive Full Control Users
  • [site name] Jive Read Users
These are used in the following ways depending on the type of permission groups applied on the Jive side.
  • For places that grant access to custom permissions groups created in Jive, each member of the Jive permission group is assigned to Jive Contributor Users or Jive Read Users according to whether their rights to the space are read/write or read/only rights. The user who created the space is assigned to the Jive Full Control Users group for the linked SharePoint site.
  • For Jive places that grant access to LDAP-provisioned permission groups, it is assumed that SharePoint is integrated with LDAP and can directly access the same permissions for each user. These permissions are then used to assign rights to the linked SharePoint site.
  • For Jive places that grant access to the built-in Jive permissions groups Everyone or All Registered Users (note that this is the default behavior in Jive when creating a space), Jive grants access to the Everyone principal in SharePoint. This principal can be mapped using the Office 365 Integration add-on settings during the Jive-side setup. If the principal is NOT specified in this setup, it will be identical to the default SharePoint Everyone principal. If you need the number of users with access to Jive content to be smaller than the total number of SharePoint users defined in the default Everyone principal, you should map the Everyone principal to a smaller group during add-on setup. For more information about how to do this, see Setting Up the Office 365 Integration Add-On.

Jive Group Permissions

Jive groups, also known as social groups, do not exist in a hierarchy or inherit permissions from anywhere else in the community. Instead, access is controlled by the type of group and by group membership. The following table shows who can access the four group types.



Other than Open groups, which always grant full access to all members of the community, the other group types have varying membership. The group of people who have permissions changes as people are invited to or leave the group (or are banned from it). SharePoint-side access is synchronized from the group membership. This means that other than SharePoint users with Full Control access, users with group membership on the Jive side have the same rights to the content in the linked site/document library on the SharePoint side. (An exception is that when the Everyone principal is not mapped in the Office 365 Integration add-on settings, users who are not members of or following an Open group will not be able to access content on the SharePoint side.)

Implications of Groups for SharePoint Permissions

Jive Group Type SharePoint Full Control Users SharePoint Contributor Users SharePoint Read Users
Open Group Creator Everyone*  
Members Only Jive Admins**, Group Creator All group members Everyone*
Private Jive Admins, Group Creator All group members  
Secret Jive Admins, Group Creator All group members  
*Requires an Everyone principal in SharePoint to be mapped in the add-on settings during Jive-side setup.

**Requires the Full Control principal in SharePoint to be mapped in the add-on settings during Jive-side setup.

Restricting Jive Places to Specific Site Collections

When you configure the Office 365 add-on, the best practice is to identify one or more site collections that users can choose from when creating a Jive group, space, or project. (If you identify more than one, place creators select from a drop-down list.) If you do not specify the site collection(s), users are required to specify the URL of a site collection, and there are no restrictions on where the SharePoint content is stored. For most administrators, security considerations will dictate the need to place content in specific site collections.