Posted on

How to Create a Blazor WebAssembly Application?

This tutorial is adapted from the Web Age course Progressive Web Application Development Using Entity Framework Core and Blazor Training.

In this tutorial, you will create a Blazor WebAssembly application.

Part 1 – Create a Blazor WebAssembly Application

In this part of the lab, you will create the initial Blazor application.

1. Open Visual Studio.

2. Click Create a new project.

3. Select the Blazor WebAssembly App project template and click Next. You may see Blazor App if you have another Visual Studio version.

4. Enter BlazorTraining as Project Name.

5. Enter C:\LabWorks as Location.

6. Click Next.

7. Ensure .Net 5.0 is selected.

8. Select ASP.NET Core hosted.

9. Click Create.

10. After the project is created, select BlazorTraining.Client.

 

11. Ensure you set Chrome as the default. Click IIS Express → WebBrowser and select Google Chrome.

12. From the menu, run the application by clicking Debug | Start Without Debugging.

In another Visual Studio 2019 version, use Run instead of Debug

If the following dialog opens, click Yes.

If the following dialog opens, click Yes.

13. The browser will open the application. After you review it then close the browser to stop the application.

Part 2 – Add a content page

In this part of the lab, you will add a content page to the application, and integrate it into the application menu.

Currently, the About link in the upper right-hand corner of the application links to general Blazor information on Blazor.net. We want to replace that with a content page that is part of this application.

1. In the BlazorTraining.Client application, right-click on the Pages folder and select Add → Razor Component, naming the new component About.razor

2. Delete the content in the file.

3. Add a page directive to make this a routable component:

@page "/about"

4. If you wish, you can make up some generic “about us” content. You can copy this content from AboutContent.

5. Save the file.

6. Open the Shared → MainLayout.razor file.

7. Edit the About link, changing the href attribute to “/about” and removing the target=”_blank” attribute:

<a href="/about" class="ml-md-auto">About</a>

8. Save the file.

9. Build and debug the application to make sure that clicking the link displays your new page.

Part 3 – Add an interactive page

In this part of the lab, you will add a page whose content will be interactive, governed by some C# code that will be executed in the browser. A button click will show/hide some Frequently Asked Question content.

1. In the BlazorTraining.Client application, right-click on the Pages folder and select Add → Razor Component, naming the new component Faqs.razor

2. Delete the content.

3. Add a page directive to make this a routable component:

@page "/faqs"

4. Write some content with FAQs. You can copy the content from FAQContent.

5. Save the file.

6. Open the Shared → NavMenu.razor component file.

7. Duplicate the third <li> element, change the href attribute of the <NavLink> element to “faqs” and change the text to FAQs:

<li class="nav-item px-3">
    <NavLink class="nav-link" href="faqs">
        <span class="oi oi-list-rich" aria-hidden="true"></span> FAQs
    </NavLink>
</li>

8. Save the file.

9. Compile and debug the application. Verify that the new menu link works. Then stop the debugging session.

Note: The Toggle FAQs button doesn’t function yet.

10. Add the code block for the Faqs razor component and add a boolean variable to control whether the content is visible or not, initializing it to a value of false. Also, create a method that will toggle the value of this variable every time it executes:

@code {
   private bool visible = false;

   private void ToggleVisible() {
       visible = !visible;
   }
}

11. In the content for the Faqs razor component, wrap the <dl> content inside a conditional block that will render the content only if your variable has a value of true:

@if (visible) {
    // <dl> content goes here
}

 

12. In the content for the Faqs razor component, connect the button click event to the toggling function you wrote:

<button @onclick="ToggleVisible">Toggle FAQs</button>

13. Save the file.

14. Compile and debug the application. Verify that clicking the button will show and then hide the FAQ content.

15. Close the browser.

16. Close Visual Studio.

Part 4 – Review

In this tutorial, you created a Blazor WebAssembly application and added a couple of content pages, one static and one dynamically controlled by C# code executing in the browser.

Posted on

Identity Protection and Privileged Identity Management in Azure

This tutorial is adapted from the Web Age course Azure IAM Advanced Training. 

Azure MFA Concepts

The security of MFA is a two-step verification lies in its layered approach.

Authentication methods include:

  • Something you know (typically a password)
  • Something you have (a trusted device that is not easily duplicated, like a phone)

  • Something you are (biometrics)

     

Enabling MFA

Select the users that you want to modify and enable for MFA. User states can be Enabled,  Enforced, or Disabled. On first-time sign-in, after MFA has been enabled, users are prompted to configure their MFA settings. Azure MFA is included free of charge for global administrator security.

 

 

MFA and other identity management features

MFA is required in order to utilize advanced identity management features, such as:

  • Identity Protection (User risk and Sign-in risk)
  • Privileged Identity Management

Azure AD Identity Protection

Risk detections in Azure AD Identity Protection include any identified suspicious actions related to user accounts in the directory. Identity Protection provides organizations access to powerful resources to see and respond quickly to these suspicious actions.

 

Risk Events

Each detected suspicious action is stored in a record called a risk event.

  • Leaked credentials
  • Sign in from anonymous IP addresses
  • Impossible travel to typical locations
  • Sign-in from unfamiliar locations
  • Sign-ins from infected devices
  • Sign-ins from IP addresses with suspicious activity

Risk levels

Identity Protection categorizes risk into three tiers:

  • low
  • medium
  • high

While Microsoft does not provide specific details about how risk is calculated, we will say that each level brings higher confidence that the user or sign-in is compromised.

Sign-in risk

The sign-in risk policy detects suspicious actions that come along with the sign-in. It is focused on the sign-in activity itself and analyzes the probability that the sign-in may not have been performed by the user. The sign-in risk checks for things like whether a user has signed in from an unfamiliar location or an unfamiliar IP address. You can then choose to require MFA for users based on the risk level of their sign-ins. 

These risks are calculated using threat intelligence sources including security researchers, law enforcement professionals, security teams at Microsoft, and other trusted sources.

  • Anonymous IP address (e.g. ToR browser or anonymous VPN)
  • Atypical travel/Impossible travel/New country
  • Malicious IP address
  • Admin confirmed user compromised

Sign-in Risk Policy

It is applied to all browser traffic and sign-ins using modern authentication. It automatically responds to a specific risk level. It provides the condition (risk level) and action (block or allow). It targets all policies to specific users – omits certain types of users.

User Risk

The user risk policy detects the probability that a user account has been compromised. Risk events require the recording of a user’s activity over a length of time so that it’s possible to detect abnormalities. You can then choose to block access to users based on their risk levels. User risk is typically determined based on leaked credentials.

Microsoft finds leaked credentials in a variety of places, including:

  • Public paste sites such as pastebin.com and paste.ca.
  • Law enforcement agencies.
  • Other groups at Microsoft doing dark web research.

User Risk Policy

It is Applied to user sign-ins. It provides the condition (risk level) and action(block or allow). It automatically responds based on a specific user’s risk level. It uses a high threshold during policy roll-out. It uses a low threshold for greater security. 

Risky Sign-ins Report

The risky sign-ins report contains filterable data for up to the past 30 days (1 month).  With the information provided by the risky sign-ins report, administrators can find:

  • Which sign-ins are classified as at risk, confirmed compromised, confirmed safe, dismissed, or remediated.
  • Detection types triggered
  • MFA details
  • Device information
  • Application information
  • Location information