manifoldcf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <daddy...@gmail.com>
Subject Re: Sharepoint SID extraction for groups
Date Wed, 06 Nov 2013 13:42:53 GMT
I should also add that, as far as ActiveDirectory groups go, my
understanding is that in non-Claim-Space versions of SharePoint, there's a
SharePoint group created for each AD group.  So a SharePoint user will
belong to some native SharePoint groups, but also to some "mirrored"
SharePoint groups that are created because of the user's group
relationships in AD.

Claim Space seems to change this in the following way: SharePoint groups no
longer mirror AD groups.  Instead, the Claim Space authorization tokens
implicitly describe the relationships.  So you have to talk to both
SharePoint AND AD in order to fully understand what documents in SharePoint
are authorized for what users.

Karl



On Wed, Nov 6, 2013 at 8:37 AM, Karl Wright <daddywri@gmail.com> wrote:

> Hi Will,
>
> The current connector indeed maps SharePoint groups to individual user
> SIDs.  That is not terribly scalable, and it is one reason why I've created
> dedicated SharePoint authorities in the CONNECTORS-754-2 branch, so that we
> can authorize documents at a group level.
>
> I've also done considerable research on the ClaimSpace security model.
> Supporting it fully has required some modifications to the basic
> authorization model that ManifoldCF uses to tie documents to authorities.
> This basic work is done and is now part of trunk as well.  And the
> documentation has been updated to describe the revised authorization model.
>
> If you want to try working with the CONNECTORS-754-2 branch, I'd be very
> happy to interact with you to iron out any problems.  What you will need to
> do if you try it out is the following:
>
> (1) Create an authority group for your SharePoint instance
> (2) Create a "SharePoint/Native" authority tied to that authority group
> (3) If this is a claim-space SharePoint instance, then also create a
> "SharePoint/Active Directory" authority tied to the same authority group
> (4) Create your SharePoint repository connection, making sure to select
> "Native" mode
>
> The implementation is currently the best I can do in the absence of a
> full-blown Claim Space instance.  Even so, there are still questions in my
> mind that, if I could solve them, would help clarify the implementation.
> For example, what "Role Definitions" do - are they essentially just another
> form of group?  And, whether it is better to use a user, group, or role
> definition's name for an access token, or the ID?  Perhaps you can clarify
> a bit, I don't know...
>
>
> Thanks,
> Karl
>
>
>
> On Wed, Nov 6, 2013 at 8:14 AM, Will Parkinson <parkinson.will@gmail.com>wrote:
>
>> Hello,
>>
>> I am just wondering how the extraction of the groups permissions works
>> for the sharepoint connector.  From what I can see, it seems that the group
>> is determined via the MCPermissions.asmx web service and then each user in
>> that group is iterated over and the SID for those users are extracted.
>>
>> Is this the case?  If so, are groups created in Sharepoint and AD groups
>> treated the same way?
>>
>> Cheers,
>>
>> Will
>>
>
>

Mime
View raw message