title | order | layout |
---|---|---|
Configuring Security for TypeScript Views |
80 |
page |
When developing server-side views, endpoint access control is done by using regular java approaches: servlet-container based security, third party libraries, or session based solutions.
This article describes all the pieces needed for securing client centric applications.
The first step is to configure authorization of each endpoint that the application exposes.
Consider the basic Vaadin endpoint defined in the following class:
@Endpoint
public class CounterEndpoint {
public int addOne(int number) {
return number + 1;
}
}
Vaadin access control features is enabled by default for any endpoint method:
if not specified in Java code explicitly, before invoking an endpoint method, the presence of Principal
object in the the request is required.
The HttpServletRequest#getUserPrincipal()
Java API is used for the check.
At this point, the servlet container or the application needs to be configured appropriately to handle user authentication. This is described in the Adding a Login Form with Spring Security and Configuring Servlet-Container Authentication articles.
In order to change the default behavior, a security Java annotation should either be placed on the endpoint class or on the endpoint method. There are the following annotations:
-
@PermitAll
Same as no annotations, allows any authenticated user to call a method via the request. -
@RolesAllowed
Grants access to users having the roles specified in the annotation value. Roles are covered in the next section. -
@DenyAll
Disallows to call the method via the request by anyone. -
@AnonymousAllowed
Permits anyone to call the method via the request without the authorization.
A security annotation that is placed on a class is applied to any public method of this class that has no security annotations. If the method has security annotations, any class-level annotation is discarded and only method ones are applied.
If there are multiple annotations specified on some entity, the following rules are applied:
-
DenyAll
overrides other annotations -
AnonymousAllowed
overridesRolesAllowed
andPermitAll
-
RolesAllowed
overridesPermitAll
Example:
@Endpoint
@DenyAll
public class MyEndpoint {
public void deniedMethod() {
// Not possible to call by any request due to class-level annotation
}
@AnonymousAllowed
public void anonymousMethod() {
// Possible to call by any request (even without
// authorization) since method level annotation
// overrides class-level one
}
@PermitAll
public void permittedToAllMethod() {
// Permitted to all authenticated users, same as if
// there were no security annotations on the class
// and the methods.
// Since there's a `@DenyAll` annotation is on the
// class, we specify this one on a method to override
// the class one.
}
@RolesAllowed("ROLE_ADMIN")
public void permittedToRoleMethod() {
// Permited to all authenticated users belonging
// to the ROLE_ADMIN
}
}
As mentioned in the previous section, every user can have roles and may affect his ability to access some endpoint methods. This section explains how to specify those for each user.
Vaadin endpoints checks the existence of roles by using the HttpServletRequest#isUserInRole(String)
Java API.
Once the servlet container has been configured to handle user authentication, when the server receives a request for the secured endpoint, user and its roles are checked, and if everything is alright, the method is executed.
When access to the UserPrincipal
is required in an endpoint, call the VaadinRequest.getCurrent()
method to access the HttpServletRequest
API.
@Endpoint
public class EchoEndpoint {
public String saySomething(String message) {
return VaadinRequest.getCurrent().getUserPrincipal().getName() + " says: " + message;
}
}
import * as endpoint from './generated/EchoEndpoint';
endpoint
.saySomething("It's snowing in Turku")
.then(response => console.log(response));
Please read the Checking Authentication article if in the client side it is needed to know whether a user is authenticated.
Vaadin endpoints are protected from CSRF attacks using the same approach with the rest of Vaadin. See the Cross-Site Request Forgery section in the security guide for more details.