ASP.NET 9 MVC: Microsoft School Account met lokale rollen

[edeboeck]

Hoi

Ik heb een probleem waar ik met Google/SO/ChatGPT/Claude/Tutorials niet uit raak. Onderstaande toepassing heb ik in het verleden geschreven voor .NET Framework 4.8, maar is nu aan een rewrite toe. Ik ben nieuw in het ASP.NET Core-verhaal, dus maak ik rookie mistakes, zeg dat gerust.

Wie kan me in de juiste richting zetten?
Alvast bedankt!

Context

In een school kunnen gebruikers zich via een webtoepassing registreren voor sportdagactiviteiten: leerlingen kunnen hun keuze (=een keuze uit een lijst die afhankelijk is van het leerjaar) maken voor een activiteit, leerkrachten kunnen kiezen welke activiteit ze begeleiden. De leerlingen schrijven zich in "golven" in: gedurende 1 week kunnen zij hun keuze maken en eventueel nog wijzigen (binnen diezelfde week). Het beginmoment (typisch om 18u) is telkens zeer druk: dan zijn ze met enkele honderden tegelijk aangemeld om toch maar een plaatsje te bemachtigen voor hun favoriete activiteit (uiteraard is het aantal plaatsen per activiteit beperkt).

Technisch

Een ASP.NET 9.0 MVC Web Application waar de gebruikers zich aanmelden met een Microsoft Work or School Account. De rollen "Leerling" en "Leerling" moeten automatisch toegekend worden op basis van de claims uit Entra. Voor een leerling kan ook de klas daaruit afgeleid worden. Daarnaast kunnen in de toepassing zelf de rollen ook beheerd worden: "organisatoren" en "beheerders" kunnen toegewezen worden aan bepaalde gebruikers.
Ik heb een class Persoon met 2 subclasses Leerling en Leerkracht. De class ApplicationUser link ik 1 op 1 met een persoon.
De gebruikers worden opgeslagen in een SQL-Server DB: na aanmelding moet gekeken worden of de gebruiker al in de db zit. Indien wel, worden daaruit de rollen ingeladen. Indien nog niet, worden de rollen automatisch bepaald op basis van de Entra-claims en moeten die zo worden opgeslagen in de DB.

Probleem

Ik slaag er niet om het geheel werkend te krijgen. Het aanmelden op zich met een Microsoft School Account werkt wel (uiteraard), ook het inlezen van de claims uit Entra en het bepalen van de Leerkrachten- en Leerlingen-rollen en deze met een claim toevoegen aan de identity. Mijn appsettings staan dus correct.
Het probleem treedt op wanneer ik de custom middleware (die ik geschreven heb met behulp van Claude) wil gebruik. Ik kan mijn gebruiker nog wel aanmelden bij de Microsoft School Account, maar in mijn toepassing blijft HttpContext.User.Identity.IsAuthenticated false.

Relevante code

Program.cs (ik weet dat het een hele lap is, maar vrees dat dit moeilijk anders kan

C#:

using Microsoft.AspNetCore.Authentication;
using Microsoft.AspNetCore.Authentication.Cookies;
using Microsoft.AspNetCore.Authentication.OpenIdConnect;
using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Identity;
using Microsoft.AspNetCore.Mvc.Authorization;
using Microsoft.Build.Framework;
using Microsoft.EntityFrameworkCore;
using Microsoft.Identity.Web;
using Microsoft.Identity.Web.UI;
using Sportdag_Claude.Data;
using Sportdag_Claude.Infrastructure;
using Sportdag_Claude.Models;
using Sportdag_Claude.Services;


var builder = WebApplication.CreateBuilder(args);

var initialScopes = builder.Configuration["DownstreamApi:Scopes"]?.Split(' ') ?? builder.Configuration["MicrosoftGraph:Scopes"]?.Split(' ');

// Add services to the container.
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
                .AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd"))
                .EnableTokenAcquisitionToCallDownstreamApi(initialScopes)
                .AddMicrosoftGraph(builder.Configuration.GetSection("MicrosoftGraph"))
                .AddInMemoryTokenCaches();

builder.Services.AddControllersWithViews();
builder.Services.AddRazorPages()
    .AddMicrosoftIdentityUI();

builder.Services.AddDbContext<SportdagContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("SportdagContext") ?? throw new InvalidOperationException("Connection string 'SportdagContext' not found.")));

