Add support for scopes based on AD group IDs + reject user if required scopes aren't added

[alexluckett]

Scope support

• Reads AD groups and maps them to scopes in ./designer/server/src/common/helpers/auth/azure-oidc.js. This is then propogated to the cookie-based session and validated on /auth/callback.
• As a temporary measure until more fine-grained scope support is added around the app, if no scopes are assigned to the user they will be rejected from the login process and their session will be dropped. This means we can easily support extra scopes in the future (e.g. superadmins, guest readers, etc) while having the short term goal met of rejecting users with insufficient privileges.

UI changes

• A new sign-in screen is the new landing page, replacing the previous "you are signed out" screen
• If a user has insufficient scopes, an error message is displayed on the sign-in screen. The user will never see that they are logged in, as we log them in, check their scopes, and immediately drop their session if they don't have permission.

[colinrotherham]

I'm getting an error that credentials.scope isn't typed

Should we be using the scope(request) handler instead?

In the deleted code there seemed to be some nice auth.access.scope examples, should we not try to keep them maintained?

  options: {
    auth: {
      access: {
        scope: ['+mockScope']
      },
      mode: 'required'
    }
  },

[alexluckett]

I don't think so. That function is per request, rather than when the token is received. We only need to grab their groups when the user is signing in or is refreshed. My understanding of the scope handler is where you want to elevate the user's access based on a specific request, which wouldn't be the case here.

credentials.scope is something I'm still trying to work out. It's definitely the right way to do it, I'm a bit puzzled though at the type errors. The docs indicate it's a property of credentials, as does a few guides I found online.

[colinrotherham]

Probably Bell using its own bespoke request types?

You'll see in #145 (comment) that credentials.scope is typed correctly there?

Be good to move the code into createUserSession() so the compiler can check our homework

      // Create user session
      const credentials = await createUserSession(request)

      if (!credentials?.user) {
        return Boom.unauthorized()
      }
      
+     if (!credentials?.scope) {
+       // Do the flashy auth failed thing
+     }

[alexluckett]

Done

[alexluckett]

In the deleted code there seemed to be some nice auth.access.scope examples, should we not try to keep them maintained?

Looking at this now. It's a CDP thing but we can use it, might be a good way to keep the route permissions centralised somewhere.