Stellen Sie sich eine GrantedAuthority als "Erlaubnis" oder "Recht" vor. Diese "Berechtigungen" werden (normalerweise) als Zeichenfolgen (mit der getAuthority()Methode) ausgedrückt . Mit diesen Zeichenfolgen können Sie die Berechtigungen identifizieren und Ihre Wähler entscheiden, ob sie Zugriff auf etwas gewähren.
Sie können Benutzern verschiedene GrantedAuthoritys (Berechtigungen) erteilen, indem Sie sie in den Sicherheitskontext stellen. Normalerweise implementieren Sie dazu Ihren eigenen UserDetailsService, der eine UserDetails-Implementierung zurückgibt, die die erforderlichen GrantedAuthorities zurückgibt.
Rollen (wie sie in vielen Beispielen verwendet werden) sind nur "Berechtigungen" mit einer Namenskonvention, die besagt, dass eine Rolle eine GrantedAuthority ist, die mit dem Präfix beginnt ROLE_. Mehr gibt es nicht. Eine Rolle ist nur eine GrantedAuthority - eine "Erlaubnis" - ein "Recht". In der Frühlingssicherheit sehen Sie viele Stellen, an denen die Rolle mit ihrem ROLE_Präfix speziell behandelt wird, z. B. im RoleVoter, wo das ROLE_Präfix standardmäßig verwendet wird. Auf diese Weise können Sie die Rollennamen ohne ROLE_Präfix angeben . Vor Spring Security 4 wurde dieser spezielle Umgang mit "Rollen" nicht sehr konsequent befolgt, und Behörden und Rollen wurden häufig gleich behandelt (wie Sie zhasAuthority()hasRole()). Mit Spring Security 4 ist die Behandlung von Rollen konsistenter und Code, der sich mit "Rollen" (wie dem RoleVoter, dem hasRoleAusdruck usw.) befasst, fügt immer das ROLE_Präfix für Sie hinzu. Bedeutet hasAuthority('ROLE_ADMIN')also dasselbe wie hasRole('ADMIN')weil das ROLE_Präfix automatisch hinzugefügt wird. Weitere Informationen finden Sie im Migrationshandbuch für Federsicherheit 3 bis 4 .
Aber dennoch: Eine Rolle ist nur eine Autorität mit einem speziellen ROLE_Präfix. In Spring ist Sicherheit 3 @PreAuthorize("hasRole('ROLE_XYZ')")dasselbe wie @PreAuthorize("hasAuthority('ROLE_XYZ')")und in Spring ist Sicherheit 4 @PreAuthorize("hasRole('XYZ')")dasselbe wie @PreAuthorize("hasAuthority('ROLE_XYZ')").
In Bezug auf Ihren Anwendungsfall:
Benutzer haben Rollen und Rollen können bestimmte Vorgänge ausführen.
Sie könnten sich GrantedAuthoritiesfür die Rollen entscheiden, zu denen ein Benutzer gehört, und für die Vorgänge, die eine Rolle ausführen kann. Die GrantedAuthoritiesfür die Rollen haben das Präfix ROLE_und die Operationen haben das Präfix OP_. Ein Beispiel für Behörden Betrieb könnte sein OP_DELETE_ACCOUNT, OP_CREATE_USER, OP_RUN_BATCH_JOBusw. können Rollen sein ROLE_ADMIN, ROLE_USER, ROLE_OWNERusw.
Möglicherweise werden Ihre Entitäten GrantedAuthoritywie in diesem Beispiel (Pseudocode) implementiert :
@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;
}
}
Die IDs der Rollen und Operationen , die Sie in Ihrer Datenbank erstellen würde die GrantedAuthority Darstellung, zB ROLE_ADMIN, OP_DELETE_ACCOUNTusw. Wenn ein Benutzer authentifiziert wird, stellen Sie sicher , dass alle GrantedAuthorities aller seiner Rollen und die entsprechenden Operationen werden von den UserDetails.getAuthorities () zurück Methode.
Beispiel: Die Admin - Rolle mit der ID ROLE_ADMINhat die Operationen OP_DELETE_ACCOUNT, OP_READ_ACCOUNT, OP_RUN_BATCH_JOBihm zugeordneten. Die Benutzerrolle mit ID ROLE_USERhat die Operation OP_READ_ACCOUNT.
Wenn ein Admin - Protokolle in der resultierenden Sicherheitskontext werden die GrantedAuthorities haben:
ROLE_ADMIN, OP_DELETE_ACCOUNT, OP_READ_ACCOUNT,OP_RUN_BATCH_JOB
Wenn ein Benutzer meldet es, wird es:
ROLE_USER,OP_READ_ACCOUNT
Der UserDetailsService würde dafür sorgen, dass alle Rollen und alle Operationen dieser Rollen erfasst und durch die Methode getAuthorities () in der zurückgegebenen UserDetails-Instanz verfügbar gemacht werden.