Angular SPA基於Ocelot API網關與IdentityServer4的身份認證與授權（四）

本文轉載自查看原文 2020-05-24 16:54 1087 微服務/ Ocelot/ IdentityServer4/ Angular/ .NET Core

在上一講中，我們已經完成了一個完整的案例，在這個案例中，我們可以通過Angular單頁面應用（SPA）進行登錄，然后通過后端的Ocelot API網關整合IdentityServer4完成身份認證。在本講中，我們會討論在當前這種架構的應用程序中，如何完成用戶授權。

回顧

用戶授權簡介

在繼續分析我們的應用程序之前，我們簡單回顧一下用戶授權。在用戶登錄的過程中，系統首先確定當前試圖登錄的用戶是否為合法用戶，也就是該用戶是否被允許訪問應用程序，在這個過程中，登錄流程並不負責檢查用戶對哪些資源具有訪問權限，反正系統中存在用戶的合法記錄，就認證通過。接下來，該用戶賬戶就需要訪問系統中的各個功能模塊，並查看或者修改系統中的業務數據，此時，授權機制就會發揮作用，以便檢查當前登錄用戶是否被允許訪問某些功能模塊或者某些數據，以及該用戶對這些數據是否具有讀寫權限。這種決定用戶是否被允許以某種方式訪問系統中的某些資源的機制，稱為授權。

最常見的授權可以基於用戶組，也可以基於用戶角色，還可以組合用戶組與角色，實現基於角色的授權（Role Based Access Control，RBAC）。比如：某個“用戶”屬於“管理員組”，而“管理員組”的所有“用戶”都具有“管理員角色”，對於“管理員角色”，系統允許它可以管理和組織系統中的業務數據，但不能對用戶賬戶進行管理，系統希望只有超級管理員才可以管理用戶賬戶。於是，當某個用戶賬戶被添加到“管理員組”之后，該用戶賬戶就自動被賦予了“管理員角色”，它可以管理系統中的業務數據，但仍然無法對系統中的用戶賬戶進行管理，因為那是“超級管理員”的事情。

從應用程序的架構角度來看，不難得出這樣的結論：用戶認證可以通過第三方的框架或者解決方案來完成，但用戶授權一般都是在應用程序內部完成的，因為它的業務性很強。不同系統可以有不同的授權方式，但認證方式還是相對統一的，比如讓用戶提供用戶名密碼，或者通過第三方身份供應商（Identity Provider，IdP）完成單點登錄等等。縱觀當下流行的認證服務供應商（例如Auth0），它們在認證這部分的功能非常強大，但僅提供一些相對簡單基礎的授權服務，幫助應用程序完成一些簡單的授權需求，雖然應用程序也可以依賴第三方服務供應商來統一完成認證與授權，但這並不是一個很好的架構實踐，因為對第三方服務的依賴性太強。

回顧我們的案例，至今為止，我們僅僅完成了用戶認證的部分，接下來，一起看看在Ocelot API網關中如何做用戶授權。

用戶授權的實現

在系統架構中引入API網關之后，實現用戶授權可以有以下兩種方式：

在API網關處完成用戶授權。這種方式不需要后台的服務各自實現自己的授權體系，用戶授權由API網關代為完成，如果授權失敗，API網關會直接返回授權失敗，不會將客戶端請求進一步轉發給后端的服務。優點是可以實現統一的授權機制，並且減少后端服務的處理壓力，后端服務無需關注和處理授權相關的邏輯；缺點是API網關本身需要知道系統的用戶授權策略
API網關將用戶賬戶信息傳遞給后端服務，由服務各自實現授權。這種做法優點是API網關無需關心由應用程序業務所驅動的授權機制，缺點是每個服務要各自管理自己的授權邏輯

后端服務授權

先來看看第二種方式，也就是API網關將用戶賬戶信息傳遞給后端服務，由后端服務完成授權。在前文中，我們可以看到，Access Token中已經包含了如下四個User Claims：

nameidentifier
name
emailaddress
role

Ocelot允許將Token中所包含的Claims通過HTTP Header的形式傳遞到后端服務上去，做法非常簡單，只需要修改Ocelot的配置文件即可，例如：

