DEV Community: ramtinmovahed

Structured Security in Blazor: Exploring Logic-Driven Authorization

ramtinmovahed — Wed, 01 Nov 2023 06:58:43 +0000

In Blazor applications, ensuring that users see only what they're authorized to is crucial. This guide will walk you through different methods of implementing authorization, both from within your markup and through procedural logic.

1st Approach: Using AuthorizeView tag.

In this approach, we display specific parts of the markup conditionally based on the user's authorization status. It supports both role-based and policy-based authorization and can be as simple or as complex as you want.


<AuthorizeView Policy="NarrowedAuthenticatedUserPolicy">
            <Authorized>
                What narrowed authenticated user sees
            </Authorized>
            <NotAuthorized>
                What unauthenticated user sees
            </NotAuthorized>
        </AuthorizeView>
        <AuthorizeView Policy="SpecialAuthenticatedUserPolicy">
            <Authorized>
                What the special authenticated user sees
            </Authorized>
</AuthorizeView>

2nd Approach: Using cascading AuthenticationState and IAuthorizationService.

When you want to check for authorization as part of procedural logic in response to user interactions. In this approach, we would use the AuthenticationState provided by the higher level AuthorizeRouteView as a cascading parameter. Then, we would inject the IAuthorizationService to authorize against a role or authorization policy.

[CascadingParameter]
private Task<AuthenticationState>? authenticationState { get; set; }

[Inject]
private IAuthorizationService AuthorizationService {get; set;}

public async Task Submit()
{
    var authState = await authenticationState;
    var authorizationResult = await AuthorizationService.AuthorizeAsync(authState.User, "NarrowedAuthenticatedUserPolicy");
    if (authorizationResult.Succeeded)
    {
        // regular user logic.
    }
    else
    {
        authorizationResult = await AuthorizationService.AuthorizeAsync(authState.User, "SpecialAuthenticatedUserPolicy");
        if (authorizationResult.Succeeded)
        {
                // Special user logic
        }
        else
        {
                // Regular authenticated user logic.
        }
    }
}

3rd Approach: using AuthenticationStateProvider with IAuthorizationService.

This approach is useful when you use a property in your razor markup and need to conditionally set that property based on the user's authorization status. In this case, we would inject AuthenticationStateProvider to get notified about authorization changes, and use the injected AuthorizationService to check if the user is authorized or not.


[Inject]
IAuthorizationService AuthorizationService { get; set; }
[Inject]
AuthenticationStateProvider AuthenticationStateProvider { get; set; }

public string UserContent = "What unauthenticated user sees";

protected override async Task OnInitializedAsync()
{
        AuthenticationStateProvider.AuthenticationStateChanged += AuthenticationStateChangedHandler;
    var authState = await AuthenticationStateProvider.GetAuthenticationStateAsync();
    if (authState is not null)
    {
        await ConstructMessage(authState.User);
    }
}


private async void AuthenticationStateChangedHandler(Task<AuthenticationState> authState)
{
    var state = await authState;
    if (state is not null && state.User is not null)
    {
        await ConstructMessage(state.User);
    }
}


private async Task ConstructMessage(ClaimsPrincipal user)
{
    var authRes = await AuthorizationService.AuthorizeAsync(user, "NarrowedAuthenticatedUserPolicy");
    if (authRes.Succeeded)
    {
        UserContent = "What narrowed authenticated user sees";
    }
    else
    {
        authRes = await AuthorizationService.AuthorizeAsync(user, "SpecialAuthenticatedUserPolicy");
        if (authRes.Succeeded)
        {
            UserContent = "What the special authenticated user sees";
        }
    }
}

Important Note: here since we're using events, it is fine to do async void. The exceptions are still caught
You may think that since CascadingAuthenticationState uses InvokeAsync internally, then you should use it too. Unless you're well-versed with Blazor's intricacies, it's recommended to avoid using InvokeAsync from componentBase within your event handler

DO NOT try to find a workaround for not using async void for the event handler. If you use InvokeAsync without awaiting it, any code that throws an exception won't be caught by blazor. It depends on your use case too, however, you can see the effect by trying to throw an exception inside the following example from Microsoft docs.

inside the second example, try to throw an error like so:

private void OnTimerCallback()
{
    _ = InvokeAsync(() =>
    {
        throw new Exception();
        currentCount++;
        StateHasChanged();
    });
}

You will see that the component simply won't work, and no exception would be caught. This means you'd be in the dark about any errors, including their origins in the stack trace.

Further reading: https://devblogs.microsoft.com/dotnet/how-async-await-really-works/

With these approaches, you'll be better equipped to implement structured security in your Blazor applications.

Thanks for reading, Happy Halloween :)

How to configure the authorize attribute for a simpler role-based authentication

ramtinmovahed — Tue, 22 Aug 2023 02:15:07 +0000

