Last post Dec 28, 2013 10:33 PM by BrockAllen
Dec 28, 2013 11:35 AM|sobdeijn|LINK
I'm designing an webbased application. I don't have much experience with security but with a bunch of research i'm getting closer to what I need. The next challenge Is as following:
Users can create a group of users and will be the admin of this group, the same user will be able to join another group as a normal user. So the authorization is context dependant. I called it group-based roles, I if thats the the official name or not, but
i'm having trouble with the implementation of the idea.
I like the ideo of using the claimsprincipalpermission attribute to seperate business logic and the authentication logic. So something like this. The required permission will probally stay the same. But I might define extra users or roles that can execute
[ClaimsPrincipalPermission(SecurityAction.Demand, Resource = "Group", Operation = "Edit")]
void EditGroup(int GroupID)
But the problem is that from what I understand the ClaimsAuthorizationManager that authenticates the user will only see the Resource and the Operation parameter but not the GroupID. Is there some other way to get this to work or am completly on the wrong
Dec 28, 2013 11:46 AM|BrockAllen|LINK
Look into the Thinktecture IdentityModel helper library -- it provides a better API for doing claims based checks and then you could pass along the group ID as another param to populate the resources collection in your claims authorization manager.
Dec 28, 2013 06:16 PM|sobdeijn|LINK
I probally need to use the checkaccess method then?
The attributes ain't going to work. I liked attributes from a readablity viewpoint. But it is what it is.
Dec 28, 2013 10:33 PM|BrockAllen|LINK
Yep, CheckAccess and then you can pass as many contextual params as you want. Then in your claims authorization manager those values will appear on the resources collection in the context param.