// Na AddDbContext, maar voor de andere services
builder.Services.AddIdentity<ApplicationUser, Rol>(options =>
{
    options.SignIn.RequireConfirmedAccount = false;
    // Configure other options as needed
})
.AddEntityFrameworkStores<SportdagContext>()
.AddDefaultTokenProviders();

builder.Services.Configure<DefinedRoles>(builder.Configuration.GetSection("Rollen"));
builder.Services.AddSingleton<DefinedRoleService>();
builder.Services.AddScoped<UserService>();
builder.Services.AddScoped<RoleMappingService>();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Home/Error");
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseRouting();
app.UseAuthentication();
// Add after UseAuthentication but before UseAuthorization
app.UseMiddleware<SportdagAuthenticationMiddleware>();
app.UseAuthorization();

app.MapStaticAssets();

app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}")
    .WithStaticAssets();

app.MapRazorPages()
   .WithStaticAssets();

app.Run();

UserService

C#:

using Microsoft.AspNetCore.Identity;
using Sportdag_Claude.Data;
using Sportdag_Claude.Models;
using System.Security.Claims;

namespace Sportdag_Claude.Services
{
    public interface IUserService
    {
        Task<ApplicationUser> GetCurrentUserAsync(ClaimsPrincipal claimsPrincipal);
        Task<bool> IsTeacherAsync(ClaimsPrincipal claimsPrincipal);
        Task<bool> IsStudentAsync(ClaimsPrincipal claimsPrincipal);
        Task<int> GetStudentGradeAsync(ClaimsPrincipal claimsPrincipal);
    }

    public class UserService : IUserService
    {
        private readonly UserManager<ApplicationUser> _userManager;
        private readonly SportdagContext _context;
        private readonly ILogger<UserService> _logger;

        public UserService(UserManager<ApplicationUser> userManager, SportdagContext context, ILogger<UserService> logger)
        {
            _userManager = userManager;
            _context = context;
            _logger = logger;
        }
        public async Task<ApplicationUser> GetCurrentUserAsync(ClaimsPrincipal principal)
        {
            // Get Azure AD object ID (unique identifier)
            var objectId = principal.FindFirstValue("http://schemas.microsoft.com/identity/claims/objectidentifier");

            // Check if user exists
            var user = await _userManager.FindByIdAsync(objectId);
            if (user != null)
                return user;

            // Create new user and link to Persoon
            user = new ApplicationUser
            {
                Id = objectId,
                UserName = principal.FindFirstValue("preferred_username"),
                Email = principal.FindFirstValue("email"),
                DisplayName = principal.FindFirstValue("name")
            };

            // Create corresponding Persoon
            //TODO: Implement CreatePersoonFromClaims
            //var persoon = await CreatePersoonFromClaims(principal);
            //user.PersoonId = persoon.Id;

            await _userManager.CreateAsync(user);
            return user;
        }

        public async Task<int> GetStudentGradeAsync(ClaimsPrincipal claimsPrincipal)
        {
            var user = await GetCurrentUserAsync(claimsPrincipal);
            if ((user?.Persoon is Leerling leerling))
            {
                //TODO: Leerjaar implementeren en ophalen
                return -1;
            }
            throw new InvalidOperationException("User is not a student");
        }

        public async Task<bool> IsStudentAsync(ClaimsPrincipal claimsPrincipal)
        {
            var user = await GetCurrentUserAsync(claimsPrincipal);
            return user?.Persoon is Leerling;
        }

