I have a SharePoint group "SPGroup A". I have users logging in to SharePoint using ADFS. All of these users have a role claim "Role A". I have the claims provider configured and working on my farm. If I add role claim "Role A" to my SharePoint group "SPGroup A" everything works great. I can log in and SharePoint correctly sees me as a member of "SPGroup A".
My problem begins when I try to call SharePoint from my on-premise provider hosted app. I have my app permissions set to allow "Read" on user profiles. I have modified the TokenHelper to include the "smtp" claim with the current user's email address. From server-side code I generate a token and use it to call the REST API to get the "AccountName" using "/_api/SP.UserProfiles.PeopleManager/GetMyProperties?$select=AccountName".
If the user is explicitely added to the "SPGroup A" SharePoint group my call works perfectly. However, if I take the user out of the SharePoint group and add the role claim "Role A" to "SPGroup A" I get "The remote server returned an error: (401) Unauthorized.". I have checked and my user definitely has the "Role A" claim. SharePoint successfully logs me in with "SPGroup A" via the "Role A" claim. However, the call I make from my provider-hosted app doesn't grant me access. Any thoughts or suggesions you might have would be greatly appreciated. Thanks!
Comments: I know this is an old thread but noticed it is still listed as proposed. I have a similar issue only between two separate SharePoint farms in separate data centers. We are trying to achieve federated search between the two farms but have hit the issue of the role claim not being rehydrated at the target SharePoint farm, hence security trimming is trimming out all content the user has not been explicitly granted access to. We are using ldapcp in both farms. Within each farm role claims are working great and security trimming is working as expected. It's only when we try and search across farms that we hit the claims rehydration/augmentation issue. In the current version of ldapcp, is there support to rehydrate or augment the role claim with AD/ldap group membership to support this scenario? I've been searching high and low but haven't been able to find much guidance around this which doesn't involve writing a custom claims provider to handle augmentation of the role claim.
My problem begins when I try to call SharePoint from my on-premise provider hosted app. I have my app permissions set to allow "Read" on user profiles. I have modified the TokenHelper to include the "smtp" claim with the current user's email address. From server-side code I generate a token and use it to call the REST API to get the "AccountName" using "/_api/SP.UserProfiles.PeopleManager/GetMyProperties?$select=AccountName".
If the user is explicitely added to the "SPGroup A" SharePoint group my call works perfectly. However, if I take the user out of the SharePoint group and add the role claim "Role A" to "SPGroup A" I get "The remote server returned an error: (401) Unauthorized.". I have checked and my user definitely has the "Role A" claim. SharePoint successfully logs me in with "SPGroup A" via the "Role A" claim. However, the call I make from my provider-hosted app doesn't grant me access. Any thoughts or suggesions you might have would be greatly appreciated. Thanks!
Comments: I know this is an old thread but noticed it is still listed as proposed. I have a similar issue only between two separate SharePoint farms in separate data centers. We are trying to achieve federated search between the two farms but have hit the issue of the role claim not being rehydrated at the target SharePoint farm, hence security trimming is trimming out all content the user has not been explicitly granted access to. We are using ldapcp in both farms. Within each farm role claims are working great and security trimming is working as expected. It's only when we try and search across farms that we hit the claims rehydration/augmentation issue. In the current version of ldapcp, is there support to rehydrate or augment the role claim with AD/ldap group membership to support this scenario? I've been searching high and low but haven't been able to find much guidance around this which doesn't involve writing a custom claims provider to handle augmentation of the role claim.