1
1
.
.
4
4
A
A
u
u
t
t
h
h
o
o
r
r
i
i
z
z
a
a
t
t
i
i
o
o
n
n
I
I
n
n
f
f
o
o
Following tutorials show a different ways of specifying which Roles have access to which Endpoints.
Since Roles are assigned to Users this defines which Users have access to which Endpoints (depending on their Roles).
Or in other words which Roles (Users) are authorized to access which Endpoints.
Security Expressions - API allows you to define Roles and Authorities through API Expression.
SecurityConfig.java
httpSecurity.authorizeRequests()
.antMatchers("/endPoint1").denyAll() //No access (even after log in)
.antMatchers("/endPoint2").permitAll() //All have access (anonymous access without Login)
.antMatchers("/endPoint3").hasRole("ADMIN") //Only ADMIN ROLE can access (after log in)
.antMatchers("/endPoint4").hasAnyRole("ADMIN", "USER"); //Only ADMIN/USER ROLE can access (after log in)
Security Expressions - @Secured allows you to define access through Annotations that can only specify Roles.
SecurityConfig.java
@EnableGlobalMethodSecurity(securedEnabled = true)
MyController.java
@Secured("ROLE_ADMIN")
@Secured({"ROLE_ADMIN", "ROLE_USER"})
Security Expressions - @PreAuthorize allows you to define access through Annotations that can use Expressions.
SecurityConfig.java
@EnableGlobalMethodSecurity(prePostEnabled = true)
MyController.java
@PreAuthorize("hasRole('ADMIN')")
@PreAuthorize("hasAnyRole('ADMIN', 'USER')")
Ant Matchers are used to specify URL Patterns to which API Expression will be applied.
SecurityConfig.java
httpSecurity.authorizeRequests()
.antMatchers("/endPoint1").denyAll()
.antMatchers("/endPoint2", "/endPoint3").permitAll()
.antMatchers("/*", "/**", "/end*").permitAll()
R
R
o
o
l
l
e
e
s
s
v
v
s
s
A
A
u
u
t
t
h
h
o
o
r
r
i
i
t
t
i
i
e
e
s
s
Roles & Authorities are technically the same - they can be used to achieve the same purpose in exactly the same way.
This means that wherever you are using Roles you could replace them with Authorities and vice versa.
Confusion between the two arises for two reasons
● they are referenced differently
● they are intended to be used for two different security design patterns
D
D
i
i
f
f
f
f
e
e
r
r
e
e
n
n
c
c
e
e
s
s
i
i
n
n
r
r
e
e
f
f
e
e
r
r
e
e
n
n
c
c
i
i
n
n
g
g
Roles & Authorities have their own sets of Methods hasRole() vs hasAuthority()
Role must have prefix ROLE_ ROLE_ADMIN
Role is referenced by omitting prefix ROLE_ hasRole("ADMIN")
Authority is referenced by using its full name hasAuthority("author.read")
D
D
i
i
f
f
f
f
e
e
r
r
e
e
n
n
c
c
e
e
s
s
i
i
n
n
d
d
e
e
s
s
i
i
g
g
n
n
p
p
a
a
t
t
t
t
e
e
r
r
n
n
Although technically the same, Roles & Authorities are conceptually/logically different.
As such it makes logically more sense to use one over the other depending on the chosen security design pattern.
The main difference between these two security design patterns are that
● single Role is assigned to multiple Endpoints @Secured("ROLE_ADMIN")
● each Endpoint gets unique Authority @Secured("author.read")
R
R
o
o
l
l
e
e
s
s
You can think of Roles as simple out of the box solution for implementing security (that doesn't require any custom code).
Using security design pattern with Roles is simpler of the two
● assign the same Role to multiple Endpoints
● assign that Role to a User
● this way you have defined to which Endpoints User has access to
● the whole configuration is contained inside the Controller using simple Annotations (no need for custom Entities)
A
A
u
u
t
t
h
h
o
o
r
r
i
i
t
t
i
i
e
e
s
s
Using security design pattern with Authorities is more complex of the two
● assign unique Authority to each Endpoint
● create custom Entity Profile which will be used to group Authorities
● inside the Database assign multiple Authorities to each Profile
● assign Profile to Account
When you get Account from DB
● you get its Profile
● then you get Authorities related to that Profile
● then you create User with all of these Authorities
● this way you have defined to which Endpoints Account/User has access to
Alternatively instead of using DB you could define Profiles and related Authorities through some Configuration File/Class.
As you can see this is far more complicated approach compared to using Roles.
In this approach security configuration is no longer encapsulated in Controller (which User has access to which Endpoint).
Instead configuration is moved to DB through Profile Entity which groups Authorities (kind of replacing Spring Role).
U
U
s
s
a
a
g
g
e
e
In your application you should use either Roles or Authorities - but not both in the same application.
Technically you could use them both but that is likely to lead to a confusion.
That is because you will have security configuration in two different places - Controller and DB.