        public async Task<bool> IsTeacherAsync(ClaimsPrincipal claimsPrincipal)
        {
            var user = await GetCurrentUserAsync(claimsPrincipal);
            return user?.Persoon is Leerkracht;
        }
    }
}

SportdagAuthenticationMiddleware

C#:

using Sportdag_Claude.Models;
using Sportdag_Claude.Services;
using System.Data;
using System.Security.Claims;

namespace Sportdag_Claude.Infrastructure
{
    public class SportdagAuthenticationMiddleware
    {
        private readonly RequestDelegate _next;
        private readonly ILogger<SportdagAuthenticationMiddleware> _logger;
        private readonly DefinedRoleService _definedRoleService;
        private readonly IServiceScopeFactory _scopeFactory; // nodig omdat de userService scoped (en geen singleton) is

        public SportdagAuthenticationMiddleware(RequestDelegate next,
                                               ILogger<SportdagAuthenticationMiddleware> logger,
                                               DefinedRoleService definedRoleService,
                                               IServiceScopeFactory scopeFactory)
        {
            _next = next;
            _logger = logger;
            _definedRoleService = definedRoleService;
            _scopeFactory = scopeFactory;
        }

        public async Task InvokeAsync(HttpContext context)
        {
            if (context.User.Identity?.IsAuthenticated==true)
            {
                try
                {
                    using var scope = _scopeFactory.CreateScope();
                    var userService = scope.ServiceProvider.GetRequiredService<IUserService>();
                    var roleMappingService = scope.ServiceProvider.GetRequiredService<RoleMappingService>();

                    var user = await userService.GetCurrentUserAsync(context.User);

                    // If user is new or roles need refresh, get roles from Azure AD
                    var objectId = context.User.FindFirstValue("http://schemas.microsoft.com/identity/claims/objectidentifier");
                    var roles = await roleMappingService.GetUserRolesAsync(objectId);

                    // Enrich identity with our application roles
                    // Add claims based on Persoon type (Leerling/Leerkracht)
                    // Create new identity with existing claims
                    var identity = new ClaimsIdentity(context.User.Identity);

                    foreach(var role in roles)
                    {
                        if(!identity.HasClaim(ClaimTypes.Role, role))
                            identity.AddClaim(new Claim(ClaimTypes.Role, role));
                    }

                    // Add role claims based on Persoon type
                    if (user.Persoon!=null)
                    {
                        string roleKey = user.Persoon is Leerling   ? "LL" :
                                         user.Persoon is Leerkracht ? "LK" :
                                         "";
                        string? rolename = _definedRoleService.GetRolnaam(roleKey);
                        if (!string.IsNullOrEmpty(rolename) && !identity.HasClaim(ClaimTypes.Role, rolename))
                            identity.AddClaim(new Claim(ClaimTypes.Role, rolename));

                        // Add special role claims (Admin, Organisator)
                        foreach (var rol in user.Persoon.Rollen)
                        {
                            identity.AddClaim(new Claim(ClaimTypes.Role, rol.Naam));
                        } 
                    }

                    // Replace the current principal
                    context.User = new ClaimsPrincipal(identity);
                }
                catch (Exception ex)
                {
                    _logger.LogError(ex, "ERROR - SportdagAuthenticationMiddleware: Rollen toevoegen aan identity mislukt.");
                }
            }
            await _next(context);
        }
    }
}

[Haan]

De volgorde waarin je middleware toevoegt is belangrijk. Volgens mij staat het al wel goed nu, maar je zou kunnen proberen wat er gebeurt als je app.UseMiddleware<SportdagAuthenticationMiddleware>() en app.UseAuthorization() omdraait. Maar dan krijg je waarschijnlijk het probleem dat de authorization niet werkt omdat je nog geen rollen hebt toegevoegd.

Anders check je gewoon alleen of de User.Identity niet null is Aangezien je daarna toch met rollen aan de slag gaat.

