[SPRING] 스프링 보안에서 역할과 GrantedAuthority의 차이점

스프링 보안에서 역할과 GrantedAuthority의 차이점

GrantedAuthority 인터페이스와 같은 Spring Security의 개념과 구현은 액세스 권한을 부여 / 제어하는 ​​권한을 얻습니다.

createSubUsers 또는 deleteAccounts와 같은 허용 가능한 작업 (관리자 (ROLE_ADMIN 역할))에 허용하고 싶습니다.

온라인에서 볼 수있는 자습서 / 데모와 혼동스러워집니다. 나는 내가 읽은 것을 연결하려고 노력하지만, 우리는이 두 가지를 상호 교환 적으로 취급한다고 생각합니다.

그랜트 인증 문자열을 사용하는 hasRole을 봅니까? 나는 이해하는데있어서 틀림없이 그것을 잘못하고있다. 개념적으로 스프링 보안에서는 어떤 것들이 있습니까?

역할에 대한 권한과 별도로 사용자의 역할을 저장하려면 어떻게해야합니까?

또한 org.springframework.security.core.userdetails.UserDetails 인터페이스를 보았습니다.이 인터페이스는 DAO를 참조하는 인증 공급자에서 사용되며 사용자 (마지막 GrantedAuthority 참고)를 사용합니다.

public User(String username, 
            String password, 
            boolean enabled, 
            boolean accountNonExpired,
            boolean credentialsNonExpired, 
            boolean accountNonLocked, 
            Collection<? extends GrantedAuthority> authorities)

아니면 다른 두 가지를 구별하는 다른 방법이 있습니까? 또는 그것은 지원되지 않으며 우리는 우리 자신을 만들어야합니까?

해결법

