I have spent the last couple weeks reading up and experimenting with ASP.NET Core (Got started just in time to have to migrate from RC1 to RC2). One of the changes that is of particular interest to me is the new authorization system centered around policies.
In the past, my team has used custom AuthorizeAttributes with a database of users and feature assignments to do feature toggling (mainly Permission toggling and experiment toggling, but we want to do more in the future). As our application has matured, we have wanted to start checking for a variety of features in order to dynamically render a page for a user. This seems like a perfect fit for policies, as it is the only way to decorate controller/action access, and the new injection in MVC core has made it easy to check for policies in the view itself.
I have read and reread the sections in the docs about Authorization as well as watching the Channel 9 Videos with Barry Dorrans about the topic. The videos gave a good overview of the new libraries as well as some of the problems that were occurring in the old Authorization model. For the most part, I really like how the Requirements and Handlers create a better separation of concerns with looser coupling and less inheritance.
The concept that I am struggling with is that it seems like policies can only be parameterized at setup time. You can make the "TacoAndTequilaTuesday" policy, which would have requirements that check that it is indeed Tuesday, and that the user is 21. You could also set up a "WingsAndBeerWednesday" that would similarly check the day of the week and the age of the user. But unlike with a custom AuthorizeAttribute, where I could have arguments for dayOfWeek and minimumAge, I can't make a policy that could be parameterized when decorating the Controller or Action. So it would seem to me that to use our old feature toggling database, we would need to loop over ourn feature toggles and create n policies (each essentially identical aside from the parameter passed to our FeatureRequirement) and map them to a unique string, then use that unique string when checking the policy on the controller/action/view?
I guess what I'm asking is:
1. Am I abusing the concept of policies?
2. Is it fair to say that for n boolean permission toggles in an application, you would have to have n policies?
3. If you were doing a credit score application, you can't have a catch all credit score policy that could be parameterized, you would have a "GoodCreditScore" policy with a CreditScoreRequirement(720) and a "GreatCreditScore" policy with a CreditScoreRequirement(800).
4. Is the lack of point-of-use authorization parameterization just the point, and I need to adapt and move on?