[edeboeck]

Dankjewel voor de reactie @Haan, helaas hielp het niet.
Als ik HttpContext.User.Identity.IsAuthenticated check, blijft die altijd false, ook al zie ik in de url dat ik netjes omgeleid wordt naar login.microsoftonline.com.
Heb je toevallig nog een andere suggestie?

[Cartman!]

Wat heb je precies gedaan aan debugging? Je moet eerst zien te achterhalen waar in je code het precies mis gaat, anders is t schieten met hagel.

[Haan]

edeboeck schreef op vrijdag 10 januari 2025 @ 18:19:
Dankjewel voor de reactie @Haan, helaas hielp het niet.
Als ik HttpContext.User.Identity.IsAuthenticated check, blijft die altijd false, ook al zie ik in de url dat ik netjes omgeleid wordt naar login.microsoftonline.com.
Heb je toevallig nog een andere suggestie?

Wat ik al zei, probeer gewoon niet die check doen. Als het inloggen inderdaad wel werkt, dan zou je wel gewoon de User beschikbaar hebben, dat is voor jou voldoende. In je middleware overschrijf je die User uiteindelijk met een nieuwe principal en claims dus wat er precies binnenkomt maakt dan ook niet zoveel uit.

Overigens is het injecteren van IServiceScopeFactory en daar vervolgens services van opvragen geen best practice, injecteer gewoon direct wat je nodig hebt (IUserService en RoleMappingService)

[ Voor 12% gewijzigd door Haan op 10-01-2025 20:14 ]

[sig69]

Stapje terug: waarom is het aan een rewrite toe? Wat ga je daarmee winnen?

[edeboeck]

Hoi, eerst en vooral: leuk dat jullie meedenken!

Ik ga hieronder in op de verschillende opmerkingen.

Haan schreef op vrijdag 10 januari 2025 @ 16:35:
De volgorde waarin je middleware toevoegt is belangrijk. Volgens mij staat het al wel goed nu, maar je zou kunnen proberen wat er gebeurt als je app.UseMiddleware<SportdagAuthenticationMiddleware>() en app.UseAuthorization() omdraait. Maar dan krijg je waarschijnlijk het probleem dat de authorization niet werkt omdat je nog geen rollen hebt toegevoegd.

Dit lijkt op het eerste zicht geen verschil te geven. Het is natuurlijk wel zo dat ik niet aangemeld geraak, dus een echte controle lijkt me dat niet.

Anders check je gewoon alleen of de User.Identity niet null is Aangezien je daarna toch met rollen aan de slag gaat.

HttpContext.User.Indentity is nooit null, ook al ben ik niet aangemeld (zodoende heb je altijd een Identity waarop je IsAuthenticated kan checken).

Cartman! schreef op vrijdag 10 januari 2025 @ 18:24:
Wat heb je precies gedaan aan debugging? Je moet eerst zien te achterhalen waar in je code het precies mis gaat, anders is t schieten met hagel.

Ik heb al heel veel geprobeerd, maar daar schiet je niet veel mee op, natuurlijk Momenteel probeer ik het zo eenvoudig mogelijk te houden: enkel en alleen een HomeController met breakpoint op Index() (wat default route is). Bij dat breakpoint controleer ik dan de watches die ik heb staan op HttpContext.User en HttpContext.User.Identity. Vervolgens klik ik op de "Sign In"-url (deze linkt area "MicrosoftIdenttity", controller "Account", action "SignIn"). Deze controller en view heb ik niet in mijn solution staan, maar ik veronderstel dat die geïnjecteerd wordt door volgende code in Program.cs:

C#:

builder.Services.AddRazorPages().AddMicrosoftIdentityUI();

Haan schreef op vrijdag 10 januari 2025 @ 20:08:
[...]
Wat ik al zei, probeer gewoon niet die check doen. Als het inloggen inderdaad wel werkt, dan zou je wel gewoon de User beschikbaar hebben, dat is voor jou voldoende. In je middleware overschrijf je die User uiteindelijk met een nieuwe principal en claims dus wat er precies binnenkomt maakt dan ook niet zoveel uit.

