GrantedAuthority를 "권한"또는 "권리"라고 생각하십시오. 이러한 "권한"은 (일반적으로) 문자열 ( getAuthority()방법 과 함께)로 표현됩니다 . 이 문자열을 통해 권한을 식별하고 유권자가 무언가에 대한 액세스 권한을 부여 할 것인지 결정할 수 있습니다.
보안 컨텍스트에 배치하여 사용자에게 다른 GrantedAuthority (권한)를 부여 할 수 있습니다. 일반적으로 필요한 GrantedAuthorities를 리턴하는 UserDetails 구현을 리턴하는 고유 한 UserDetailsService를 구현하여이를 수행합니다.
역할 (많은 예제에서 사용됨)은 역할이 접두사로 시작하는 GrantedAuthority라는 이름 지정 규칙이있는 "권한"입니다 ROLE_. 더 이상 아무것도 없습니다. 역할은 단지 GrantedAuthority- "권한"- "권리"입니다. ROLE_접두사가 붙은 역할이 접두사가 ROLE_기본값으로 사용되는 RoleVoter와 같이 접두사가 있는 역할이 특별히 처리 되는 스프링 보안의 많은 부분이 있습니다 . 이를 통해 ROLE_접두사없이 역할 이름을 제공 할 수 있습니다 . Spring security 4 이전에는 이러한 "역할"의 특수한 처리가 일관되게 따르지 않았으며 권한과 역할이 종종 동일하게 취급되었습니다 (예 :hasAuthority()hasRole()). 봄 보안 4과 함께, 역할의 치료는 "역할"을 가진 거래 (같은 것을보다 일관되고 코드 RoleVoter의 hasRole표현 등이) 항상 추가 ROLE_당신을 위해 접두사. 그래서 hasAuthority('ROLE_ADMIN')와 같은 의미 hasRole('ADMIN')때문에 ROLE_접두사가 자동으로 추가됩니다. 추가 정보 는 스프링 보안 3-4 마이그레이션 안내서 를 참조하십시오.
그러나 여전히 : 역할은 특수한 ROLE_접두사가 있는 권한 일뿐 입니다. 따라서 스프링 보안 3의 @PreAuthorize("hasRole('ROLE_XYZ')")경우와 동일하며 @PreAuthorize("hasAuthority('ROLE_XYZ')")스프링 보안 4의 @PreAuthorize("hasRole('XYZ')")경우와 동일합니다 @PreAuthorize("hasAuthority('ROLE_XYZ')").
사용 사례와 관련하여 :
사용자에게는 역할이 있으며 역할은 특정 작업을 수행 할 수 있습니다.
GrantedAuthorities사용자가 속한 역할과 역할이 수행 할 수있는 작업으로 끝날 수 있습니다. GrantedAuthorities역할에 대한 접두사를 가지고 ROLE_와 작업은 접두사가 OP_. 조작 당국이 수에 대한 예는 OP_DELETE_ACCOUNT, OP_CREATE_USER, OP_RUN_BATCH_JOB등의 역할을 할 수있다 ROLE_ADMIN, ROLE_USER, ROLE_OWNER등
GrantedAuthority이 (의사 코드) 예제와 같이 엔티티를 구현하게 할 수 있습니다 .
@Entity
class Role implements GrantedAuthority {
@Id
private String id;
@ManyToMany
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;
@ManyToMany
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가있는 관리자 역할 에는 작업이 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 () 메서드를 통해 사용할 수 있도록주의를 기울입니다.