Question

I am working on the very first project at my office where we will be using "Windows Identity Foundation" with Claims-Based-Authorization. To this end, Microsoft .net provides the ClaimsAuthorizationManager abstract class. In order to use this class, you override two methods: the constructor and CheckAccess(context as ClaimsAuthorizationContext).

The constructor sets everything up; then when the user accesses something, such as a web page, CheckAccess gets called with a parameter which indicates the user, the resource to be accessed, and the action to be taken on the resource. For example, CheckAccess could be called to see if the user Bob should be given access to the resource http://www.mysite.com/SecretPage.aspx to perform action GET. CheckAccess simply returns true or false. Windows Identity Foundation gives us the flexibility to implement CheckAccess almost any way imaginable!

In the code samples that Microsoft provides, CheckAccess is configured to allow access to a user only if he has a birthday claim that indicates age 21 or older. This policy is given in plain-text in the web.config and read in the ClaimsAuthorizationManager constructor.

In my office, we use SQL to keep track of almost all of our data, so in my case. I believe that it makes sense to program the ClaimsAuthorizationManager to read data from SQL to determine if a user may or may not access a resource. However, there is a myriad of different possible policies. I want to create a ClaimsAuthorizationManager that will be useful in the current project and that I can build upon and improve in the future without having to rip and replace the project I create today.

What are the most important things to bear in mind as I proceed with this project?

UPDATE: I have been working on a system of representing required-claim policies as strings. I use binary-tree logic to group together policies. I maintain a database of claims associated with "resources" and "actions".

Has anyone else here built a ClaimsAuthorizationManager class?

Answer 1

I think it is encouraging that you are looking forward trying not to write dead code BUT I think you are getting ahead of yourself.

You need to produce one or more spikes that ARE treated as throw-away to determine for yourself what makes sense for your particular scenario.

That said, if all of your rules are in the db, create a sproc base CAM that reads the sproc name from the config file. The CheckAccess args are not going to change so the sproc signature can be immutable allowing you to switch them out as needed.

友情链接