Groove Security, meet SharePoint Security.

  • Article

If you are looking at Groove and SharePoint, at some point the security questions start coming up...Does Groove support SharePoint ACL's in the SharePoint Files Tool? Who can edit content in the tool? Who can get access to the tool? Is this a violation of the SharePoint security model? Groove Security, meet SharePoint. SharePoint, meet Groove. 

Does Groove support SharePoint ACL's in the SharePoint Files Tool?

  • There are two seperate security domains at play here. Groove has a Roles/Permissions based model, while SharePoint has an Access Control List. Groove does not support the Sharepoint ACL within the Groove workspace, and SharePoint does not support the Groove Roles/Permissions within the SharePoint site. 

  • In essence, Groove security and SharePoint security are configured and administered separately and independently. Within the transaction, a Groove sync request and SharePoint access are glued together by a Windows logon session.

  • It is at the intersection of the two that things get interesting.

Who can edit content in the tool?

  • Take an example where Alice/Fabrikam has a specific set of rights on the SharePoint site "Project Alpha". Alice can create a new Groove workspace ("Alice's Project") and can add a SharePoint files tool to that workspace. When she first sets up the SharePoint files tool in Groove, and enters the URL for the SharePoint site (or picks it from her site picker) she crosses the boundary from her Groove workspace ("Alice's Project") where she has a Role, to the SharePoint site ("Project Alpha") where she is part of an ACL. 

  • Her ability to create the synchronization between the two requires at least Read access to the contents of the SharePoint site "Project Alpha." Once the content is in the workspace, her ability to work with that content is governed by the Roles and Permissions in the workspace, not the SharePoint ACL. 

Who can get access to the tool?

  • When Alice/Fabrikam invites Charlie/Contoso into the Groove workspace, his ability to work with the contents in the workspace are governed by his Role and Permissions in Groove. His status on a Sharepoint ACL is not considered at this time. Charlie will be able to read all the contents of the "Alice's Project" workspace, and may be able to modify content, create new content, or delete content, depending on his role in the workspace. When Alice synchronizes with the "Project Alpha" SharePoit site the ACL is checked to determine what exactly Alice (or rather Alice's Windows log-on credential) is able to do. Can she write changes back to SharePoint? Delete? Add new? 

Note that Charlie/Contoso's credentials are not checked by the SharePoint site. Any changes made by Charlie in the "Alice's Project" workspace will show up in the SharePoint site as modified by Alice/Contoso. As the synchronizer, it is Alice's credentials that are applied. (Note that Alice could make Charlie the synchonizer, at which point it would be his credentials that are checked).

As for the credentials, in an established workspace, when a user clicks the "SharePoint sync" button in Groove, Groove passes the sync request to the current Windows log-on session. Subsequently, it is as if the request is from current Windows log-on session is trying to authenticate with the SharePoint server. This part works very much like, if not identical to, accessing a generic IIS web site. Notice the behavior also depends on which authentication method is configured in IIS for the SharePoint web site (in this example, we assume it is an intranet environment with Integrated Windows Authentication).

As the current Windows log-on session accessing SharePoint, if the current Windows logon session is a domain log on, the Windows credentials (which were cached upon successful log on to the domain) are sent to the SharePoint server. If the cached credentials are authenticated by SharePoint, a connection is established, and content is synchronized. In this case, the user is not prompted for credentials. If the credentials are not accpeted, however, IIS will prompt the user for credentials, and her or she will need to enter a username and password in order to authenticate against the SharePoint site. 

If the current log-on session is not a domain log on, the log on reverts to NTLM and the local log-on credential cannot be delegated out. Windows typically tries to establish an anonymous log on, which will succed or fail depending on wether SharePoint is set to allow anonymous logging on.

 Link to this page: https://blogs.technet.com/groove/archive/2007/04/02/groove-security-meet-sharepoint-security.aspx