1
votes

I have an MVC project that uses Azure AD as a connected service for single sign-on authentication of the user. That works fine, and any controller with the [Authorize] attribute works as expected.

I have two app roles defined in Azure for this application, and I've assigned myself to both of them. But when I add [Authorize(Roles="foo")] to a controller, the application redirects to Microsoft to ask for another sign in, and then continues to do that forever. I can't tell whether the roles aren't being passed back in the token, or whether MVC is failing to pick up the roles that are being passed back.

I've tried using KentorOwinCookieSaver but that didn't seem to address the problem.

Is there an additional step I need to take to get MVC to recognize the Azure appRoles? I'm not using Identity Manager or storing any user info in the database.

Here's my Startup.Auth:

 public void ConfigureAuth(IAppBuilder app)
    {
        app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);

        app.UseCookieAuthentication(new CookieAuthenticationOptions
        { CookieSecure = CookieSecureOption.Always,
        CookieManager = new Microsoft.Owin.Host.SystemWeb.SystemWebChunkingCookieManager()});

        app.UseOpenIdConnectAuthentication(
            new OpenIdConnectAuthenticationOptions
            {
                ClientId = clientId,
                Authority = Authority,
                PostLogoutRedirectUri = postLogoutRedirectUri,

                Notifications = new OpenIdConnectAuthenticationNotifications()
                {
                    // If there is a code in the OpenID Connect response, redeem it for an access token and refresh token, and store those away.
                    AuthorizationCodeReceived = (context) =>
                    {
                        var code = context.Code;
                        ClientCredential credential = new ClientCredential(clientId, appKey);
                        string signedInUserID = context.AuthenticationTicket.Identity.FindFirst(ClaimTypes.NameIdentifier).Value;
                        AuthenticationContext authContext = new AuthenticationContext(Authority, new NaiveSessionCache(signedInUserID));
                        return authContext.AcquireTokenByAuthorizationCodeAsync(
                           code, new Uri(HttpContext.Current.Request.Url.GetLeftPart(UriPartial.Path)), credential, graphResourceId);
                    },
                    AuthenticationFailed = (context) =>
                    {
                        context.HandleResponse();
                        context.Response.Redirect("/Home/Error?message=" + context.Exception.Message);
                        return Task.FromResult(0);
                    }
                }
            });
    }
1
Are you sure that the rule is already exists and assigned to the logged in member?Marzouk
Yes, the role exists and is assigned to my Azure AD account, which is the account being authenticated against.Matthew
Do you see those role names in access token?Win
They're in the token. A closer look reveals a silly mistake on my end. The role names returned in the token don't match the role names on the Azure management screen. Thanks for making me take a second look!Matthew

1 Answers

0
votes

This turned out to be a ridiculous mistake on my end. After looking at the token again, at Win's prompting, and comparing it to the app registration manifest in the Azure portal, I see the problem. I was trying to use the "displayName" of the role, which is what is displayed on the administration screens, rather than the "value" which is, predictably, the value passed back with the token.

Oops.