{
  "ReRoutes": [
    {
      "DownstreamPathTemplate": "/weatherforecast",
      "DownstreamScheme": "http",
      "DownstreamHostAndPorts": [
        {
          "Host": "localhost",
          "Port": 5000
        }
      ],
      "UpstreamPathTemplate": "/api/weather",
      "UpstreamHttpMethod": [ "Get" ],
      "AuthenticationOptions": {
        "AuthenticationProviderKey": "AuthKey",
        "AllowedScopes": []
      },
      "AddHeadersToRequest": {
        "X-CLAIMS-NAME-IDENTIFIER": "Claims[http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier] > value > |",
        "X-CLAIMS-NAME": "Claims[http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name] > value > |",
        "X-CLAIMS-EMAIL": "Claims[http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress] > value > |",
        "X-CLAIMS-ROLE": "Claims[http://schemas.microsoft.com/ws/2008/06/identity/claims/role] > value > |"
      }
    }
  ]
}

然后重新運行服務，並在后端服務的API Controller中設置斷點，可以看到，這四個Claims的數據都可以通過Request.Headers得到：

有了這個信息，服務端就可以得知目前是哪個用戶賬戶在請求API調用，並且它是屬於哪個角色，剩下的工作就是基於這個角色信息來決定是否允許當前用戶訪問當前的API。很顯然，這里需要一種合理的設計，而且至少需要滿足以下兩個需求：

授權機制的實現應該能夠被后端多個服務所重用，以便解決“每個服務要各自管理自己的授權邏輯”這一弊端
API控制器不應該自己實現授權部分的代碼，可以通過擴展中間件並結合C# Attribute的方式完成

在這里我們就不深入討論如何去設計這樣一套權限認證系統了，今后有機會再介紹吧。

注：Ocelot可以支持多種Claims的轉換形式，這里介紹的AddHeadersToRequest只是其中的一種，更多方式可以參考：https://ocelot.readthedocs.io/en/latest/features/claimstransformation.html

Ocelot API網關授權

通過Ocelot網關授權，有兩種比較常用的方式，一種是在配置文件中，針對不同的downstream配置，設置其RouteClaimsRequirement配置，以便指定哪些用戶角色能夠被允許訪問所請求的API資源。比如：

{
  "ReRoutes": [
    {
      "DownstreamPathTemplate": "/weatherforecast",
      "DownstreamScheme": "http",
      "DownstreamHostAndPorts": [
        {
          "Host": "localhost",
          "Port": 5000
        }
      ],
      "UpstreamPathTemplate": "/api/weather",
      "UpstreamHttpMethod": [ "Get" ],
      "AuthenticationOptions": {
        "AuthenticationProviderKey": "AuthKey",
        "AllowedScopes": []
      },
      "RouteClaimsRequirement": {
        "Role": "admin"
      }
    }
  ]
}

上面高亮部分的代碼指定了只有admin角色的用戶才能訪問/weatherforecast API，這里的“Role”就是Claim的名稱，而“admin”就是Claim的值。如果我們在此處將Role設置為superadmin，那么前端頁面就無法正常訪問API，而是獲得403 Forbidden的狀態碼：

注意：理論上講，此處的“Role”原本應該是使用標准的Role Claim的名稱，即原本應該是：

但由於ASP.NET Core框架在處理JSON配置文件時存在特殊性，使得上述標准的Role Claim的名稱無法被正確解析，因此，也就無法在RouteClaimsRequirement中正常使用。目前的解決方案就是用戶認證后，在Access Token中帶入一個自定義的Role Claim（在這里我使用最簡單的名字“Role”作為這個自定義的Claim的名稱，這也是為什么上面的JSON配置例子中，使用的是“Role”，而不是“http://schemas.microsoft.com/ws/2008/06/identity/claims/role”），而要做到這一點，就要修改兩個地方。

首先，在IdentityService的Config.cs文件中，增加一個自定義的User Claim：

public static IEnumerable<ApiResource> GetApiResources() =>
    new[]
    {
        new ApiResource("api.weather", "Weather API")
        {
            Scopes =
            {
                new Scope("api.weather.full_access", "Full access to Weather API")
            },
            UserClaims =
            {
                ClaimTypes.NameIdentifier,
                ClaimTypes.Name,
                ClaimTypes.Email,
                ClaimTypes.Role,
                "Role"
            }
        }
    };

