話說Spring Security權限管理（源碼）

時間 2019-11-12

標籤話說 spring security 權限管理源碼欄目 Spring 简体版

原文原文鏈接

最近項目須要用到Spring Security的權限控制，故花了點時間簡單的去看了一下其權限控制相關的源碼(版本爲4.2)。
java

AccessDecisionManager

spring security是經過AccessDecisionManager進行受權管理的，先來張官方圖鎮樓。spring

AccessDecisionManager

AccessDecisionManager 接口定義了以下方法：app

//調用AccessDecisionVoter進行投票（關鍵方法）
void decide(Authentication authentication, Object object,
        Collection<ConfigAttribute> configAttributes) throws AccessDeniedException,
        InsufficientAuthenticationException;

boolean supports(ConfigAttribute attribute);
boolean supports(Class clazz);

接下來看看它的實現類的具體實現：ide

AffirmativeBased

public void decide(Authentication authentication, Object object,
        Collection<ConfigAttribute> configAttributes) throws AccessDeniedException {
    int deny = 0;

    for (AccessDecisionVoter voter : getDecisionVoters()) {
        //調用AccessDecisionVoter進行vote(咱們姑且稱之爲投票吧)，後面再看vote的源碼。
        int result = voter.vote(authentication, object, configAttributes);

        if (logger.isDebugEnabled()) {
            logger.debug("Voter: " + voter + ", returned: " + result);
        }
        
        switch (result) {
        case AccessDecisionVoter.ACCESS_GRANTED://值爲1
            //只要有voter投票爲ACCESS_GRANTED，則經過
            return;

        case AccessDecisionVoter.ACCESS_DENIED://值爲-1
            deny++;

            break;

        default:
            break;
        }
    }

    if (deny > 0) {
        //若是有兩個及以上AccessDecisionVoter(姑且稱之爲投票者吧)都投ACCESS_DENIED，則直接就不經過了
        throw new AccessDeniedException(messages.getMessage(
                "AbstractAccessDecisionManager.accessDenied", "Access is denied"));
    }

    // To get this far, every AccessDecisionVoter abstained
    checkAllowIfAllAbstainDecisions();
}

源碼中，有個Collection configAttributes 參數，ConfigAttribute是什麼？這個實際上是一個很靈活的東西，不一樣的狀況表明不一樣的語義，好比在使用了角色控制的時候，傳入的則多是ROLE__XXX之類的，以便ROLE_VOTER使用。具體的後面在細說。 ui

經過以上代碼可直接看到AffirmativeBased的策略：this

只要有投經過（ACCESS_GRANTED）票，則直接判爲經過。
若是沒有投經過票且反對（ACCESS_DENIED）票在兩個及其以上的，則直接判爲不經過。

UnanimousBased

public void decide(Authentication authentication, Object object,
        Collection<ConfigAttribute> attributes) throws AccessDeniedException {

    int grant = 0;
    int abstain = 0;

    List<ConfigAttribute> singleAttributeList = new ArrayList<ConfigAttribute>(1);
    singleAttributeList.add(null);

    for (ConfigAttribute attribute : attributes) {
        singleAttributeList.set(0, attribute);

        for (AccessDecisionVoter voter : getDecisionVoters()) {
            //配置的投票者進行投票
            int result = voter.vote(authentication, object, singleAttributeList);

            if (logger.isDebugEnabled()) {
                logger.debug("Voter: " + voter + ", returned: " + result);
            }

            switch (result) {
            case AccessDecisionVoter.ACCESS_GRANTED:
                grant++;

                break;

            case AccessDecisionVoter.ACCESS_DENIED:
                //只要有投票者投反對票就立馬判爲無權訪問
                throw new AccessDeniedException(messages.getMessage(
                        "AbstractAccessDecisionManager.accessDenied",
                        "Access is denied"));

            default:
                abstain++;

                break;
            }
        }
    }

    // To get this far, there were no deny votes
    if (grant > 0) {
        //若是沒反對票且有經過票，那麼就判爲經過
        return;
    }

    // To get this far, every AccessDecisionVoter abstained
    checkAllowIfAllAbstainDecisions();
}