1. ==============================

   1.GrantedAuthority를 ​​"허가"또는 "권리"라고 생각하십시오. 이러한 "권한"은 (보통) 문자열로 표현됩니다 (getAuthority () 메소드 사용). 이러한 문자열을 통해 사용 권한을 식별하고 유권자가 무언가에 대한 액세스 권한을 부여할지 여부를 결정할 수 있습니다.

   GrantedAuthority를 ​​"허가"또는 "권리"라고 생각하십시오. 이러한 "권한"은 (보통) 문자열로 표현됩니다 (getAuthority () 메소드 사용). 이러한 문자열을 통해 사용 권한을 식별하고 유권자가 무언가에 대한 액세스 권한을 부여할지 여부를 결정할 수 있습니다.

   사용자에게 다른 GrantAuthority (권한)를 보안 컨텍스트에 추가하여 부여 할 수 있습니다. 일반적으로 필요한 GrantedAuthorities를 반환하는 UserDetails 구현을 반환하는 고유 한 UserDetailsService를 구현하여이를 수행합니다.

   역할 (많은 예제에서 사용되는 역할)은 역할이 ROLE_ 접두어로 시작하는 GrantedAuthority라는 명명 규칙을 사용하여 "사용 권한"에 불과합니다. 더 이상 아무것도 없습니다. 역할은 GrantedAuthority에 불과하며 "허가"- "권리"입니다. ROLE_ 접두사가있는 역할이 특별히 예를 들어 처리되는 곳은 봄 보안 환경에서 많이 볼 수 있습니다. RoleVoter에서 ROLE_ 접두어가 기본값으로 사용됩니다. 이렇게하면 ROLE_ 접두어없이 역할 이름을 제공 할 수 있습니다. 스프링 보안 4 이전에는 "롤"에 대한이 특별한 핸들링이 일관되게 따르지 않았고, 권위와 역할은 종종 SecurityExpressionRoot의 hasAuthority () 메소드 구현에서 볼 수있는 것처럼 동일하게 취급되었습니다. 단순히 hasRole ()). Spring Security 4를 사용하면 역할 처리가보다 일관되고 "역할"(RoleVoter, hasRole 표현식 등)을 다루는 코드가 항상 ROLE_ 접두어를 추가합니다. 따라서 hasAuthority ( 'ROLE_ADMIN')은 ROLE_ 접두어가 자동으로 추가되므로 hasRole ( 'ADMIN')과 동일 함을 의미합니다. 자세한 내용은 스프링 보안 3 ~ 4 마이그레이션 설명서를 참조하십시오.

   그러나 여전히 : 역할은 특수한 ROLE_ 접두사가있는 단순한 권한입니다. 그래서 Spring 보안 3 @PreAuthorize ( "hasRole ( 'ROLE_XYZ')")는 @PreAuthorize ( "hasAuthority ( 'ROLE_XYZ')"와 동일하고 Spring 보안 4 @PreAuthorize ( "hasRole ( 'XYZ')") @PreAuthorize ( "hasAuthority ( 'ROLE_XYZ')")와 같습니다.

   사용 사례 :

   GrantedAuthorities에서 사용자가 속한 역할과 역할이 수행 할 수있는 작업이 끝날 수 있습니다. 역할에 대한 GrantedAuthorities에는 접두사 ROLE_이 있고 작업에는 접두사 OP_이 있습니다. 조작 권한의 예는 OP_DELETE_ACCOUNT, OP_CREATE_USER, OP_RUN_BATCH_JOBetc가 될 수 있습니다. 역할은 ROLE_ADMIN, ROLE_USER 등이 될 수 있습니다.

   당신은이 엔티티 (예 : 의사 코드) 예제와 같이 GrantedAuthority를 ​​구현하게 될 수도 있습니다.

   @Entity
   class Role implements GrantedAuthority {
       @Id
       private String id;
   
       @OneToMany
       private final List<Operation> allowedOperations = new ArrayList<>();
   
       @Override
       public String getAuthority() {
           return id;
       }
   
       public Collection<GrantedAuthority> getAllowedOperations() {
           return allowedOperations;
       }
   }
   
   @Entity
   class User {
       @Id
       private String id;
   
       @OneToMany
       private final List<Role> roles = new ArrayList<>();
   
       public Collection<Role> getRoles() {
           return roles;
       }
   }
   
   @Entity
   class Operation implements GrantedAuthority {
       @Id
       private String id;
   
       @Override
       public String getAuthority() {
           return id;
       }
   }
   

   데이터베이스에서 생성하는 역할 및 작업의 ID는 GrantedAuthority 표현입니다 (예 : "ROLE_ADMIN", "OP_DELETE_ACCOUNT"등. 사용자가 인증되면 모든 역할의 모든 GrantedAuthorities와 해당 작업이 UserDetails.getAuthorities () 메소드에서 반환되는지 확인하십시오.

   예: id가 ROLE_ADMIN 인 admin 역할은 OP_DELETE_ACCOUNT, OP_READ_ACCOUNT, OP_RUN_BATCH_JOB 작업이 할당되어 있습니다. ID가 ROLE_USER 인 사용자 역할의 작업은 OP_READ_ACCOUNT입니다.

   관리자가 결과 보안 컨텍스트에 로그인하면 GrantedAuthorities : ROLE_ADMIN, OP_DELETE_ACCOUNT, OP_READ_ACCOUNT, OP_RUN_BATCH_JOB

   사용자가 기록하면 다음과 같이 표시됩니다. ROLE_USER, OP_READ_ACCOUNT

   UserDetailsService는 모든 역할 및 해당 역할의 모든 작업을 수집하고 반환 된 UserDetails 인스턴스에서 getAuthorities () 메서드를 통해 사용할 수 있도록합니다.

2. ==============================

   2.AFAIK GrantedAuthority 및 역할은 봄 보안 분야에서 동일합니다. GrantedAuthority의 getAuthority () 문자열은 역할입니다 (기본 구현 SimpleGrantedAuthority에 따라).

   AFAIK GrantedAuthority 및 역할은 봄 보안 분야에서 동일합니다. GrantedAuthority의 getAuthority () 문자열은 역할입니다 (기본 구현 SimpleGrantedAuthority에 따라).

   귀하의 경우에는 계층 적 역할을 사용할 수 있습니다.

   <bean id="roleVoter" class="org.springframework.security.access.vote.RoleHierarchyVoter">
       <constructor-arg ref="roleHierarchy" />
   </bean>
   <bean id="roleHierarchy"
           class="org.springframework.security.access.hierarchicalroles.RoleHierarchyImpl">
       <property name="hierarchy">
           <value>
               ROLE_ADMIN > ROLE_createSubUsers
               ROLE_ADMIN > ROLE_deleteAccounts 
               ROLE_USER > ROLE_viewAccounts
           </value>
       </property>
   </bean>
   

   당신이 찾고있는 정확한 솔은 아니지만 도움이되기를 바랍니다.

   편집 : 귀하의 의견에 회신

   역할은 봄 보안의 허가와 같습니다. intercept-url과 hasRole을 함께 사용하면 어떤 역할 / 권한에 대해 어떤 작업이 허용되는지에 대한 매우 정교한 제어를 제공합니다.

   애플리케이션에서 처리하는 방식은 예를 들어 각 작업 (또는 나머지 URL)에 대한 권한 (예 : 역할)을 정의합니다. view_account, delete_account, add_account 등. 그런 다음 admin, guest_user, normal_user와 같은 각 사용자에 대한 논리적 프로필을 만듭니다. 프로필은 봄 보안과는 별도로 사용 권한을 논리적으로 그룹화 한 것입니다. 새 사용자가 추가되면 프로필이 할당되며 (허용되는 모든 권한을 가짐) 이제 사용자가 일부 작업을 수행하려고 시도하면 해당 작업에 대한 권한 / 역할이 grantedAuthorities 사용자와 비교하여 검사됩니다.

   또한 기본 RoleVoter는 접두사 ROLE_을 사용하므로 ROLE_로 시작하는 모든 권한이 역할로 간주되므로 역할 유권자의 사용자 정의 RolePrefix를 사용하고 스프링 보안에 사용하여이 기본 동작을 변경할 수 있습니다.

3. ==============================

   3.이 개념들의 관계를 이해하는 또 다른 방법은 ROLE을 Authorities의 컨테이너로 해석하는 것입니다.

   이 개념들의 관계를 이해하는 또 다른 방법은 ROLE을 Authorities의 컨테이너로 해석하는 것입니다.

   권한은 특정 데이터 범위 또는 컨텍스트와 결합 된 특정 작업을 대상으로하는 세분화 된 사용 권한입니다. 예를 들어, 읽기, 쓰기, 관리는 주어진 정보 범위에 대한 다양한 수준의 사용 권한을 나타낼 수 있습니다.

   또한 권한은 요청의 처리 흐름에 깊이 적용되며 ROLE은 요청 필터 방식으로 컨트롤러에 도달하기 전에 필터링됩니다. 베스트 프랙티스는 비즈니스 계층에서 컨트롤러를지나 당국 실행을 구현하도록 규정합니다.

   반면에 ROLES는 사용 권한 집합의 거친 표현입니다. ROLE_READER는 읽기 또는보기 권한 만 가지고 ROLE_EDITOR는 읽기 및 쓰기 권한을 갖습니다. 역할은 주로 다음과 같은 요청 처리의 외곽에서 첫 번째 스크리닝에 사용됩니다. http.   ...  .antMatcher (...). hasRole (ROLE_MANAGER)

   당국은 요청의 프로세스 흐름이 깊게 시행되어 권한을보다 세밀하게 적용 할 수 있습니다. 예를 들어 사용자는 리소스를 먼저 수준을 올리려면 하위 수준 리소스에 읽기 권한 만 가질 수 있습니다. ROLE_READER를 가지고 있으면이 리소스를 편집 할 수있는 쓰기 권한이 필요하므로 첫 번째 레벨 리소스를 편집 할 수있는 권한이 없지만 @PreAuthorize 인터셉터는 하위 리소스를 편집 할 수있는 임시 태그를 차단할 수 있습니다.

   제이크

from https://stackoverflow.com/questions/19525380/difference-between-role-and-grantedauthority-in-spring-security by cc-by-sa and MIT license