Can Metalama add an aspect to a class? Thinking of creating a runtime AuthorizeAspectAttribute.

[HowardShank]

I'm new to using Metalama.

I have implemented Field and Property Aspects thus far. I have also implement a shared ProjectFabric Aspect for adding Aspect to multiple Properties across multiple projects.

Our project is using .Net 8 & Blazor Server Side app.

I am considering the idea to create an Aspect that implements runtime Authorization. The @ attribute [Authorize] applied in the .razor file is considered a AttributeTargets.Class for usage. I cannot find any information on how it is "wired" to the class or executed (when or how).

If anyone would be so generous as to offer a few beginning suggestions or pointers on what to look for I'd appreciate it.

I am unsure if this can be combined with custom AuthorizationMiddleware or if that's the right or wrong way to approach this.

I am unable to find any information on the web how the @Attribute [Authorize] works in a Blazor context other than the attribute is a "class" attribute.

Thank you in advance for any constructive responses you may provide.

[svick]

All @attribute does is that it adds the attribute on the generated class.

For example, if you have Home.razor with this content:

@page "/"
@using Microsoft.AspNetCore.Authorization

@attribute [Authorize]

<PageTitle>Home</PageTitle>

<h1>Hello, world!</h1>

Welcome to your new app.

It generates this C# code (simplified):

namespace BlazorApp.Components.Pages
{
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Threading.Tasks;
    using Microsoft.AspNetCore.Components;
    using System.Net.Http;
    using Microsoft.AspNetCore.Components.Forms;
    using Microsoft.AspNetCore.Components.Routing;
    using Microsoft.AspNetCore.Components.Web;
    using static Microsoft.AspNetCore.Components.Web.RenderMode;
    using Microsoft.AspNetCore.Components.Web.Virtualization;
    using Microsoft.JSInterop;
    using BlazorApp;
    using BlazorApp.Client;
    using BlazorApp.Components;
    using Microsoft.AspNetCore.Authorization;

    [Authorize]
    [RouteAttribute("/")]
    public partial class Home : ComponentBase
    {
        protected override void BuildRenderTree(Microsoft.AspNetCore.Components.Rendering.RenderTreeBuilder __builder)
        {
            __builder.OpenComponent<PageTitle>(0);
            __builder.AddAttribute(1, "ChildContent", (RenderFragment)((__builder2) => {
                __builder2.AddContent(2, "Home");
            }
            ));
            __builder.CloseComponent();
            __builder.AddMarkupContent(3, "\r\n\r\n");
            __builder.AddMarkupContent(4, "<h1>Hello, world!</h1>\r\n\r\nWelcome to your new app.\r\n");
        }
    }
}

It's then up to other parts of the Blazor runtime to interpret this attribute.

From Metalama's point of view, you should be able to treat this generated class as any other class.

For example, a useless aspect that just adds [Authorize] would look like this:

class AuthorizeAspect : TypeAspect
{
    public override void BuildAspect(IAspectBuilder<INamedType> builder)
    {
        base.BuildAspect(builder);

        builder.Advice.IntroduceAttribute(builder.Target, AttributeConstruction.Create(typeof(AuthorizeAttribute)));
    }
}

And would be applied like this:

@attribute [AuthorizeAspect]

Though it's not quite clear to me what you're actually trying to achieve or how Metalama fits into that.

I think it would make sense to first figure out what you need to do in terms of plain C#/Blazor and only then consider how to use Metalama to improve on that.

[HowardShank]

@svick Thank you for your reply. I appreciate it.

Here's our challenge:

Note: If it matters, our Blazor components inherit from our CustomComponentBase class which in turn inherits the Blazor ComponentBase class.

• We desire to avoid create code blocks in each and every page/component, hence our desire to use AOP/Metalama tool to add authorization code/logic. Metalama, if this is possible, will help us decorate the Blazor classes with the desired logic to control page/component access.

• We need to avoid redeploying the application every time a data driven element is changed in the database. We do not want to go change a compile time value to match creating/deleted/activating/deactivating a menu item or component/page item. We do not want to manually change a value, recompile, redeploy, etc.

• We have data drive information for authorizing users to access functional areas from an RDBMS.

• User claims are data driven from an RDBMS to populate the Principal Security Claims object.

• Menu items have data driven access controls for Authorization. Value list is only known at runtime.

• Pages/Components have data driven access controls Authorization. Value list is only known at runtime.

• The standard AuthorizeAttribute requires compile time values for the authorization test. Since the list of Authorized roles to test user claims is not know until runtime, AuthorizeAttribute does not meet our needs.

• We need to control access to the menu items and direct access to the page/component direct URL.

• Managing the display of menu items is a separate issue and not necessarily a part of authorizing the user to access a .Net 8/Blazor page/component

Data/Logic description:
Menu items:

1. Menu items/navigation links display is controlled by two data driven factors: business unit is active flag & if user is a member of the business unit. Being data driven, neither values are known at compile time.

Page/Components:

1. Authorization to particular pages is controlled by two data driven factors: business unit is active flag & if user is a member of the business unit. Being data driven, neither values are known at compile time.

Business Units.

1. There are multiple business units. A business unit may be added, removed, activated or deactivated through system administration of the data table during runtime. Thus the requirement is the Business Unit Authorization information must be retested every time a a user requests a controlled feature.
2. Changes to the data cannot require a new compilation, reset, restart, etc. of the application..
3. Business unit 0 will always exist. Cannot be deleted or deactivated.
4. A business unit is used to determine if a menu item is displayed in the application. User must be a member of the business unit for the menu item to display at runtime to test authorization.
5. A business unit is used to determine if a user has access to a page/component. User must be a member of the business unit at runtime to test authorization.

User information.

1. A user may belong to 0 or more business units.
2. When user is member of business unit 0, access is granted.
3. When a user is a member of one or more business units (not including business unit 0) their access to a page/component is controlled by the users matching claim to the business unit. Authorization permitted if user claim is in dynamic list of business units. Authorization is denied if user is not a member of the dynamic list of business units.

Logic:

1. if an object requires authorization where a user data driven claim is in a component data driven required role, check user roles programmatically and determine if access should be authorized or not.

[svick]

It seems to me that the main thing you need is to restrict access as soon as the underlying data changes and, as I understand it, you should be able to achieve that using CookieAuthenticationEvents.ValidatePrincipal.

Though since you also need a dynamic list of allowed roles, doing this with role-based authorization would require that the roles in your data are not the same as the roles in the app, but are dynamically mapped between each other. And I'm not sure this would be a good idea.

So you probably should consider either claims- or policy-based authorization, both of which allow you to execute code when authorizing an user.

[HowardShank]

We are going to refactor the existing security to modernize it and avoid the problem all together.

Thanks!