The authorize attribute in ASP.NET is quite powerful. You can use it for simple authentication, or you can use it for role-based authentication or policy-based authentication by specifying the supplying roles or policies as parameters.

Depending on the size and scope of a project, you might only need a role-based access control without authorization policy. Also, you might want a resource to be accessible for multiple roles.

The way that authorize attribute is structured is that you need to pass a string to specify the role or policy. You may use constants to prevent hard coding it, but you still need to constantly concatenate a comma "," to add more roles.

With a mix of a lookup dictionary, enums, and inheritance, you can create a custom strongly typed authorize attribute for role-based access control.

First, define your roles in a role helper class like so:

public class RolesHelper
    {
        public static readonly Dictionary<Role, string> RolesDict = new()
        {
            { Role.FullAdmin, "FullAdmin" }
            { Role.ReadOnly, "ReadOnly" },
        };
    }
    public enum Role
    {
        FullAdmin,
        ReadOnly
    }
}

In the code above, we first defined the roles in an enum and then created a lookup dictionary.

** You might be able to simplify that further in the future when c# adds support for discriminated unions by assigning string values directly to enums.

Now its time to implement the custom authorize attribute class like so:

public class CustomRoleAuthorizationAttribute : AuthorizeAttribute
    {
        public CustomRoleAuthorizationAttribute(params Role[] roles)
        {
            List<string> rolesFromDict = new();
            foreach (Role role in roles)
            {
                if (RolesHelper.RolesDict.TryGetValue(role, out string? roleFromDict))
                {
                    rolesFromDict.Add(roleFromDict);
                }
            }
            Roles = string.Join(",", rolesFromDict);
        }
    }

Let's go through the code. We first inherit from the Authorize attribute class. We then create the constructor. In the constructor, we pass the list of roles using the params keyword.

Side note: what is params?
You may recall this keyword if you started building a console application and you might have seen it in the main method. By using this keyword, you can send any number of roles that you want, without creating and putting them into an array first.

The params keyword is important as the attributes are evaluated at the runtime, and we cannot instantiate an array to pass to them (we still can instantiate an object inside an attribute).

We would then loop through the roles and check the dictionary to get the string value of it. Finally, we assign the Roles property to those string values, joined by commas ",".

I hope you find this useful. Thanks for reading!

How to have separate staging and testing token enrichment process without creating another Azure AD B2C Tenant.

ramtinmovahed — Thu, 03 Aug 2023 05:31:39 +0000

Azure AD B2C tips

how to have separate staging and testing token enrichment process without creating another Azure AD B2C Tenant.

Based on your use case, you might want a separate process to add custom domains to your user flow. Azure B2C engine needs to call your APIs to get the appropriate claims to include in the JWT token. However, sometimes (especially during the staging environment), you might still want to have two separate API endpoints for Azure to call. One is the backend that sits in the staging environment, and the other one is the endpoint at your local dev environment.
A secure solution would require you to create different Azure tenants for testing and production. However, during the staging environment, you can make the process simpler by using a temporary custom policy that is based on the final policy to call those APIs.

A secure solution would require you to create different Azure tenants for testing and production. However, during the staging environment, you can make the process simpler by using a temporary custom policy that is based on the final policy to call those APIs.

The process is as follows:

ensure that the API endpoints reside in the main user flow policy.
create a duplicate of the custom policy that holds the orchestration steps and the API endpoint's
put the appropriate URLs for each endpoint in each file.
upload it to Azure.
update your application to use the new test policy in the dev environment.

First step

The first step is to check that the technical profile exists in the policy file that contains the user journey.

<TechnicalProfile Id="EnrichToken">
          <DisplayName>...</DisplayName>
          <Metadata>
            <Item Key="ServiceUrl">https://yourendpoint.com/api/.../</Item>
          </Metadata>
          <InputClaims>
            <InputClaim ClaimTypeReferenceId="..." />
            ...
          </InputClaims>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="..."/>
            ...
          </OutputClaims>
          <IncludeTechnicalProfile ReferenceId="...." />
</TechnicalProfile>

Step 2: create the test policy

create a duplicate of that policy file.
Remove all parts that you don't need to change.
include the main policy file as the base policy of the test policy file.
- since the Identity Experience framework has an inheritance model, all information would be included.

<TrustFrameworkPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06" PolicySchemaVersion="0.3.0.0" TenantId="yourtenant.onmicrosoft.com" PolicyId="B2C_1A_yourNewTestPolicyFileName" PublicPolicyUri="http://yourtenant.onmicrosoft.com/B2C_1A_yourNewTestPolicyFileName" TenantObjectId="...">
  <BasePolicy>
    <TenantId>yourtenant.onmicrosoft.com</TenantId>
    <PolicyId>B2C_1A_NameOfPreviousPolicyFile</PolicyId>
  </BasePolicy>
  ....
</TrustFrameworkPolicy>

Step 3: change the endpoints

