Share via

Authorization Sample 301

  • Article

In Authorization Sample 201, I touched on some of the extensibility options for custom authorization. These include applying custom rules or setting target properties for custom bindings in xaml. I avoided the bigger picture, however, by neglecting to explain how it all works. In this section, I’ll tackle explaining the ins and outs of the authorization engine.

Attributes, Behaviors, and Rules

AuthorizationAttributes are the primary types for authorizing. They define the logic that determines whether something is allowed or not. All custom authorization implementations will start by defining a new attribute.

AuthorizationBehaviors are the primary types for applying authorization results to UI. They interpret the result and update the targeted object accordingly. For instance, the default behavior knows how to create Bindings for the attached property Authorization.TargetProperties.

AuthorizationRules are used to define the attributes and behaviors that will be applied to an object.

Invoking Authorization.Authorize() will run a target object through the following set of steps.

  1. Determine the AuthorizationRules that apply to the target
  2. Use those rules to determine all the AuthorizationAttributes that apply to the target
  3. Authorize the target by testing each attribute against WebContext.Current.User

There is one final step if the target is a DependencyObject. The rules are used to determine all the AuthorizationBehaviors that apply to the target, and then those behaviors are added to target.

Rule Management

As I describe above, AuthorizationRules are really what tie everything together. What I still need to explain is how rules are associated with an authorization target. Association occurs in two ways. First, targets start with a default set of rules based on their type. Second, specific rules can be added or removed from the collection of rules associated with a target. Both these responsibilities fall to the AuthorizationRuleManager. The manager tracks the rules for each target and allows you to access and update the them. Also, it allows you to set the default rules for a type (by passing in the type as the target). The following snippet adds a default rule and then gets the attributes for a specific target.

   AuthorizationRuleManager.AddAuthorizationRule(typeof(MyType), myRule);
  AuthorizationRuleManager.GetAuthorizationRules(myType); // Contains myRule

AuthorizationSource

If you inspect AuthorizationBehavior a little closer, you’ll notice it uses a type named AuthorizationSource. AuthorizationSource is a model that makes the AuthorizationResult (from step 3 above) available for binding. Additionally, anytime WebContext.Current.User is updated, it recalculates the result and raises the appropriate notifications.

Authorize Everything

Up until now, all examples have shown authorization being used solely with controls. That is definitely a primary use case, but it isn’t the only thing the authorization engine supports. In fact, you can authorize anything. The most common scenario where a non-control target is authorized is Uri authorization. The navigation part of the framework authorizes both the Uri and Page when navigating.

Hopefully this section gives you a better idea what the authorization library is really capable of. I have a number of small samples I hope to share in the coming weeks that use these extensibility points in all sorts of interesting scenarios including Site Map-based navigation and MVVM authorization.

Comments

  • Anonymous
    July 17, 2010
    Thanks for some great posts on WCF RIA Services and authentication. I'm not sure if this has been mentioned before but I was unable to find any notes on the fact that client side security is inherently insecure. With that I mean that anyone doing checks on roles in the Silverlight client needs to make sure they also check the same roles on the server. Anyone can manipulate the roles that a user gets by changing the HTTP requests, and therefore potentially see screens and content they normally wouldn't. Just a tip =)

  • Anonymous
    July 18, 2010
    Absolutely agree with you. Our advice has always been that you must authorize on the server and that client-side authorization is only for UI customization. Worst case, a malicious user should only be able to see pages you don't want them to see. All your data should be protected. Obviously that advice is no longer easy to find. I'll make sure to update my posts.

  • Anonymous
    July 24, 2010
    Hi Kyle. Dublicating message that i send you. First what i need to say is: Good work! About your sample: code.msdn.microsoft.com/.../ProjectReleases.aspx

  1. Why not add extensions(attached properties) for UriMapper? I think this is the best place for the purpose of the rules to redirect and check for authorized users.
  2. Where you store the actual project version? maybe store it at CodePlex? Thanks.

  • Anonymous
    August 01, 2010
    Where is the user file stored when you are running SQL Server?  I cannot see it on my SQL server.  I will need to move it when I publish my application. What is the procedure to add additional fields to the user file, for example I want to relate the users to the customer file by adding the customerID and preferred Shipto? Is there an example of adding or modifying user settings from c#, so I can autogenerate users from the customer file?  How would you randomize a password and trigger an email to the user as if they clicked on lost password themselves?

  • Anonymous
    August 02, 2010
    @Andrew Here's a good place to start with application services. RIA uses ASP.NET by default. msdn.microsoft.com/.../bb547119.aspx Here's another decent link that describes deploying the DB. msdn.microsoft.com/.../2fx93s7w.aspx

  • Anonymous
    September 08, 2011
    Hi, authorization is sometimes seen as both the preliminary setting up of permissions by a system administrator and the actual checking of the permission values that have been set up when a user is getting access.....good work...

  • Anonymous
    October 17, 2011
    Hi, In my application when app loads,login is prompted. ie,on http://localhost:2555/AuthorizationSampleTestPage.aspx#/Home page, login child window pops.After sucessful login i click a link to redirect to 'about' page. ie,http://localhost:2555/AuthorizationSampleTestPage.aspx#/About. It works fine. But when the copy the above link and paste it to another tab, About page comes with login prompt. I mean login is prompted although the app get redirect to about us page. I can see the about page in background. So my question is how can i remain in Home page when i copy the 'about' page link in browser if i am not authenticated?Or when I paste a link to another page I should get redirect to first page,if i am not authenticated.