認證鑑權與API許可權控制在微服務架構中的設計與實現（四）

引言：本文系《認證鑑權與API許可權控制在微服務架構中的設計與實現》系列的完結篇，前面三篇已經將認證鑑權與API許可權控制的流程和主要細節講解完。本文比較長，對這個系列進行收尾，主要內容包括對授權和鑑權流程之外的endpoint以及Spring Security過濾器部分踩坑的經歷。歡迎閱讀本系列文章。

1. 前文回顧

首先還是照例對前文進行回顧。在第一篇認證鑑權與API許可權控制在微服務架構中的設計與實現（一）介紹了該專案的背景以及技術調研與最後選型。第二篇認證鑑權與API許可權控制在微服務架構中的設計與實現（二）畫出了簡要的登入和校驗的流程圖，並重點講解了使用者身份的認證與token發放的具體實現。第三篇認證鑑權與API許可權控制在微服務架構中的設計與實現（三）先介紹了資源伺服器配置，以及其中涉及的配置類，後面重點講解了token以及API級別的鑑權。

本文將會講解剩餘的兩個內建端點：登出和重新整理token。登出token端點的處理與Spring Security預設提供的有些'/logout'有些區別，不僅清空SpringSecurityContextHolder中的資訊，還要增加對儲存token的清空。另一個重新整理token端點其實和之前的請求授權是一樣的API，只是引數中的grant_type不一樣。

除了以上兩個內建端點，後面將會重點講下幾種Spring Security過濾器。API級別的操作許可權校驗本來設想是通過Spring Security的過濾器實現，特地把這邊學習了一遍，踩了一遍坑。

最後是本系列的總結，並對於存在的不足和後續工作進行論述。

2. 其他端點

2.1 登出端點

在第一篇中提到了Auth系統內建的登出端點 /logout，如果還記得第三篇資源伺服器的配置，下面的關於/logout配置一定不陌生。

            //...
                .and().logout()
                .logoutUrl("/logout")
                .clearAuthentication(true)
                .logoutSuccessHandler(new HttpStatusReturningLogoutSuccessHandler())
                .addLogoutHandler(customLogoutHandler());複製程式碼

上面配置的主要作用是：

設定登出的URL
清空Authentication資訊
設定登出成功的處理方式
設定自定義的登出處理方式

當然在LogoutConfigurer中還有更多的設定選項，筆者此處列出專案所需要的配置項。這些配置項圍繞著LogoutFilter過濾器。順帶講一下Spring Security的過濾器。其使用了springSecurityFillterChian作為了安全過濾的入口，各種過濾器按順序具體如下：

SecurityContextPersistenceFilter：與SecurityContext安全上下文資訊有關
HeaderWriterFilter：給http響應新增一些Header
CsrfFilter：防止csrf攻擊，預設開啟
LogoutFilter：處理登出的過濾器
UsernamePasswordAuthenticationFilter：表單認證過濾器
RequestCacheAwareFilter：快取request請求
SecurityContextHolderAwareRequestFilter：此過濾器對ServletRequest進行了一次包裝，使得request具有更加豐富的API
AnonymousAuthenticationFilter：匿名身份過濾器
SessionManagementFilter：session相關的過濾器，常用來防止session-fixation protection attack，以及限制同一使用者開啟多個會話的數量
ExceptionTranslationFilter：異常處理過濾器
FilterSecurityInterceptor：web應用安全的關鍵Filter

各種過濾器簡單標註了作用，在下一節重點講其中的幾個過濾器。登出過濾器排在靠前的位置，我們一起看下LogoutFilter的UML類圖。

類圖和我們之前配置時的思路是一致的，HttpSecurity建立了LogoutConfigurer，我們在這邊配置了LogoutConfigurer的一些屬性。同時LogoutConfigurer根據這些屬性建立了LogoutFilter。