In the test policy file, replace the endpoint with the development API endpoint.

<ClaimsProviders>
    <ClaimsProvider>
      <DisplayName>...</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="EnrichToken">
          <Metadata>
            <Item Key="ServiceUrl">https://yourdevendpoint.com/api/...</Item>
          </Metadata>
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>
</ClaimsProviders>

Step 4: Upload to Azure

Upload the created test policy to azure.

Final step: updating the application.

Add the custom logic in your application to request this new test policy for authentication in the dev environment.

If you're using Blazor or ASP.NET, you can use the app settings to configure that.

next to appsettings.json, create appsettings.Development.json (case sensitive)
override the values for the policy

  "AzureAd": {
    "Authority": "https://yourtenant.b2clogin.com/yourtenant.onmicrosoft.com/B2C_1A_yourNewTestPolicyFileName"
  }

Finally, test.

Thanks for reading. Have a good day!

expandable card in angular material using button.

ramtinmovahed — Sun, 29 Nov 2020 22:57:43 +0000

In this post, I'm going to implement a simple version of the expandable card with an action button in angular using angular material.

material design

Step 1: base initializations

create a new angular project by running

ng new my-app

we just need the basic functionalities for this demo, so we don't need routing and strict mode.

Then, install angular material by running:

ng add @angular/material

don't forget to enable the browser animations

next, delete the content of app.component.html

Step 2: Import the necessary modules

Based on material design, to implement, we need three components: card, divider, and button.

so in app.module.ts add them to the imports array

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';

import { AppComponent } from './app.component';
import { BrowserAnimationsModule } from '@angular/platform-browser/animations';
import { MatCardModule } from '@angular/material/card';
import { MatButtonModule } from '@angular/material/button';
import { MatDividerModule } from '@angular/material/divider';

@NgModule({
  declarations: [
    AppComponent,

  ],
  imports: [
    BrowserModule,
    BrowserAnimationsModule,
    MatCardModule,
    MatButtonModule,
    MatDividerModule,
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule { }

Step 3: change the template

edit the app.component.html

<mat-card class="card">
  <mat-card-header>
    <mat-card-title>Title</mat-card-title>
    <mat-card-subtitle>Subtitle</mat-card-subtitle>
  </mat-card-header>
  <mat-card-content>
    <p>
      Lorem ipsum, dolor sit amet consectetur adipisicing elit. Exercitationem, praesentium sit tempora numquam vel odit
      dolorem qui quod sint distinctio! Quasi exercitationem tempore voluptas quam voluptatibus distinctio ex magni
      repellendus?
    </p>

    <p [@bodyExpansion]="state" class="expandable-content">
      [expandable] Lorem ipsum, dolor sit amet consectetur adipisicing elit. Exercitationem, praesentium sit tempora
      numquam vel odit
      dolorem qui quod sint distinctio! Quasi exercitationem tempore voluptas quam voluptatibus distinctio ex magni
      repellendus?
    </p>
  <mat-divider>
  </mat-divider>
  </mat-card-content>

  <mat-card-actions>
    <button mat-button (click)="toggle()" color="primary">EXPAND</button>
  </mat-card-actions>

</mat-card>

the bodyExpansion is the name of the animation that we're going to implement next.
We needed to add the mat-divider component as specified in the material design spec.
The state is the name of the property that's responsible for the state of the animations

the toggle method will change this state (as you guest)

Step 4: adding the animations and implementing toggle method

change the content of app.component.ts

import { trigger, state, style, transition, animate } from '@angular/animations';
import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css'],
  animations: [
    trigger('bodyExpansion', [
      state('collapsed, void', style({ height: '0px', visibility: 'hidden' })),
      state('expanded', style({ height: '*', visibility: 'visible' })),
      transition('expanded <=> collapsed, void => collapsed',
        animate('225ms cubic-bezier(0.4, 0.0, 0.2, 1)')),
    ])
  ]
})
export class AppComponent {
  title = 'my-app';

  state = 'collapsed';

  toggle(): void {
    this.state = this.state === 'collapsed' ? 'expanded' : 'collapsed';
  }
}

In the animations array, we defined our animation. The trigger name is bodyExpansion that should match the trigger name that we set in the template. It has two states, collapsed and expanded. The collapsed state defines how the component should look when it's not expanded. So the height is zero and it's hidden.
The expanded state defines how it should look when it's expanded. So the height would be the actual height and it should be visible.
The transition defines how to move between these two states. the void=>collapsed is there to ensure it's collapsed when the component first renders.

The toggle method will change the state property that we defined above.

Final step: add the appropriate styles

In the app.component.css , add the following code

.card {
  width: 500px;
  margin: 50px auto auto auto;
}

.expandable-content {
  overflow: hidden;
}

The thing to note here is the expandable-content class. This class makes the final fixes to the smooth transition.

Hope this was useful, have a nice day!