From Windows sign-in to Microsoft Entra ID

When Ms. Aydin opens the Order Book, her name is in the title bar. She has not signed in anywhere. Windows signed her in when she unlocked her computer in the morning, and the program only asks Windows who is there and in which group. That is break point B3, and it is the most convenient one in the whole program: no sign-in dialog, no password, no failure case.

On the web there is no such silent help. Every request to the web API from module 4 comes from somewhere, and the server has to know provably from whom. This lesson replaces the silent sign-in with Microsoft Entra ID. How sign-in and permissions work in ASP.NET Core in general is covered in K2, module 2.6 (Signing in and permissions). What is special about the Order Book is covered here: three programs that have to recognize the same person, and a transition in which the old and the new program run side by side.

What the Windows sign-in silently does

This is how the check has stood in the program since lesson M1.2:

using System.Security.Principal;

namespace Brandt.OrderBook
{
    // BREAK B3: Who is this, and in which group? Windows answers that, silently and without a sign-in page.
    internal static class Permissions
    {
        public static string User
        {
            get { return WindowsIdentity.GetCurrent().Name; }
        }

        // Dispatch may edit; everyone else reads only. Without a group in the configuration, everyone may (local development).
        public static bool CanEdit
        {
            get
            {
                string group = Settings.DispatchGroup;
                if (string.IsNullOrEmpty(group))
                {
                    return true;
                }

                return new WindowsPrincipal(WindowsIdentity.GetCurrent()).IsInRole(group);
            }
        }
    }
}

Windows answers two questions here without anyone asking them. The table shows what each one becomes on the web:

The second row of the table is the most important. In the Windows program, the check sits where the user interface sits: Whoever changes the program changes the check. Microsoft's documentation on Windows programs with a protected web API says it explicitly for line-of-business programs: The service remains the security boundary for shared data; it validates tokens, enforces the permissions and performs the data access. The Windows program may cache data, but it decides nothing. That is the reason for the next lesson, M5.2: Permissions apply where the data lives.