LogoutConfigurer的配置，第一和第二點就不用再詳細解釋了，一個是設定端點，另一個是清空認證資訊。
對於第三點，配置登出成功的處理方式。由於專案是前後端分離，客戶端只需要知道執行成功該API介面的狀態，並不用返回具體的頁面或者繼續向下傳遞請求。因此，這邊配置了預設的HttpStatusReturningLogoutSuccessHandler，成功直接返回狀態碼200。
對於第四點配置，自定義登出處理的方法。這邊需要藉助TokenStore，對token進行操作。TokenStore在之前文章的配置中已經講過，使用的是JdbcTokenStore。首先校驗請求的合法性，如果合法則對其進行操作，先後移除refreshToken和existingAccessToken。

public class CustomLogoutHandler implements LogoutHandler {

    //...

    @Override
    public void logout(HttpServletRequest request, HttpServletResponse response, Authentication authentication) {
        //確定注入了tokenStore
        Assert.notNull(tokenStore, "tokenStore must be set");
       //獲取頭部的認證資訊
        String token = request.getHeader("Authorization");
        Assert.hasText(token, "token must be set");
        //校驗token是否符合JwtBearer格式
        if (isJwtBearerToken(token)) {
            token = token.substring(6);
            OAuth2AccessToken existingAccessToken = tokenStore.readAccessToken(token);
            OAuth2RefreshToken refreshToken;
            if (existingAccessToken != null) {
                if (existingAccessToken.getRefreshToken() != null) {
                    LOGGER.info("remove refreshToken!", existingAccessToken.getRefreshToken());
                    refreshToken = existingAccessToken.getRefreshToken();
                    tokenStore.removeRefreshToken(refreshToken);
                }
                LOGGER.info("remove existingAccessToken!", existingAccessToken);
                tokenStore.removeAccessToken(existingAccessToken);
            }
            return;
        } else {
            throw new BadClientCredentialsException();
        }

    }

    //...
}複製程式碼

執行如下請求：

method: get
url: http://localhost:9000/logout
header:
{
    Authorization: Basic ZnJvbnRlbmQ6ZnJvbnRlbmQ=
}複製程式碼

登出成功則會返回200，將token和SecurityContextHolder進行清空。

2.2 重新整理端點

在第一篇就已經講過，由於token的時效一般不會很長，而refresh token一般週期會很長，為了不影響使用者的體驗，可以使用refresh token去動態的重新整理token。重新整理token主要與RefreshTokenGranter有關，CompositeTokenGranter管理一個List列表，每一種grantType對應一個具體的真正授權者，refresh_ token對應的granter就是RefreshTokenGranter，而granter內部則是通過grantType來區分是否是各自的授權型別。執行如下請求：

method: post 
url: http://localhost:12000/oauth/token?grant_type=refresh_token&refresh_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJYLUtFRVRTLVVzZXJJZCI6ImQ2NDQ4YzI0LTNjNGMtNGI4MC04MzcyLWMyZDYxODY4ZjhjNiIsInVzZXJfbmFtZSI6ImtlZXRzIiwic2NvcGUiOlsiYWxsIl0sImF0aSI6ImJhZDcyYjE5LWQ5ZjMtNDkwMi1hZmZhLTA0MzBlN2RiNzllZCIsImV4cCI6MTUxMDk5NjU1NiwianRpIjoiYWE0MWY1MjctODE3YS00N2UyLWFhOTgtZjNlMDZmNmY0NTZlIiwiY2xpZW50X2lkIjoiZnJvbnRlbmQifQ.mICT1-lxOAqOU9M-Ud7wZBb4tTux6OQWouQJ2nn1DeE
header:
{
    Authorization: Basic ZnJvbnRlbmQ6ZnJvbnRlbmQ=
}複製程式碼

在refresh_ token正確的情況下，其返回的response和/oauth/token得到正常的響應是一樣的。具體的程式碼可以參閱第二篇的講解。

3. `Spring Security`過濾器

