I have a site that is using Azure ACS as our trusted identity provider.  All authentication goes through this STS.  ACS provides my identity claim (email) and can provide others.  Additionally, I understand that I could write a custom claims provider to extend my user with even more claims.

 

What I'm struggling with is how I can use these claims to control authorizations within my site?  I do not want to directly assign a user, by email, into a SharePoint group.  Instead I would like to interrogate a claim to determine group membership.

Unfortunately, SharePoint does claims authentication not claims authorization.  You can only use claims to establish the identity of the user in SharePoint.  You can't use it to vary authorization based on claims.  An individual user either has access or doesn't.  If they lose one of the components that claims uses to establish their identity then they won't be authenticated and won't have access.  But once their identity is established you can't vary what they have access to based on claims.  It would be nice if SharePoint worked that way, but it doesn't.

I am seeing any number of things that seem to say claims authorization/augmentation is part of SharePoint.  The entire concept of a custom claims provider (a SharePoint construct) is to augment the claims of a user within the SharePoint environment.

See here on MSDN:

https://msdn.microsoft.com/en-us/library/office/ee535894%28v=office.15%29.aspx

And I quote:  " By including these claims in the user's token, resources can be authorized against these claims. That is, these claims are used to determine whether a particular user has access to specific resources."

Authentication and Authorization are separate processes in SharePoint.  Custom claims providers are specifically limited to authentication at this point.  I agree that the quote seems to imply that you can use the claims to authorize access.  But the reality is you can't.  You can only use the claims to authenticate a user or not.  If you don't authenticate them then they don't have access to the resources.  But you can't authenticate them and then deny them access to a specific resource based on the claims that are in their token.  Its just not designed to work that way.

I'm sorry, I'm not trying to be obtuse but I am not following.  Do you have some documentation that says claims can't be used for authorization in SharePoint 2013?  It's a foundational concept of claims in that they assert information about a user that is then used by a claims-aware application to determine authorization.

Here's another link that seems to be saying I can create a people picker where, I think, I can find and select a claim to assign permissions to a site, list or library.  This would be used instead of a specific user or group, I believe...

https://technet.microsoft.com/en-us/library/gg602072(v=office.15).aspx

Another quote:

"You cant change what information is supplied and how it is displayed when you use an out-of-box claims provider. To do this, you must create a custom claims provider that will meet the needs of your solution for finding and selecting users, groups, and claims when a user assigns permissions to items such as a site, list, or library."

Another link that seems to disagree with you here:

https://msdn.microsoft.com/en-us/library/ff699494(v=office.14).aspx#SP_WCP_Resolve

Quote: "You can use a claims provider in SharePoint 2010 to augment claims and provide name resolution. By using claims authentication, you can assign rights based on claims without having to know who a user is, or how they are authenticated; all that you have to know is the attributes of the users. You can, for example, use a piece of corporate metadata that is associated with a person, and have the claims provider do a lookup to some other system to figure out all the different identities that particular person usesWindows, forms-based authentication, SAP, CRM, and so onand map some other identifier or set of claims to that identity. Those claims are then used to grant access to resources."

But if you read the quote you will notice that it keeps talking about claims AUTHENTICATION not AUTHORIZATION.  I agree that you can authenticate people based on the tokens in their claims.  But what you want to do is AUTHORIZE people to access a specific resource based on the claim in their token, not Authenticate them.  As I have clearly stated.  SharePoint does NOT do Claims Authorization it does Claims Authentication.  They are two separate processes in SharePoint.  I wish it operated the way you want it to, but the fact is that it doesn't.  You cannot dynamically authorize people to access specific resources in SharePoint based on what is in their claim token.  You can decide what needs to be in a user's claims token to authenticate them to the system and then use that identity to decide who has access to what resources.