{"id":52234,"date":"2020-04-27T08:00:19","date_gmt":"2020-04-27T06:00:19","guid":{"rendered":"https:\/\/code-maze.com\/?p=52234"},"modified":"2022-01-11T16:53:50","modified_gmt":"2022-01-11T15:53:50","slug":"identityserver4-authorization","status":"publish","type":"post","link":"https:\/\/code-maze.com\/identityserver4-authorization\/","title":{"rendered":"IdentityServer4 Authorization and Working with Claims"},"content":{"rendered":"

We can use claims to show identity-related information in our application but, we can use it for the authorization process as well. In this article, we are going to learn how to modify our claims and add new ones. Additionally, we are going to learn about the IdentityServer4 Authorization process and how to use Roles to protect our endpoints.<\/p>\n

To download the source code for the client application, you can visit the IdentityServer4 Authorization<\/a> repository.<\/div>\n

To navigate through the entire series, visit the\u00a0IdentityServer4 series\u00a0<\/a>page.<\/p>\n

So, let\u2019s get down to business.<\/p>\n

Modifying Claims<\/h2>\n

If we inspect our decoded id_token<\/code> with the claims on the Privacy page, we are going to find some naming differences:<\/p>\n

\"Different<\/a><\/p>\n

So, what we want to do is to ensure that our claims stay the same as we define them, instead of being mapped to different claims. For example, the nameidentifier claim is mapped from the sub claim, and we want it to stay the sub claim. To do that, we have to slightly modify the constructor in the client\u2019s Startup<\/code> class:<\/p>\n

public Startup(IConfiguration configuration)\r\n{\r\n    Configuration = configuration;\r\n    JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();\r\n} \r\n<\/pre><\/p>\n
For this to work, we have to add the System.IdentityModel.Tokens.Jwt<\/code> using statement.<\/p>\n
Now, we can start our application, log out from the client, log in again, and check the Privacy page:<\/p>\n
\"Correct<\/a><\/p>\n
We can see our claims are the same as we defined them at the IDP (Identity Provider) level.<\/p>\n
If there are some claims we don\u2019t want to have in the token, we can remove them. To do that, we have to use the ClaimActions<\/code> in the OIDC configuration:<\/p>\n
.AddOpenIdConnect("oidc", opt =>\r\n{\r\n    opt.SignInScheme = "Cookies";\r\n    opt.Authority = "https:\/\/localhost:5005";\r\n    opt.ClientId = "mvc-client";\r\n    opt.ResponseType = "code id_token";\r\n    opt.SaveTokens = true;\r\n    opt.ClientSecret = "MVCSecret";\r\n    opt.GetClaimsFromUserInfoEndpoint = true;\r\n\r\n    opt.ClaimActions.DeleteClaim("sid");\r\n    opt.ClaimActions.DeleteClaim("idp");\r\n});\r\n<\/pre><\/p>\n
The DeleteClaim<\/code> method exists in the Microsoft.AspNetCore.Authentication<\/code> namespace. As a parameter, we pass a claim we want to remove. Now, if we start our client again and navigate to the Privacy page, these claims will be missing for sure (Log out and log in prior to checking the Privacy page).<\/p>\n
If you don\u2019t want to use the DeleteClaim<\/code> method for each claim you want to remove, you can always use the DeleteClaims<\/code> method:<\/p>\n
opt.ClaimActions.DeleteClaims(new string[] { \"sid\", \"idp\" });<\/code><\/p>\n
Let\u2019s move on.<\/p>\n
Adding Additional Claims<\/h2>\n
If we want to add additional claims to our token (address, for example),\u00a0 we can do that with a few simple steps. The first step is to support a new identity resource in the InMemoryConfig<\/code> class in the IDP project :<\/p>\n
public static IEnumerable<IdentityResource> GetIdentityResources() =>\r\n    new List<IdentityResource>\r\n    {\r\n        new IdentityResources.OpenId(),\r\n        new IdentityResources.Profile(),\r\n        new IdentityResources.Address()\r\n    };\r\n<\/pre><\/p>\n
Then, we have to add it to our client\u2019s allowed scopes:<\/p>\n
new Client\r\n{\r\n    ClientName = "MVC Client",\r\n    ClientId = "mvc-client",\r\n    AllowedGrantTypes = GrantTypes.Hybrid,\r\n    RedirectUris = new List<string>{ "https:\/\/localhost:5010\/signin-oidc" },\r\n    AllowedScopes =\r\n    { \r\n       IdentityServerConstants.StandardScopes.OpenId, \r\n       IdentityServerConstants.StandardScopes.Profile, \r\n       IdentityServerConstants.StandardScopes.Address \r\n    },\r\n    ClientSecrets = { new Secret("MVCSecret".Sha512()) },\r\n    PostLogoutRedirectUris = new List<string> { "https:\/\/localhost:5010\/signout-callback-oidc" }\r\n}\r\n<\/pre><\/p>\n
And lastly, we have to add the address claim for our users:<\/p>\n
new TestUser\r\n{\r\n    SubjectId = "a9ea0f25-b964-409f-bcce-c923266249b4",\r\n    Username = "Mick",\r\n    Password = "MickPassword",\r\n    Claims = new List<Claim>\r\n    {\r\n        new Claim("given_name", "Mick"),\r\n        new Claim("family_name", "Mining"),\r\n        new Claim("address", "Sunny Street 4")\r\n    }\r\n},\r\nnew TestUser\r\n{\r\n    SubjectId = "c95ddb8c-79ec-488a-a485-fe57a1462340",\r\n    Username = "Jane",\r\n    Password = "JanePassword",\r\n    Claims = new List<Claim>\r\n    {\r\n        new Claim("given_name", "Jane"),\r\n        new Claim("family_name", "Downing"),\r\n        new Claim("address", "Long Avenue 289")\r\n    }\r\n}\r\n<\/pre><\/p>\n
And, that\u2019s all it takes regarding the InMemoryConfig<\/code> class.<\/p>\n
One more thing. If we want to see the consent page for a specific client, we can enable that in the Client configuration in the OAuth project:<\/p>\n
ClientSecrets = { new Secret("MVCSecret".Sha512()) },\r\nPostLogoutRedirectUris = new List<string> { "https:\/\/localhost:5010\/signout-callback-oidc" },\r\nRequireConsent = true<\/pre><\/p>\n
Now, we have to modify the Client application, by adding the new scope to the OIDC configuration:<\/p>\n
.AddOpenIdConnect("oidc", opt =>\r\n{\r\n    \/\/previous code\r\n\r\n    opt.ClaimActions.DeleteClaim("sid");\r\n    opt.ClaimActions.DeleteClaim("idp");\r\n\r\n    opt.Scope.Add("address");\r\n});\r\n<\/pre><\/p>\n
If we log out and log in again, we are going to see a new scope in the Consent<\/code> screen:<\/p>\n
\"Additional<\/a><\/p>\n
But, if we inspect the Privacy page, we won\u2019t be able to find the address claim there. That\u2019s because we didn\u2019t map it to our claims. Of course, we can inspect the console logs to make sure the IdentityServer returned our new claim:<\/p>\n
\"Address<\/a><\/p>\n
But if we want to include it, we can modify the OIDC configuration:<\/p>\n
opt.ClaimActions.MapUniqueJsonKey(\"address\", \"address\");<\/code><\/p>\n
After we log in again, we can find the address claim on the Privacy page.<\/p>\n
We just want to mention if you don\u2019t need all the additional claims for your entire application but just for one part of it, the best practice is not to map all the claims. You can always get them with the IdentityModel<\/code> package by sending the request to the \/userinfo<\/code> endpoint. By doing that, we ensure our cookies are small in size and that we get always up-to-date information from the userinfo endpoint.<\/p>\n
Getting Claims Manually from the UserInfo Endpoint<\/h2>\n
So, let\u2019s see how we can extract the address claim from the \/userinfo<\/code> endpoint. The first thing we have to do is to remove the MapUniqueJsonKey(\u201eaddress\u201c, \u201eaddress\u201c)<\/code> statement from the OIDC configuration.<\/p>\n
Then, let\u2019s install the required package:<\/p>\n
\"IdentityModel<\/a><\/p>\n
After that, let\u2019s modify the Privacy<\/code> action in the Home<\/code> controller:<\/p>\n
public async Task<IActionResult> Privacy()\r\n{\r\n    var client = new HttpClient();\r\n    var metaDataResponse = await client.GetDiscoveryDocumentAsync(\"https:\/\/localhost:5005\");\r\n\r\n    var accessToken = await HttpContext.GetTokenAsync(OpenIdConnectParameterNames.AccessToken);\r\n\r\n    var response = await client.GetUserInfoAsync(new UserInfoRequest\r\n    {\r\n        Address = metaDataResponse.UserInfoEndpoint,\r\n        Token = accessToken\r\n    });\r\n\r\n    if(response.IsError)\r\n    {\r\n        throw new Exception(\"Problem while fetching data from the UserInfo endpoint\", response.Exception);\r\n    }\r\n\r\n    var addressClaim = response.Claims.FirstOrDefault(c => c.Type.Equals(\"address\"));\r\n\r\n    User.AddIdentity(new ClaimsIdentity(new List<Claim> { new Claim(addressClaim.Type.ToString(), addressClaim.Value.ToString()) }));\r\n\r\n    return View();\r\n}\r\n<\/pre>\n
So, we create a new client object and fetch the response from the IdentityServer with the GetDiscoveryDocumentAsync<\/code> method. This response contains our required \/userinfo<\/code> endpoint\u2019s address. After that, we extract the access token and use the UserInfo<\/code> address and extracted token to fetch the required user information. If the response is successful, we extract the address claim from the claims list and just add it to the User.Claims<\/code> list (this is the list of Claims we iterate through in the Privacy view).<\/p>\n
Now, if we log in again, and navigate to the Privacy page, we are going to see the address claim again. But this time, we extracted it manually. So basically, we can use this code only when we need it in our application.<\/p>\n
IdentityServer4 Authorization<\/h2>\n
Authorization is the process of determining what you are allowed to do once authenticated. The id_token<\/code> helps us with the authentication process while the access_token<\/code> helps us with the authorization process because it authorizes a web client application to communicate with the web api.<\/p>\n
So, let\u2019s start with the InMemoryConfig<\/code> class modification, by adding roles to our users:<\/p>\n
public static List<TestUser> GetUsers() =>\r\n    new List<TestUser>\r\n    {\r\n        new TestUser\r\n        {\r\n\t     \/\/previous code\r\n\r\n            Claims = new List<Claim>\r\n            {\r\n                new Claim("given_name", "Mick"),\r\n                new Claim("family_name", "Mining"),\r\n                new Claim("address", "Sunny Street 4"),\r\n                new Claim("role", "Admin")\r\n            }\r\n        },\r\n        new TestUser\r\n        {\r\n            \/\/previous code\r\n\r\n            Claims = new List<Claim>\r\n            {\r\n                new Claim("given_name", "Jane"),\r\n                new Claim("family_name", "Downing"),\r\n                new Claim("address", "Long Avenue 289"),\r\n                new Claim("role", "Visitor")\r\n            }\r\n        }\r\n   };\r\n<\/pre><\/p>\n
We have to create a new identity scope in the GetIdentityResources<\/code> method:<\/p>\n
public static IEnumerable<IdentityResource> GetIdentityResources() =>\r\n    new List<IdentityResource>\r\n    {\r\n        new IdentityResources.OpenId(),\r\n        new IdentityResources.Profile(),\r\n        new IdentityResources.Address(),\r\n        new IdentityResource("roles", "User role(s)", new List<string> { "role" })\r\n    };\r\n<\/pre><\/p>\n
And, we have to add roles scope to the allowed scopes for our MVC Client:<\/p>\n
AllowedScopes =\r\n{ \r\n    IdentityServerConstants.StandardScopes.OpenId, \r\n    IdentityServerConstants.StandardScopes.Profile, \r\n    IdentityServerConstants.StandardScopes.Address,\r\n    "roles"\r\n},\r\n<\/pre><\/p>\n
With this, we have finished the modification of the IDP application. Let\u2019s continue with the client application by modifying the OIDC configuration to support roles scope:<\/p>\n
.AddOpenIdConnect("oidc", opt =>\r\n{\r\n    \/\/previous code\r\n\r\n    opt.Scope.Add("address");\r\n    \/\/opt.ClaimActions.MapUniqueJsonKey("address", "address");\r\n\r\n    opt.Scope.Add("roles");\r\n    opt.ClaimActions.MapUniqueJsonKey("role", "role");\r\n});\r\n<\/pre><\/p>\n
So, we want to allow Create, Edit, Details, and Delete actions only to users with the Admin role. To do that, we are going to modify the Index<\/code> view:<\/p>\n
@if (User.IsInRole("Admin"))\r\n{\r\n    <p>\r\n        <a asp-action="Create">Create New<\/a>\r\n    <\/p>\r\n}\r\n<table class="table">\r\n    \r\n    \/\/previous code\r\n\r\n    <tbody>\r\n        @foreach (var item in Model)\r\n        {\r\n            <tr>\r\n                \/\/previous code\r\n\r\n                @if (User.IsInRole("Admin"))\r\n                {\r\n                    <td>\r\n                        @Html.ActionLink("Edit", "Edit", new { \/* id=item.PrimaryKey *\/ }) |\r\n                        @Html.ActionLink("Details", "Details", new { \/* id=item.PrimaryKey *\/ }) |\r\n                        @Html.ActionLink("Delete", "Delete", new { \/* id=item.PrimaryKey *\/ })\r\n                    <\/td>\r\n                }\r\n            <\/tr>\r\n        }\r\n    <\/tbody>\r\n<\/table>\r\n<\/pre><\/p>\n
We use the IsInRole<\/code> method to allow only Admin users to see these links.<\/p>\n
Finally, we have to state where our framework can find the user\u2019s role:<\/p>\n
.AddOpenIdConnect("oidc", opt =>\r\n{\r\n    \/\/previous code\r\n\r\n    opt.Scope.Add("roles");\r\n    opt.ClaimActions.MapUniqueJsonKey("roles", "role");\r\n\r\n    opt.TokenValidationParameters = new TokenValidationParameters\r\n    {\r\n        RoleClaimType = "role"\r\n    };\r\n});\r\n<\/pre><\/p>\n
The TokenValidationParameters<\/code> class exists in the Microsoft.IdentityModel.Tokens<\/code> namespace.<\/p>\n
Now, we can start our applications and login with Jane’s account:<\/p>\n
\"Roles<\/a><\/p>\n
We can see an additional scope in the Consent screen. Once we allow this, we can see the Index view but without additional actions. That\u2019s because Jane is in the Visitor role. If we log out and log in with Mick, we are going to see those links for sure.<\/p>\n
Excellent.<\/p>\n
But can we protect our endpoints with roles as well? Of course, we can. Let\u2019s see how to do it.<\/p>\n
Using Roles to Protect Endpoints<\/h2>\n
Le\u2019s say, for example, only the Admin users can access the Privacy page. Well, with the same action we did in a previous part, we can show the Privacy link in the _Layout<\/code> view:<\/p>\n
<ul class="navbar-nav flex-grow-1">\r\n    <li class="nav-item">\r\n        <a class="nav-link text-dark" asp-area="" asp-controller="Home" asp-action="Index">Home<\/a>\r\n    <\/li>\r\n    @if (User.IsInRole("Admin"))\r\n    {\r\n        <li class="nav-item">\r\n            <a class="nav-link text-dark" asp-area="" asp-controller="Home" asp-action="Privacy">Privacy<\/a>\r\n        <\/li>\r\n    }\r\n    @if (User.Identity.IsAuthenticated)\r\n    {\r\n        <li class="nav-item">\r\n            <a class="nav-link text-dark" asp-area="" asp-controller="Authentication" asp-action="Logout">Logout<\/a>\r\n        <\/li>\r\n    }\r\n<\/ul>\r\n<\/pre><\/p>\n
If we log in as Jane, we won\u2019t be able to see the Privacy link:<\/p>\n
\"Hidden<\/a><\/p>\n
Even though we can\u2019t see the Privacy link, we still have access to the Privacy page by entering a valid URI address:<\/p>\n
\"Accessed<\/a><\/p>\n
So, what we have to do is to protect our Privacy endpoint with the user\u2019s role:<\/p>\n
[Authorize(Roles = "Admin")]\r\npublic async Task<IActionResult> Privacy()\r\n<\/pre><\/p>\n
Now, if we log out, log in again as Jane, and try to use the URI address to access the privacy page, we won\u2019t be able to do that:<\/p>\n
\"IdentityServer4<\/a><\/p>\n
The application redirects us to the \/Account\/AccessDenied page, but we get 404 because we don\u2019t have that page.<\/p>\n
So, let\u2019s create it.<\/p>\n
The first thing we are going to do is to add a new action in the Account controller:<\/p>\n
public IActionResult AccessDenied()\r\n{\r\n    return View();\r\n}\r\n<\/pre>\n
And, let\u2019s create a view for this action:<\/p>\n
@{\r\n    ViewData[\"Title\"] = \"AccessDenied\";\r\n}\r\n\r\n<h1>AccessDenied<\/h1>\r\n\r\n<h3>You are not authorized to view this page.<\/h3>\r\n\r\n<p>\r\n    You can always <a asp-controller=\"Account\" asp-action=\"Logout\">log in as someone else<\/a>.\r\n<\/p>\r\n<\/pre>\n
After these changes, we can log out and log in as Jane. Once we navigate to the \/Home\/Privacy URI, we are going to be redirected to the AccessDenied page:<\/p>\n
\"Access<\/a><\/p>\n
So, this works as we expect it to do.<\/p>\n
We want to mention one more thing. If you create this action in a controller with a different name, you have to add additional mapping in the AddCookie<\/code> method in the Client application:<\/p>\n
.AddCookie(\"Cookies\", (opt) => \r\n{\r\n    opt.AccessDeniedPath = \"\/ControllerName\/AccessDenied\";\r\n})\r\n<\/pre>\n
With this configuration, we are adding a different address for the AccessDenied action.<\/p>\n
Conclusion<\/h2>\n
Let\u2019s sum up everything.<\/p>\n
We have learned:<\/p>\n