在上一節我們介紹了內建的兩個端點的實現細節，還提到了HttpSecurity過濾器，因為登出端點的實現就是通過過濾器的作用。核心的過濾器主要有：

FilterSecurityInterceptor
UsernamePasswordAuthenticationFilter
SecurityContextPersistenceFilter
ExceptionTranslationFilter

這一節將重點介紹其中的UsernamePasswordAuthenticationFilter和FilterSecurityInterceptor。

3.1 `UsernamePasswordAuthenticationFilter`

筆者在剛開始看關於過濾器的文章，對於UsernamePasswordAuthenticationFilter有不少的文章介紹。如果只是引入Spring-Security，必然會與/login端點熟悉。SpringSecurity強制要求我們的表單登入頁面必須是以POST方式向/login URL提交請求，而且要求使用者名稱和密碼的引數名必須是username和password。如果不符合，則不能正常工作。原因在於，當我們呼叫了HttpSecurity物件的formLogin方法時，其最終會給我們註冊一個過濾器UsernamePasswordAuthenticationFilter。看一下該過濾器的原始碼。

public class UsernamePasswordAuthenticationFilter extends
        AbstractAuthenticationProcessingFilter {
    //使用者名稱、密碼
    public static final String SPRING_SECURITY_FORM_USERNAME_KEY = "username";
    public static final String SPRING_SECURITY_FORM_PASSWORD_KEY = "password";

    private String usernameParameter = SPRING_SECURITY_FORM_USERNAME_KEY;
    private String passwordParameter = SPRING_SECURITY_FORM_PASSWORD_KEY;
    private boolean postOnly = true;

    //post請求/login
    public UsernamePasswordAuthenticationFilter() {
        super(new AntPathRequestMatcher("/login", "POST"));
    }
    //實現抽象類AbstractAuthenticationProcessingFilter的抽象方法，嘗試驗證
    public Authentication attemptAuthentication(HttpServletRequest request,
            HttpServletResponse response) throws AuthenticationException {
        if (postOnly && !request.getMethod().equals("POST")) {
            throw new AuthenticationServiceException(
                    "Authentication method not supported: " + request.getMethod());
        }

        String username = obtainUsername(request);
        String password = obtainPassword(request);

        //···

        username = username.trim();

        UsernamePasswordAuthenticationToken authRequest = new UsernamePasswordAuthenticationToken(
                username, password);
        //···
        return this.getAuthenticationManager().authenticate(authRequest);
    }
}複製程式碼

public abstract class AbstractAuthenticationProcessingFilter extends GenericFilterBean
        implements ApplicationEventPublisherAware, MessageSourceAware {
    //...

    //呼叫requiresAuthentication，判斷請求是否需要authentication，如果需要則呼叫attemptAuthentication
    //有三種結果可能返回：
    //1.Authentication物件
    //2. AuthenticationException
    //3. Authentication物件為空
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
            throws IOException, ServletException {

        HttpServletRequest request = (HttpServletRequest) req;
        HttpServletResponse response = (HttpServletResponse) res;
        //不需要校驗，繼續傳遞
        if (!requiresAuthentication(request, response)) {
            chain.doFilter(request, response);
            return;
        }
        Authentication authResult;

        try {
            authResult = attemptAuthentication(request, response);
            if (authResult == null) {
                // return immediately as subclass has indicated that it hasn't completed authentication
                return;
            }
            sessionStrategy.onAuthentication(authResult, request, response);
        }
        //...
        catch (AuthenticationException failed) {
            // Authentication failed
            unsuccessfulAuthentication(request, response, failed);

            return;
        }

        // Authentication success
        if (continueChainBeforeSuccessfulAuthentication) {
            chain.doFilter(request, response);
        }

        successfulAuthentication(request, response, chain, authResult);
    }

    //實際執行的authentication，繼承類必須實現該抽象方法
    public abstract Authentication attemptAuthentication(HttpServletRequest request,
            HttpServletResponse response) throws AuthenticationException, IOException,
            ServletException;
    //成功authentication的預設行為
    protected void successfulAuthentication(HttpServletRequest request,
            HttpServletResponse response, FilterChain chain, Authentication authResult)
            throws IOException, ServletException {

        //...
    }
    //失敗authentication的預設行為
    protected void unsuccessfulAuthentication(HttpServletRequest request,
            HttpServletResponse response, AuthenticationException failed)
            throws IOException, ServletException {
    //...            
    }

    ...
    //設定AuthenticationManager
    public void setAuthenticationManager(AuthenticationManager authenticationManager) {
        this.authenticationManager = authenticationManager;
    }
    ...
}複製程式碼