Helaas werkt het inloggen dus niet. Ik word wel omgeleid naar login.microsoftonline.com, ontvang ook netjes het 2FA-request indien nodig, maar vervolgens blijft binnen mijn web app de user niet aangemeld. Ik was van mening dat wat binnenkomt wel uitmaakt omdat ik die claims gebruik om zelf enkele rollen te bepalen... zie ik dat verkeerd?

Overigens is het injecteren van IServiceScopeFactory en daar vervolgens services van opvragen geen best practice, injecteer gewoon direct wat je nodig hebt (IUserService en RoleMappingService)

Die aanpassing heb ik, eerlijk is eerlijk, gedaan op advies van Claude, dus heel goed mogelijk dit ik hier (en niet alleen hier) de mist inga. Zonder die constructie krijg ik wel volgende error:
"Cannot resolve scoped service 'Sportdag_Claude.Services.IUserService' from root provider."

Als ik IUserService en zijn implementatie UserService toch registreer als een Singleton (net als de RoleMappingService) zoals in deze code:

C#:

builder.Services.AddSingleton<IUserService, UserService>();
builder.Services.AddSingleton<RoleMappingService>();

dan krijg ik volgende error:
Some services are not able to be constructed (Error while validating the service descriptor 'ServiceType: Sportdag_Claude.Services.IUserService Lifetime: Singleton ImplementationType: Sportdag_Claude.Services.UserService': Cannot consume scoped service 'Microsoft.AspNetCore.Identity.UserManager`1[Sportdag_Claude.Models.ApplicationUser]' from singleton 'Sportdag_Claude.Services.IUserService'.) (Error while validating the service descriptor 'ServiceType: Sportdag_Claude.Services.RoleMappingService Lifetime: Singleton ImplementationType: Sportdag_Claude.Services.RoleMappingService': Cannot consume scoped service 'Microsoft.Graph.GraphServiceClient' from singleton 'Sportdag_Claude.Services.RoleMappingService'.)

sig69 schreef op maandag 13 januari 2025 @ 04:34:
Stapje terug: waarom is het aan een rewrite toe? Wat ga je daarmee winnen?

Goede vraag, ik houd wel van dit out-of-the-box denken. In de vorige versie was het zo dat sommigen maar heel moeilijk aangemeld geraakt wat met héél veel uren Googlen nooit tot een echte oplossing leidde. Bovendien (daaraan gerelateerd) moest ik de ASP.NET-container in het webpanel regelmatig resetten. Dat wilde ik in 1 beweging allemaal oplossen... helaas loop ik dus vast bij het begin.

[ Voor 11% gewijzigd door edeboeck op 13-01-2025 12:06 . Reden: Uitleg van en error bij Singleton-registraties toegevoegd ]

[sig69]

edeboeck schreef op maandag 13 januari 2025 @ 12:00:

[...]
Goede vraag, ik houd wel van dit out-of-the-box denken. In de vorige versie was het zo dat sommigen maar heel moeilijk aangemeld geraakt wat met héél veel uren Googlen nooit tot een echte oplossing leidde. Bovendien (daaraan gerelateerd) moest ik de ASP.NET-container in het webpanel regelmatig resetten. Dat wilde ik in 1 beweging allemaal oplossen... helaas loop ik dus vast bij het begin.

Dit is gelukkig de reden dat wij developers voorlopig onze baan niet kwijt raken aan AI
Ik je zou je toch focussen op het oplossen van de (vage) problemen in de oorspronkelijke applicatie. Als je je applicatie nu herschrijft (wat waarschijnlijk ongeveer hetzelfde wordt) heb je 0 garantie dat de problemen opgelost zijn. Wat je moet doen is debuggen, loggen, monitoren, etc.
1. Wat betekent "sommigen maar heel moeilijk aangemeld geraakt"?
2. "Bovendien (daaraan gerelateerd) moest ik de ASP.NET-container in het webpanel regelmatig resetten". Waarom?