然后，在注冊新用戶的API中，當用戶注冊信息包含Role時，將“Role” Claim也添加到數據庫中：

[HttpPost]
[Route("api/[controller]/register-account")]
public async Task<IActionResult> RegisterAccount([FromBody] RegisterUserRequestViewModel model)
{
    if (!ModelState.IsValid)
    {
        return BadRequest(ModelState);
    }

    var user = new AppUser { UserName = model.UserName, DisplayName = model.DisplayName, Email = model.Email };


    var result = await _userManager.CreateAsync(user, model.Password);

    if (!result.Succeeded) return BadRequest(result.Errors);

    await _userManager.AddClaimAsync(user, new Claim(ClaimTypes.NameIdentifier, user.UserName));
    await _userManager.AddClaimAsync(user, new Claim(ClaimTypes.Name, user.DisplayName));
    await _userManager.AddClaimAsync(user, new Claim(ClaimTypes.Email, user.Email));

    if (model.RoleNames?.Count > 0)
    {
        var validRoleNames = new List<string>();
        foreach (var roleName in model.RoleNames)
        {
            var trimmedRoleName = roleName.Trim();
            if (await _roleManager.RoleExistsAsync(trimmedRoleName))
            {
                validRoleNames.Add(trimmedRoleName);
                await _userManager.AddToRoleAsync(user, trimmedRoleName);
            }
        }

        await _userManager.AddClaimAsync(user, new Claim(ClaimTypes.Role, string.Join(',', validRoleNames)));
        await _userManager.AddClaimAsync(user, new Claim("Role", string.Join(',', validRoleNames)));
    }

    return Ok(new RegisterUserResponseViewModel(user));
}

修改完后，重新通過調用這個register-account API來新建一個用戶來進行測試，一切正常的話，就可以通過Ocelot API網關中的RouteClaimsRequirement來完成授權了。

通過Ocelot網關授權的另一種做法是使用代碼實現。通過代碼方式，可以實現更為復雜的授權策略，我們仍然以“角色”作為授權參照，我們可以首先定義所需的授權策略：

public void ConfigureServices(IServiceCollection services)
{
    services.AddOcelot();
    services.AddAuthentication()
        .AddIdentityServerAuthentication("AuthKey", options =>
        {
            options.Authority = "http://localhost:7889";
            options.RequireHttpsMetadata = false;
        });

    services.AddAuthorization(options =>
    {
        options.AddPolicy("admin", builder => builder.RequireRole("admin"));
        options.AddPolicy("superadmin", builder => builder.RequireRole("superadmin"));
    });

    services.AddCors(options => options.AddPolicy("AllowAll", p => p.AllowAnyOrigin()
       .AllowAnyMethod()
       .AllowAnyHeader()));
}

然后使用Ocelot的AuthorisationMiddleware中間件，來定義我們的授權處理邏輯：

app.UseOcelot((b, c) =>
{
    c.AuthorisationMiddleware = async (ctx, next) =>
    {
        if (ctx.DownstreamReRoute.DownstreamPathTemplate.Value == "/weatherforecast")
        {
            var authorizationService = ctx.HttpContext.RequestServices.GetService<IAuthorizationService>();
            var result = await authorizationService.AuthorizeAsync(ctx.HttpContext.User, "superadmin");
            if (result.Succeeded)
            {
                await next.Invoke();
            }
            else
            {
                ctx.Errors.Add(new UnauthorisedError($"Fail to authorize policy: admin"));
            }
        }
        else
        {
            await next.Invoke();
        }
    };

    b.BuildCustomOcelotPipeline(c).Build();
    
}).Wait();

當然，上面的BuildCustomOcelotPipeline方法的目的就是將一些默認的Ocelot中間件加入到管道中，否則整個Ocelot框架是不起作用的。我將這個方法定義為一個擴展方法，代碼如下：

public static class Extensions
{
    private static void UseIfNotNull(this IOcelotPipelineBuilder builder,
        Func<DownstreamContext, Func<Task>, Task> middleware)
    {
        if (middleware != null)
        {
            builder.Use(middleware);
        }
    }