UsernamePasswordAuthenticationFilter因為繼承了AbstractAuthenticationProcessingFilter才擁有過濾器的功能。AbstractAuthenticationProcessingFilter要求設定一個authenticationManager，authenticationManager的實現類將實際處理請求的認證。AbstractAuthenticationProcessingFilter將攔截符合過濾規則的request，並試圖執行認證。子類必須實現 attemptAuthentication 方法，這個方法執行具體的認證。
認證之後的處理和上登出的差不多。如果認證成功，將會把返回的Authentication物件存放在SecurityContext，並呼叫SuccessHandler，也可以設定指定的URL和指定自定義的處SuccessHandler。如果認證失敗，預設會返回401程式碼給客戶端，也可以設定URL，指定自定義的處理FailureHandler。

基於UsernamePasswordAuthenticationFilter自定義的AuthenticationFilte還是挺多案例的，這邊推薦一篇博文Spring Security(五)--動手實現一個IP_Login，寫得比較詳細。

3.2 `FilterSecurityInterceptor`

FilterSecurityInterceptor是filterchain中比較複雜，也是比較核心的過濾器，主要負責web應用安全授權的工作。首先看下對於自定義的FilterSecurityInterceptor配置。

    @Override
    public void configure(HttpSecurity http) throws Exception {

        ...
        //新增CustomSecurityFilter，過濾器的順序放在FilterSecurityInterceptor
        http.antMatcher("/oauth/check_token").addFilterAt(customSecurityFilter(), FilterSecurityInterceptor.class);

    }
    //提供例項化的自定義過濾器
    @Bean
    public CustomSecurityFilter customSecurityFilter() {
        return new CustomSecurityFilter();
    }複製程式碼

從上述配置可以看到，在FilterSecurityInterceptor的位置註冊了CustomSecurityFilter，對於匹配到/oauth/check_token，則會呼叫該進入該過濾器。下圖為FilterSecurityInterceptor的類圖，在其中還新增了CustomSecurityFilter和相關實現的介面的類，方便讀者對比著看。

CustomSecurityFilter是模仿FilterSecurityInterceptor實現，繼承AbstractSecurityInterceptor和實現Filter介面。整個過程需要依賴AuthenticationManager、AccessDecisionManager和FilterInvocationSecurityMetadataSource。
AuthenticationManager是認證管理器，實現使用者認證的入口；AccessDecisionManager是訪問決策器，決定某個使用者具有的角色，是否有足夠的許可權去訪問某個資源；FilterInvocationSecurityMetadataSource是資源源資料定義，即定義某一資源可以被哪些角色訪問。
從上面的類圖中可以看到自定義的CustomSecurityFilter同時又實現了
AccessDecisionManager和FilterInvocationSecurityMetadataSource。分別為SecureResourceFilterInvocationDefinitionSource和SecurityAccessDecisionManager。下面分析下主要的配置。

//通過一個實現的filter，對HTTP資源進行安全處理
public class FilterSecurityInterceptor extends AbstractSecurityInterceptor implements Filter {
    //被filter chain真實呼叫的方法，通過invoke代理
    public void doFilter(ServletRequest request, ServletResponse response,
            FilterChain chain) throws IOException, ServletException {
        FilterInvocation fi = new FilterInvocation(request, response, chain);
        invoke(fi);
    }
    //代理的方法
    public void invoke(FilterInvocation fi) throws IOException, ServletException     {
        //...省略
    }
}複製程式碼

