Question

Is there a best practice for using claims for right-management?

I am using the new .net 4.5 and the new claim classes.
Currently I do something like that:

new ClaimsIdentity(new List<Claim>
                    {
                        new Claim("Username", user.UserName),
                        new Claim("UserNumber", user.UserNumber.ToString()),
                        new Claim("Creation_Right", ""),
                        new Claim("Edit_Right", "")
                    }

I add the right-claims without a value.
Later I check for the presence of a right. There is no need for a value (like true/false) – if it is present, its implicit ‘true‘.

Is there a better way to do that?

Answer 1

Perhaps. It looks like what you’re doing is merging authentication and authorization together, making an access policy decision at the moment of authentication.

You also have the option of separating your authorization component away from your authentication component. Claims represent a set of information about a user that can be used to make an authorization decision. That is, your autheNtication step produces a set of claims, and whenever your user tries to access something, those claims are fed to the authoriZation component which renders a decision.

This provides some flexibility in that your authorization policy can change and evolve independent of your claims issuance system. For example, you might issue a role claim that identifies someone as an administrator, and you might also issue a authentication method claim that specifies how the user logged on, using a smart card or username and password for example. This gives you power in defining your access policy, you can require just an administrator role for access to some resources, while other more sensitive resources require administrator role AND use of a strong authentication mechanism. It also means you can switch between multiple different access policies depending on context. Your online whiskey store might use an ageOver21 claim on the US, but the Canadian version of your site requires over18 or over19 claims instead. Separating your authZ from your authN allows for this kind of flexibility.