[Bug] AccessDenied Routing

[mattosaurus]

Which Version of Microsoft Identity Web are you using ?
Microsoft.Identity.Web - v0.1.0 Preview
Microsoft.Identity.Web.UI - v0.1.0 Preview

Where is the issue?

• Web App
  • Sign-in users
  • Sign-in users and call web APIs
• Web API
  • Protected web APIs (Validating tokens)
  • Protected web APIs (Validating scopes)
  • Protected web APIs call downstream web APIs
• Token cache serialization
  • In Memory caches
  • Session caches
  • Distributed caches

Is this a new or existing app?
c. This is a new app or experiment

Repro

Clone and run the below sample project.

https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/blob/master/5-WebApp-AuthZ/5-2-Groups

Log in with an unauthorized account.

Expected behavior
Unauthorized account should be redirected to /MicrosoftIdentity/Account/AccessDenied.

Actual behavior
Unauthorized account is redirected to /Account/AccessDenied which doesn't exist.

Possible Solution
The Microsoft.Identity.Web.UI AccountController exists in the MicrosoftIdentity area but there doesn't seem to be a way to provide the AccessDenied response with this route info.

I'd expect this to be configurable using something like the AccessDenied property like this but it doesn't seem to work.

services.Configure<OpenIdConnectOptions>(options =>
{
	// Use the groups claim for populating roles
	options.TokenValidationParameters.RoleClaimType = "groups";
	options.AccessDeniedPath = "/MicrosoftIdentity/Account/AccessDenied";
});

Possibly this is a redirect URL that should be set in the portal but it's not obvious where this is.

A workaround is to create an account controller with the required view but this goes against the point of Microsoft.Identity.Web.UI.

[jmprieur]

@mattosaurus

as a work around you could specify your page yourself doing the following:

public void ConfigureServices(IServiceCollection services)
{
services.AddSignIn(Configuration);
services.Configure(OpenIdConnectDefaults.AuthenticationScheme,
options => {
// Use the groups claim for populating roles
options.TokenValidationParameters.RoleClaimType = "groups";
options.AccessDeniedPath = "/MicrosoftIdentity/Account/AccessDenied";
});

// More code here ...

}

[jmprieur]

Spec

Why?

See issue above

What?

When using .AddMicrosoftIdentityUI, we should override the AccessDeniedPath to be "/MicrosoftIdentity/Account/AccessDenied"

[creativebrother]

services.AddSignIn(Configuration, "AzureAd");
JwtSecurityTokenHandler.DefaultMapInboundClaims = false;
services.Configure(OpenIdConnectDefaults.AuthenticationScheme, options =>
{
// Use the groups claim for populating roles
options.TokenValidationParameters.RoleClaimType = "roles";
options.AccessDeniedPath = "/MicrosoftIdentity/Account/AccessDenied";
});
work around by specifying AccessDeniedPath seems not working either for this 0.1.2-preview.

[pmaytak]

Yes, seems like specifying AccessDeniedPath on OpenIdConnectOptions doesn't work.

Specifying the path on CookieAuthenticationOptions works:

services.Configure<CookieAuthenticationOptions>(CookieAuthenticationDefaults.AuthenticationScheme, options => {
    options.AccessDeniedPath = new PathString("/MicrosoftIdentity/Account/AccessDenied");
});

The scheme has to be the same as what is passed into AddSignIn method (or default CookieAuthenticationDefaults.AuthenticationScheme) because that is what is passed in

microsoft-identity-web/src/Microsoft.Identity.Web/WebAppAuthenticationBuilderExtensions.cs

Line 82 in 4458dbf

builder.AddCookie(cookieScheme);

From logging we can see that when the user is unauthorized and the code above is not used, cookie and OIDC handlers fail and redirect to /Account/AccessDenied... is done.

When the above fix is used, after the handlers fail to authorize, the redirect is made to a correct page.

I looked through the ASP.NET Core repo and really the only references to AccessDeniedPath I found were related to cookies.

The default path value is in CookieAuthenticationDefaults.

If the custom path is not specified, it is set to default in PostConfigureCookieAuthenticationOptions PostConfigure.

CookieAuthenticationHandler builds the URI and redirects in HandleForbiddenAsync.

[jmprieur]

Thanks for investigating, @pmaytak
Do you want to propose a fix?

[creativebrother]

So by default CookieAuthenticationHandler will be called anyway even though if one does not use cookieauthentication scheme explicitly within asp.net core?

[pmaytak]

Well the AccessDeniedPath seems to be used from the scheme that was assigned to
OpenIdConnectOptions.SignInScheme in AddSignIn method, which in our case is the cookie scheme.

microsoft-identity-web/src/Microsoft.Identity.Web/WebAppAuthenticationBuilderExtensions.cs

Line 85 in 35a76fd

options.SignInScheme = cookieScheme;

I reckon cookie handler will only be called if cookie scheme is enabled.

[jennyf19]

In 0.1.4-preview release