    public static IOcelotPipelineBuilder BuildCustomOcelotPipeline(this IOcelotPipelineBuilder builder,
        OcelotPipelineConfiguration pipelineConfiguration)
    {
        builder.UseExceptionHandlerMiddleware();
        builder.MapWhen(context => context.HttpContext.WebSockets.IsWebSocketRequest,
            app =>
            {
                app.UseDownstreamRouteFinderMiddleware();
                app.UseDownstreamRequestInitialiser();
                app.UseLoadBalancingMiddleware();
                app.UseDownstreamUrlCreatorMiddleware();
                app.UseWebSocketsProxyMiddleware();
            });
        builder.UseIfNotNull(pipelineConfiguration.PreErrorResponderMiddleware);
        builder.UseResponderMiddleware();
        builder.UseDownstreamRouteFinderMiddleware();
        builder.UseSecurityMiddleware();
        if (pipelineConfiguration.MapWhenOcelotPipeline != null)
        {
            foreach (var pipeline in pipelineConfiguration.MapWhenOcelotPipeline)
            {
                builder.MapWhen(pipeline);
            }
        }
        builder.UseHttpHeadersTransformationMiddleware();
        builder.UseDownstreamRequestInitialiser();
        builder.UseRateLimiting();

        builder.UseRequestIdMiddleware();
        builder.UseIfNotNull(pipelineConfiguration.PreAuthenticationMiddleware);
        if (pipelineConfiguration.AuthenticationMiddleware == null)
        {
            builder.UseAuthenticationMiddleware();
        }
        else
        {
            builder.Use(pipelineConfiguration.AuthenticationMiddleware);
        }
        builder.UseClaimsToClaimsMiddleware();
        builder.UseIfNotNull(pipelineConfiguration.PreAuthorisationMiddleware);
        if (pipelineConfiguration.AuthorisationMiddleware == null)
        {
            builder.UseAuthorisationMiddleware();
        }
        else
        {
            builder.Use(pipelineConfiguration.AuthorisationMiddleware);
        }
        builder.UseClaimsToHeadersMiddleware();
        builder.UseIfNotNull(pipelineConfiguration.PreQueryStringBuilderMiddleware);
        builder.UseClaimsToQueryStringMiddleware();
        builder.UseLoadBalancingMiddleware();
        builder.UseDownstreamUrlCreatorMiddleware();
        builder.UseOutputCacheMiddleware();
        builder.UseHttpRequesterMiddleware();

        return builder;
    }
}

與上文所提交的“后端服務授權”類似，我們需要在Ocelot API網關上定義並實現授權策略，有可能是需要設計一些框架來簡化用戶數據的訪問並提供靈活的、可復用的授權邏輯，由於這部分內容跟每個應用程序的業務關系較為密切，所以本文也就不深入討論了。

總結

至此，有關Angular SPA基於Ocelot API網關與IdentityServer4的身份認證與授權的介紹，就告一段落了。通過四篇文章，我們從零開始，一步步搭建微服務、基於IdentityServer4的IdentityService、Ocelot API網關以及Angular單頁面應用，並逐步介紹了認證與授權的實現過程。雖然沒有最終實現一個可被重用的授權框架，但基本架構也算是完整了，今后有機會我可以再補充認證、授權的相關內容，歡迎閱讀並提寶貴意見。

源代碼

訪問以下Github地址以獲取源代碼：

https://github.com/daxnet/identity-demo

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 Angular SPA基於Ocelot API網關與IdentityServer4的身份認證與授權（一） Angular SPA基於Ocelot API網關與IdentityServer4的身份認證與授權（三） Ocelot網關+IdentityServer4實現API權限認證授權認證（IdentityServer4) IdentityServer4授權和認證 .net core 微服務架構-docker的部署-包括網關服務(Ocelot)+認證服務(IdentityServer4)+應用服務（asp.net core web api）認證授權：IdentityServer4 - 各種授權模式應用 Ocelot簡易教程（五）之集成IdentityServer認證以及授權 IdentityServer4身份認證授權入門-----客戶端憑據、密碼模式認證授權：IdentityServer4 - 單點登錄