Using roles in claims identity

[billpratt]

I was happy to see the latest addition of Role scope claims. What is the best way to use these roles in an MVC Owin application using OpenIdConnectConfiguration to restrict access? In the MVC Owin Client sample I have added a SecurityTokenValidated notification in the OpenIdConnectConfigurationOptions where I transfer "role" claims from the identity token to ClaimTypes.Role claims.

Notifications = new OpenIdConnectAuthenticationNotifications
{
    SecurityTokenValidated = async n =>
    {
        var claims = n.AuthenticationTicket.Identity.Claims;
        var roles = from c in claims
                    where c.Type == "role"
                    select c;

        foreach (var role in roles)
        {
            n.AuthenticationTicket.Identity.AddClaim(new Claim(ClaimTypes.Role, role.Value));
        }
    }
}

I added a Test action to the HomeController and gave it role authorize attribute

[Authorize(Roles = "Admin")]
public string Admin()
{
    return "You are an admin";
}

If I authenticate as "bob", who is not an admin, and try to access /Home/Admin, I am left in an infinite loop of authorization where it hits the identity server and then back to my SecurityTokenValidated notification over and over again.

Any idea what I'm doing wrong or what is the best approach to use roles as claims?

[brockallen]

Yes, the OIDC middleware is detecting 401 and automatically redirecting back to the OP STS, even though the user is logged in. You should handle the other events on the notification to prevent that and instead show the user an access denied page.

Also, we've been toying around with an alternative authorization system where an authenticated user that is denied access that we emit a 403 instead. This is a cleaner way to differentiate the need for a token vs. the user is not allowed. Look into the resource authorization stuff we did recently here:

https://github.com/thinktecture/Thinktecture.IdentityModel/commit/ce66b60b59266124f22bf0ff219fd5b937522bda

We only did this so far in the WebApi project, but we're thinking about also doing the same in the Mvc project.

[billpratt]

Ah yes the good ol' 401. Thanks for the quick reply.

I started looking into the IdentityModel project shortly after posting this. Does the new version still support Claims authorization?

[brockallen]

Yea, that's the resource based authorization (the new name, in a sense). The 401/403 is not yet done in the MVC version -- we've not yet had time to test it out. Feel free to make the comparable changes and let us know how it works.

[billpratt]

Will do

On Sep 26, 2014, at 4:58 PM, Brock Allen [email protected] wrote:

Yea, that's the resource based authorization (the new name, in a sense). The 401/403 is not yet done in the MVC version -- we've not yet had time to test it out. Feel free to make the comparable changes and let us know how it works.

—
Reply to this email directly or view it on GitHub.

[brockallen]

BTW, I created a branch on IdentityModel to allow this for MVC apps:

https://github.com/thinktecture/Thinktecture.IdentityModel/tree/mvc_resourceauthorize_403

Feedback welcome.