因而可知UnanimousBased的策略：debug

不管多少投票者投了多少經過（ACCESS_GRANTED）票，只要有反對票（ACCESS_DENIED），那都判爲不經過。
若是沒有反對票且有投票者投了經過票，那麼就判爲經過。

ConsensusBased

public void decide(Authentication authentication, Object object,
        Collection<ConfigAttribute> configAttributes) throws AccessDeniedException {
    int grant = 0;
    int deny = 0;
    int abstain = 0;

    for (AccessDecisionVoter voter : getDecisionVoters()) {
        //配置的投票者進行投票
        int result = voter.vote(authentication, object, configAttributes);

        if (logger.isDebugEnabled()) {
            logger.debug("Voter: " + voter + ", returned: " + result);
        }

        switch (result) {
        case AccessDecisionVoter.ACCESS_GRANTED:
            grant++;

            break;

        case AccessDecisionVoter.ACCESS_DENIED:
            deny++;

            break;

        default:
            abstain++;

            break;
        }
    }

    if (grant > deny) {
        //經過的票數大於反對的票數則判爲經過
        return;
    }

    if (deny > grant) {
        //經過的票數小於反對的票數則判爲不經過
        throw new AccessDeniedException(messages.getMessage(
                "AbstractAccessDecisionManager.accessDenied", "Access is denied"));
    }

    if ((grant == deny) && (grant != 0)) {
        //this.allowIfEqualGrantedDeniedDecisions默認爲true
        //經過的票數和反對的票數相等，則可根據配置allowIfEqualGrantedDeniedDecisions進行判斷是否經過
        if (this.allowIfEqualGrantedDeniedDecisions) {
            return;
        }
        else {
            throw new AccessDeniedException(messages.getMessage(
                    "AbstractAccessDecisionManager.accessDenied", "Access is denied"));
        }
    }

    // To get this far, every AccessDecisionVoter abstained
    checkAllowIfAllAbstainDecisions();
}

因而可知，ConsensusBased的策略：code

經過的票數大於反對的票數則判爲經過。
經過的票數小於反對的票數則判爲不經過。
經過的票數和反對的票數相等，則可根據配置allowIfEqualGrantedDeniedDecisions（默認爲true）進行判斷是否經過。

到此，應該明白AffirmativeBased、UnanimousBased、ConsensusBased三者的區別了吧，spring security默認使用的是AffirmativeBased，若是有須要，可配置爲其它兩個，也可本身去實現。orm

投票者

以上AccessDecisionManager的實現類都只是對權限（投票）進行管理（策略的實現），具體投票（vote）的邏輯是經過調用AccessDecisionVoter的子類（投票者）的vote方法實現的。spring security默認註冊了RoleVoter和AuthenticatedVoter兩個投票者。下面來看看其源碼。token

AccessDecisionManager

boolean supports(ConfigAttribute attribute);
boolean supports(Class<?> clazz);
//核心方法，此方法由上面介紹的的AccessDecisionManager調用，子類實現此方法進行投票。
int vote(Authentication authentication, S object,
        Collection<ConfigAttribute> attributes);

RoleVoter

private String rolePrefix = "ROLE_";

//只處理ROLE_開頭的（可經過配置rolePrefix的值進行改變）
public boolean supports(ConfigAttribute attribute) {
    if ((attribute.getAttribute() != null)
            && attribute.getAttribute().startsWith(getRolePrefix())) {
        return true;
    }
    else {
        return false;
    }
}