上述程式碼是FilterSecurityInterceptor中的實現，具體實現細節就沒列出了，我們這邊重點在於對自定義的實現進行講解。

public class CustomSecurityFilter extends AbstractSecurityInterceptor implements Filter {

    @Autowired
    SecureResourceFilterInvocationDefinitionSource invocationSource;

    @Autowired
    private AuthenticationManager authenticationManager;

    @Autowired
    private SecurityAccessDecisionManager decisionManager;

    //設定父類中的屬性
    @PostConstruct
    public void init() {
        super.setAccessDecisionManager(decisionManager);
        super.setAuthenticationManager(authenticationManager);
    }
    //主要的過濾方法，與原來的一致
    @Override
    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
        //logger.info("doFilter in Security ");
        //構造一個FilterInvocation，封裝request, response, chain
        FilterInvocation fi = new FilterInvocation(servletRequest, servletResponse, filterChain);
        //beforeInvocation會呼叫SecureResourceDataSource中的邏輯，類似於aop中的before 
        InterceptorStatusToken token = super.beforeInvocation(fi);
        try {
            //執行下一個攔截器
            fi.getChain().doFilter(fi.getRequest(), fi.getResponse());            
        } finally {
            //完成後續工作，類似於aop中的after 
            super.afterInvocation(token, null);
        }
    }

    //...

    //資源源資料定義，設定為自定義的SecureResourceFilterInvocationDefinitionSource
    @Override
    public SecurityMetadataSource obtainSecurityMetadataSource() {
        return invocationSource;
    }
}複製程式碼

上面自定義的CustomSecurityFilter，與我們之前的講解是一樣的流程。主要依賴的三個介面都有在實現中例項化注入。看下父類的beforeInvocation方法，其中省略了一些不重要的程式碼片段。

protected InterceptorStatusToken beforeInvocation(Object object) {  
    //根據SecurityMetadataSource獲取配置的許可權屬性  
    Collection<ConfigAttribute> attributes = this.obtainSecurityMetadataSource().getAttributes(object);  
    //...  
    //判斷是否需要對認證實體重新認證，預設為否  
    Authentication authenticated = authenticateIfRequired();  

    // Attempt authorization  
    try {  
        //決策管理器開始決定是否授權，如果授權失敗，直接丟擲AccessDeniedException  
        this.accessDecisionManager.decide(authenticated, object, attributes);  
    }  
    catch (AccessDeniedException accessDeniedException) {  
        publishEvent(new AuthorizationFailureEvent(object, attributes, authenticated,  
                accessDeniedException));  

        throw accessDeniedException;  
    }  
}複製程式碼

上面程式碼可以看出，第一步是根據SecurityMetadataSource獲取配置的許可權屬性，accessDecisionManager會用到許可權列表資訊。然後判斷是否需要對認證實體重新認證，預設為否。第二步是接著決策管理器開始決定是否授權，如果授權失敗，直接丟擲AccessDeniedException。

(1). 獲取配置的許可權屬性

public class SecureResourceFilterInvocationDefinitionSource implements FilterInvocationSecurityMetadataSource, InitializingBean {
    private PathMatcher matcher;
    //map儲存配置的URL對應的許可權集
    private static Map<String, Collection<ConfigAttribute>> map = new HashMap<>();

