TOC

Zugewiesene Autorität versus Rolle in der Frühlingssicherheit

Gewährte Autorität versus Rolle im Frühjahr Sicherheit

1. Überblick

In diesem kurzen Artikel erklären wirthe subtle but significant difference between a Role and a GrantedAuthority in Spring Security. Ausführlichere Informationen zu Rollen und Berechtigungen finden Sie im Artikelhere.

Weitere Lektüre:

Spring Security Authentication Tutorial

Erstellen eines Registrierungsprozesses in Produktionsqualität für neue Benutzer und eines Anmeldeflusses für vorhandene Benutzer.

Read more →

Frühjahrssicherheit für eine REST-API

So sichern Sie eine REST-API mit Spring Security: XML-Konfiguration, web.xml, HTTP-Statuscodes für die Authentifizierung usw.

Read more →

Basisauthentifizierung von Spring Security

Richten Sie im Frühjahr die Standardauthentifizierung ein - die XML-Konfiguration, die Fehlermeldungen und ein Beispiel für die Verwendung der gesicherten URLs mit curl.

Read more →

2. GrantedAuthority

In Spring Security können wirthink of each GrantedAuthority as an individual privilege. Beispiele könntenREAD_AUTHORITY,WRITE_PRIVILEGE oder sogarCAN_EXECUTE_AS_ROOT sein. Wichtig zu verstehen ist, dassthe name is arbitrary.

Wenn SieGrantedAuthority direkt verwenden, z. B. durch Verwendung eines Ausdrucks wiehasAuthority(‘READ_AUTHORITY'),, sind wirrestricting access in a fine-grained manner.

Wie Sie wahrscheinlich feststellen können, können wir uns auf das Konzept vonauthority beziehen, indem wir auchprivilege verwenden.

3. Rolle als Autorität

In ähnlicher Weise können wir in Spring Securitythink of each Role as a coarse-grained GrantedAuthority that is represented as a String and prefixed with “ROLE“. Wenn Sie einRole direkt verwenden, z. B. durch einen Ausdruck wiehasRole(“ADMIN”), beschränken wir den Zugriff grobkörnig.

Es ist erwähnenswert, dass das Standardpräfix „ROLE”“ konfigurierbar ist. Die Erläuterung der Vorgehensweise würde jedoch den Rahmen dieses Artikels sprengen.

The core difference between these two is the semantics we attach to how we use the feature. Für das Framework ist der Unterschied minimal - und es behandelt diese im Grunde genauso.

4. Rolle als Container

Nachdem wir gesehen haben, wie das Framework das Konzept vonroleverwendet, wollen wir auch schnell eine Alternative diskutieren - und das istusing roles as containers of authorities/privileges.

Dies ist eine übergeordnete Herangehensweise an Rollen - und macht sie eher zu einem geschäftsorientierten als zu einem implementierungsorientierten Konzept.

Das Spring Security-Framework enthält keine Anleitung zur Verwendung des Konzepts. Die Auswahl ist daher vollständig implementierungsspezifisch.

5. Spring-Sicherheitskonfiguration

Wir können eine differenzierte Autorisierungsanforderung nachweisen, indem wir den Zugriff auf/protectedbyauthority auf Benutzer mitREAD_AUTHORITY beschränken.

Wir können eine grobkörnige Autorisierungsanforderung nachweisen, indem wir den Zugriff auf/protectedbyrole auf Benutzer mitROLE_USER beschränken.

Konfigurieren wir ein solches Szenario in unserer Sicherheitskonfiguration: 

@Override
protected void configure(HttpSecurity http) throws Exception {
    // ...
    .antMatchers("/protectedbyrole").hasRole("USER")
    .antMatchers("/protectedbyauthority").hasAuthority("READ_PRIVILEGE")
    // ...
}

6. Einfache Dateninit

Nachdem wir die Kernkonzepte besser verstanden haben, wollen wir beim Starten der Anwendung einige Setup-Daten erstellen.

Dies ist natürlich eine sehr einfache Methode, um mit einigen Testbenutzern während der Entwicklung auf den neuesten Stand zu kommen - und nicht, wie Sie mit Daten in der Produktion umgehen sollten.

Wir werden auf das Kontextaktualisierungsereignis warten: 

@Override
@Transactional
public void onApplicationEvent(ContextRefreshedEvent event) {
    MyPrivilege readPrivilege
      = createPrivilegeIfNotFound("READ_PRIVILEGE");
    MyPrivilege writePrivilege
      = createPrivilegeIfNotFound("WRITE_PRIVILEGE");
}

Die tatsächliche Implementierung spielt hier keine Rolle - und hängt im Allgemeinen von der verwendeten Persistenzlösung ab. Der Hauptpunkt ist - wir behalten die Behörden bei, die wir im Code verwenden.

7. UserDetailsService

Unsere Implementierung vonUserDetailsService is where the authority mapping takes place. Sobald sich der Benutzer authentifiziert hat, füllt unsere MethodegetAuthorities()das ObjektUserDetailsund gibt es zurück: 

private Collection getAuthorities(
  Collection roles) {
    List authorities
      = new ArrayList<>();
    for (Role role: roles) {
        authorities.add(new SimpleGrantedAuthority(role.getName()));
        role.getPrivileges().stream()
         .map(p -> new SimpleGrantedAuthority(p.getName()))
         .forEach(authorities::add);
    }

    return authorities;
}

8. Ausführen und Testen des Beispiels

Wir können die Java-Anwendung des BeispielsRolesAuthoritiesApplicationausführen, die inGitHub project enthalten ist.

Um die rollenbasierte Autorisierung in Aktion zu sehen, müssen wir:

Um die autorisierungsbasierte Autorisierung in Aktion zu sehen, müssen wir uns von der Anwendung abmelden und dann:

9. Fazit

In diesem kurzen Tutorial haben wir uns den subtilen, aber signifikanten Unterschied zwischen aRole und aGrantedAuthority in Spring Security angesehen.

Related