public int vote(Authentication authentication, Object object,
        Collection<ConfigAttribute> attributes) {
        
    if(authentication == null) {
        //用戶沒經過認證，則投反對票
        return ACCESS_DENIED;
    }
    int result = ACCESS_ABSTAIN;
    //獲取用戶實際的權限
    Collection<? extends GrantedAuthority> authorities = extractAuthorities(authentication);

    for (ConfigAttribute attribute : attributes) {
        if (this.supports(attribute)) {
            result = ACCESS_DENIED;

            // Attempt to find a matching granted authority
            for (GrantedAuthority authority : authorities) {
                if (attribute.getAttribute().equals(authority.getAuthority())) {
                    //權限匹配則投經過票
                    return ACCESS_GRANTED;
                }
            }
        }
    }
    //若是處理過，但沒投經過票，則爲反對票，若是沒處理過，那麼視爲棄權（ACCESS_ABSTAIN）。
    return result;
}

很簡單吧，同時，咱們還能夠經過實現AccessDecisionManager來擴展本身的voter。可是，要實現這個，咱們還必須得弄清楚attributes這個參數是從哪兒來的，這個是個很關鍵的參數啊。經過一張官方圖能很清晰的看出這個問題來：

接下來，就看看AccessDecisionManager的調用者AbstractSecurityInterceptor。

AbstractSecurityInterceptor

...
//上面說過默認是AffirmativeBased，可配置
private AccessDecisionManager accessDecisionManager;
...
protected InterceptorStatusToken beforeInvocation(Object object) {
    ...
    //抽象方法，子類實現，但由此也可看出ConfigAttribute是由SecurityMetadataSource（實際上，默認是DefaultFilterInvocationSecurityMetadataSource）獲取。
    Collection<ConfigAttribute> attributes = this.obtainSecurityMetadataSource()
            .getAttributes(object);
    ...
    //獲取當前認證過的用戶信息
    Authentication authenticated = authenticateIfRequired();

    try {
        //調用AccessDecisionManager
        this.accessDecisionManager.decide(authenticated, object, attributes);
    }
    catch (AccessDeniedException accessDeniedException) {
        publishEvent(new AuthorizationFailureEvent(object, attributes, authenticated,
                accessDeniedException));

        throw accessDeniedException;
    }
    ...     
}

public abstract SecurityMetadataSource obtainSecurityMetadataSource();

以上方法都是由AbstractSecurityInterceptor的子類（默認是FilterSecurityInterceptor）調用，那就再看看吧：

FilterSecurityInterceptor

...
//SecurityMetadataSource的實現類，因而可知，可經過外部配置。這也說明咱們能夠經過自定義SecurityMetadataSource的實現類來擴展出本身實際須要的ConfigAttribute
private FilterInvocationSecurityMetadataSource securityMetadataSource;  
...
//入口
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 {
    if ((fi.getRequest() != null)
            && (fi.getRequest().getAttribute(FILTER_APPLIED) != null)
            && observeOncePerRequest) {
        // filter already applied to this request and user wants us to observe
        // once-per-request handling, so don't re-do security checking
        fi.getChain().doFilter(fi.getRequest(), fi.getResponse());
    }
    else {
        // first time this request being called, so perform security checking
        if (fi.getRequest() != null) {
            fi.getRequest().setAttribute(FILTER_APPLIED, Boolean.TRUE);
        }
        //在這兒調用了父類（AbstractSecurityInterceptor）的方法， 也就調用了accessDecisionManager
        InterceptorStatusToken token = super.beforeInvocation(fi);

        try {
            fi.getChain().doFilter(fi.getRequest(), fi.getResponse());
        }
        finally {
            super.finallyInvocation(token);
        }
        //完了再執行（父類的方法），一前一後，AOP無處不在啊
        super.afterInvocation(token, null);
    }
}

好啦，到此應該對於Spring Security的權限管理比較清楚了。看完這個，不知你是否能擴展出一套適合本身需求的權限需求來呢，若是還不太清楚，那也不要緊，下篇就實戰一下，根據它來開發一套本身的權限體系。

歡迎你們訪問個人獨立博客：
www.javafan.cn