[Haan]

@sig69 je hebt opzich een valide punt hoor, maar .net 48 begint wel echt legacy te worden. Voor een relatief eenvoudige applicatie zoals we hier hebben lijkt het me geen slecht idee om te moderniseren.

@edeboeck Ik heb zelf geen ervaring met inloggen via Microsoft accounts, maar probeer eerst eens de basic tutorial werkend te krijgen: https://learn.microsoft.c...ogins?view=aspnetcore-9.0 Als dat eenmaal is gelukt, kan je van daaruit verder uitbouwen.

[sig69]

4.7 en hoger hebben geen support eind datum, om dat nou legacy te noemen.. Microsoft adviseert zelf ook om bestaande projecten vooral niet te migreren, dus die support blijft nog wel even.

[Haan]

Wel support, maar geen nieuwe features, dus je gaat steeds meer missen. Of je gaat er tegen aan lopen dat je op oude versies van libraries blijft steken (voorbeeld) omdat die geen support blijven leveren, met alle risico's van dien.
Nogmaals, als om een complexe enterprise applicatie gaat geef ik je gelijk, ik heb op m'n werk ook nog tientallen projecten op v4.8 draaien. Maar dat is hier niet aan de orde.

[ Voor 8% gewijzigd door Haan op 14-01-2025 14:55 ]

[sig69]

Ik ook hoor. Maar een rewrite is geen oplossing voor het probleem. Er worden ongeveer 20 stappen overgeslagen. Die problemen zijn vast op te lossen, als je weet wat je doet. Maar TS is een AI developer (no offence, ik vind het knap dat je daar zonder kennis een werkend systeem uit krijgt) en dan schiet de kennis dus te kort om die problemen te troubleshooten.

[edeboeck]

Dankjewel voor het blijven meedenken!

sig69 schreef op dinsdag 14 januari 2025 @ 00:43:
[...]1. Wat betekent "sommigen maar heel moeilijk aangemeld geraakt"?

Dat ze meerdere keren moeten proberen en dat het niet duidelijk is waarom het niet lukt. Het trad het eerst op bij iPhones, maar ook Android-toestellen bleven niet gespaard. Ook in de gebruikte browser was er geen patroon te bespeuren.

2. "Bovendien (daaraan gerelateerd) moest ik de ASP.NET-container in het webpanel regelmatig resetten". Waarom?

Goede vraag: geen idee. Ik heb de logs toen zitten nakijken (generatie m.b.v. ELMAH), maar die brachten geen oorzaak.

Het lijkt er heel fel op dat het met de aanmeldingen te maken heeft (na verloop van tijd te veel requests die blijven hangen of zoiets? - is maar een beredeneerde gok), daarom ben ik nu documentatie aan t lezen rond SameSiteCookies.

Haan schreef op dinsdag 14 januari 2025 @ 10:20:
[...]
@edeboeck Ik heb zelf geen ervaring met inloggen via Microsoft accounts, maar probeer eerst eens de basic tutorial werkend te krijgen: https://learn.microsoft.c...ogins?view=aspnetcore-9.0 Als dat eenmaal is gelukt, kan je van daaruit verder uitbouwen.

Die basis krijg ik werkend: het probleem is net dat ik voorbij de basis wil: aanmelden tegen Microsoft School Account, maar de rollen wel uit lokale db halen.

Mijn plan is alleszins bijgestuurd: in eerste instantie toch maar verdiepen in die SameSiteCookies-instellingen in de hoop onze oude app zo probleemloos werkend te krijgen. Nadien kan dan een clean-up en overgang naar nieuwere versie volgen.

[ Voor 12% gewijzigd door edeboeck op 16-01-2025 11:12 ]