CODEWITHSUNDEEP
javaspring-security
emilly
emilly

Reputation: 10530

Understanding RoleVoter concept?

I can see below configuration in one of the project

<bean id="myFilterSecurityInterceptor"
        class="org.springframework.security.web.access.intercept.FilterSecurityInterceptor">
        <property name="authenticationManager" ref="authenticationManager" />
        <property name="accessDecisionManager" ref="accessDecisionManager" />
        <property name="securityMetadataSource">
            <security:filter-security-metadata-source>
                <security:intercept-url pattern="/user/**" access="PERMISSION_VIEW_USER" />
                             .....
            </security:filter-security-metadata-source>
        </property>
    </bean>

    
    <bean id="accessDecisionManager"
        class="org.springframework.security.access.vote.AffirmativeBased" >
        <property name="decisionVoters">
            <list>
                <bean class="org.springframework.security.access.vote.RoleVoter" />
                <bean class="org.springframework.security.access.vote.RoleVoter">
                    <property name="rolePrefix" value="PERMISSION_"/>
                </bean>
            </list>
        </property>

Question 1 :-

I am not able to understand what role two bean element with class "RoleVoter" is playing here ? I mean is not single role voter is sufficient ?

Question 2:-

Also under one bean
how does property name="rolePrefix" value="PERMISSION_" helps?

My understanding about second question is when user tries to access URL /user/, RoleVoter will match the granted authorities against the value given against access attribute (in this case PERMISSION_VIEW_USER) and also it should start with "PERMISSION_"(given as value of rolePrefix). Is that right?

I got my understanding confirmed about question 2 with [this link][1]. Don't bother about this.

Upvotes: 0

Views: 1604

Answers (1)

Shaun the Sheep
Shaun the Sheep

Reputation: 22762

If you have a solution to your second question, then that really answers the first one. The default prefix the RoleVoter uses is ROLE_, so it will ignore any attributes which do not match.

Adding a second voter with a customized prefix means that attributes matching both ROLE_ and PERMISSION_ will be taken into account. The behaviour is independent of the prefix though, so unless there's some other reason for having the different prefixes in your application, it would be simpler if you just chose one ans stuck with it.

Alternatively, you can use the newer expression syntax for access control, which is probably easier to understand and doesn't need any special naming conventions at all.

Upvotes: 2

Related Questions