    //根據傳入的物件URL進行迴圈
    @Override
    public Collection<ConfigAttribute> getAttributes(Object o) throws IllegalArgumentException {
        logger.info("getAttributes");
        //應該做instanceof
        FilterInvocation filterInvocation = (FilterInvocation) o;
        //String method = filterInvocation.getHttpRequest().getMethod();
        String requestURI = filterInvocation.getRequestUrl();
        //迴圈資源路徑，當訪問的Url和資源路徑url匹配時，返回該Url所需要的許可權
        for (Iterator<Map.Entry<String, Collection<ConfigAttribute>>> iterator = map.entrySet().iterator(); iter.hasNext(); ) {
            Map.Entry<String, Collection<ConfigAttribute>> entry = iterator.next();
            String url = entry.getKey();

            if (matcher.match(url, requestURI)) {
                return map.get(requestURI);
            }
        }
        return null;
    }

    //... 

    //設定許可權集，即上述的map
    @Override
    public void afterPropertiesSet() throws Exception {
        logger.info("afterPropertiesSet");
        //用來匹配訪問資源路徑
        this.matcher = new AntPathMatcher();
        //可以有多個許可權
        Collection<ConfigAttribute> atts = new ArrayList<>();
        ConfigAttribute c1 = new SecurityConfig("ROLE_ADMIN");
        atts.add(c1);
        map.put("/oauth/check_token", atts);
    }
}複製程式碼

上面是getAttributes()實現的具體細節，將請求的URL取出進行匹配事先設定的受限資源，最後返回需要的許可權、角色。系統在啟動的時候就會讀取到配置的map集合，對於攔截到請求進行匹配。程式碼中註釋比較詳細，這邊不多說。

(2). 決策管理器

public class SecurityAccessDecisionManager implements AccessDecisionManager {
    //...

    @Override
    public void decide(Authentication authentication, Object o, Collection<ConfigAttribute> collection) throws AccessDeniedException, InsufficientAuthenticationException {
        logger.info("decide url and permission");
        //集合為空
        if (collection == null) {
            return;
        }

        Iterator<ConfigAttribute> ite = collection.iterator();
        //判斷使用者所擁有的許可權，是否符合對應的Url許可權，如果實現了UserDetailsService，則使用者許可權是loadUserByUsername返回使用者所對應的許可權
        while (ite.hasNext()) {
            ConfigAttribute ca = ite.next();
            String needRole = ca.getAttribute();
            for (GrantedAuthority ga : authentication.getAuthorities()) {
                logger.info("GrantedAuthority: {}", ga);
                if (needRole.equals(ga.getAuthority())) {
                    return;
                }
            }
        }
        logger.error("AccessDecisionManager: no right!");
        throw new AccessDeniedException("no right!");
    }

    //...
}複製程式碼

上面的程式碼是決策管理器的實現，其邏輯也比較簡單，將請求所具有的許可權與設定的受限資源所需的進行匹配，如果具有則返回，否則丟擲沒有正確的許可權異常。預設提供的決策管理器有三種，分別為AffirmativeBased、ConsensusBased、UnanimousBased，篇幅有限，我們這邊不再擴充套件了。

補充一下，所具有的許可權是通過之前配置的認證方式，有password認證和client認證兩種。我們之前在授權伺服器中配置了withClientDetails，所以用frontend身份驗證獲得的許可權是我們預先配置在資料庫中的authorities。

4. 總結

Auth系統主要功能是授權認證和鑑權。專案微服務化後，原有的單體應用基於HttpSession認證鑑權不能滿足微服務架構下的需求。每個微服務都需要對訪問進行鑑權，每個微應用都需要明確當前訪問使用者以及其許可權，尤其當有多個客戶端，包括web端、移動端等等，單體應用架構下的鑑權方式就不是特別合適了。許可權服務作為基礎的公共服務，也需要微服務化。

筆者的設計中，Auth服務一方面進行授權認證，另一方面是基於token進行身份合法性和API級別的許可權校驗。對於某個服務的請求，經過閘道器會呼叫Auth服務，對token合法性進行驗證。同時筆者根據當前專案的整體情況，存在部分遺留服務，這些遺留服務又沒有足夠的時間和人力立馬進行微服務改造，而且還需要繼續執行。為了適配當前新的架構，採取的方案就是對這些遺留服務的操作API，在Auth服務進行API級別的操作許可權鑑定。API級別的操作許可權校驗需要的上下文資訊需要結合業務，與客戶端進行商定，應該在token能取到相應資訊，傳遞給Auth服務，不過應儘量減少在header取上下文校驗的資訊。

