Authentication and Secure Pages

Authentication and secure pages

Imp integrates with host-provided ASP.NET Core authentication. It does not authenticate users itself.

Configure the host first

Register an actual authentication scheme and place authentication/authorization middleware before Imp:

builder.Services
   .AddAuthentication(/* defaults */)
   .AddCookie(/* options */);

var app = builder.Build();
app.UseAuthentication();
app.UseAuthorization();
app.UseImp(/* configuration */);

Mark and authenticate pages

Add [SecurePage] to a page:

using Imp.TemplateManagers;

[SecurePage]
public sealed class Account : BasePage { }

Then configure the callback:

.Authenticate((context, page) =>
{
   if (context.User.Identity?.IsAuthenticated == true)
      return true;

   context.Response.Redirect("/login");
   return false;
})

Returning false stops pre-render, postback, and page rendering. The callback must set an appropriate response—redirect, 401, or 403.

Important: [SecurePage] alone does nothing when no Authenticate callback is configured. Treat configuring both pieces as one security requirement and cover it with integration tests.

Authentication versus authorization

The callback can inspect the page type, claims, roles, policies, route, and request. Authentication only establishes identity; pages that require ownership or a particular permission still need authorization.

For complicated policy evaluation, resolve an authorization service before Imp or design an application service used by the callback. Avoid scattering claim-string comparisons through page rendering methods.

Secure postbacks

Authentication does not replace antiforgery protection. A secure state-changing page should require:

1. an authenticated identity;
2. authorization for the action/record;
3. a valid antiforgery token;
4. server-side input validation.

Never rely on hidden fields for ownership. Reload the target under the authenticated user before changing it.

Redirect safety

Validate return URLs as local before redirecting after login. Do not send users to arbitrary query-string URLs. For API-like responses, prefer 401/403 over an HTML login redirect.