筆者將本次開發Auth系統所涉及的大部分程式碼及原始碼進行了解析，至於沒有講到的一些內容和細節，讀者可以自行擴充套件。

5. 不足與後續工作

5.1 存在的不足

API級別操作許可權校驗的通用性

(1). 對於API級別操作許可權校驗，需要在閘道器處呼叫時構造相應的上下文資訊。上下文資訊基本依賴於 token中的payload，如果資訊太多引起token太長，導致每次客戶端的請求頭部長度變長。

(2). 並不是所有的操作介面都能覆蓋到，這個問題是比較嚴重的，根據上下文集合很可能出現好多介面的許可權沒法鑑定，最後的結果就是API級別操作許可權校驗失敗的是絕對沒有許可權訪問該介面，而通過不一定能訪問，因為該介面涉及到的上下文根本沒法完全得到。我們的專案在現階段，定義的最小上下文集合能勉強覆蓋到，但是對於後面擴增的服務介面真的是不樂觀。

(3). 每個服務的每個介面都在Auth服務註冊其所需要的許可權，太過麻煩，Auth服務需要額外維護這樣的資訊。
閘道器處呼叫Auth服務帶來的系統吞吐量瓶頸

(1). 這個其實很容易理解，Auth服務作為公共的基礎服務，大多數服務介面都會需要鑑權，Auth服務需要經過複雜。

(2). 閘道器呼叫Auth服務，阻塞呼叫，只有等Auth服務返回校驗結果，才會做進一步處理。雖說Auth服務可以多例項部署，但是併發量大了之後，其瓶頸明顯可見，嚴重可能會造成整個系統的不可用。

5.2 後續工作

從整個系統設計角度來講，API級別操作許可權後期將會分散在各個服務的介面上，由各個介面負責其所需要的許可權、身份等。Spring Security對於介面級別的許可權校驗也是支援的，之所以採用這樣的做法，也是為了相容新服務和遺留的服務，主要是針對遺留服務，新的服務採用的是分散在各個介面之上。
將API級別操作許可權分散到各個服務介面之後，相應的能提升Auth服務的響應。閘道器能夠及時的對請求進行轉發或者拒絕。
API級別操作許可權所需要的上下文資訊對各個介面真的設計的很複雜，這邊我們確實花了時間，同時管理移動服務的好幾百操作介面所對應的許可權，非常煩。！

本文的原始碼地址：
GitHub：github.com/keets2012/A…
碼雲： gitee.com/keets/Auth-…

認證鑑權與API許可權控制在微服務架構中的設計與實現（四）

1. 前文回顧

2. 其他端點

2.1 登出端點

2.2 重新整理端點

3. `Spring Security`過濾器

3.1 `UsernamePasswordAuthenticationFilter`

3.2 `FilterSecurityInterceptor`

4. 總結

5. 不足與後續工作

5.1 存在的不足

5.2 後續工作

訂閱最新文章，歡迎關注我的公眾號

參考

相關閱讀

相關文章

認證鑑權與API許可權控制在微服務架構中的設計與實現（四）

1. 前文回顧

2. 其他端點

2.1 登出端點

2.2 重新整理端點

3. Spring Security過濾器

3.1 UsernamePasswordAuthenticationFilter

3.2 FilterSecurityInterceptor

4. 總結

5. 不足與後續工作

5.1 存在的不足

5.2 後續工作

訂閱最新文章，歡迎關注我的公眾號

參考

相關閱讀

相關文章

3. `Spring Security`過濾器

3.1 `UsernamePasswordAuthenticationFilter`

3.2 `FilterSecurityInterceptor`