The Atoti Server Starter
Introduction
The Atoti Server Starter is the cornerstone of an Atoti Server application; almost all Atoti projects using starters will use it. Its function is to do setup all the essentials of an Atoti application, such as various services, endpoints and a functional security layer.
Services setup
The Atoti Server Starter automatically configures quite a few services that used to require manual instantiation, such as all the REST, WS and XMLA services and endpoints, and even some legacy services such as SOAP. This step of building an Atoti Server application is now handled for you.
Stock Security
The Atoti Server Starter a default security configuration, to enable build MVPs quickly. You may keep it as is, alter it using the mechanisms described below, or replace it entirely with a security configuration of your own.
Roles and rights
The default security recognizes two role categories: users and admins. Admins have every right, and users can only access a limited set of endpoints. You can set which roles are admins and which are users using the following properties:
atoti:
server:
security:
roles_users:
- "Role1"
- "Role2"
roles_admin:
- "admin"
If these properties are not set, ROLE_USER
is set as the only user role and ROLE_ADMIN
as the only admin role.
Filter chains and DSLs
The stock security uses a couple of DSLs that may be extended or overwritten to better suit your needs. They are intended to be used for both the Atoti Server endpoints and your own endpoints, if any.
Human to Machine DSL
This DSL configures all the endpoints that are intended to be accessed through a browser.
Its default implementation is AtotiServerHumanDsl
.
If you wish to change its behavior, you can replace it by exposing a bean of type HumanToMachineSecurityDsl
,
either by extending our default implementation, or creating your own.
Machine to Machine DSL
This DSL configures all the endpoints that are intended to be accessed through a direct request, such as REST, WS, or GraphQL requests.
Its default implementation is AtotiServerMachineDsl
.
If you wish to change its behavior, you can replace it by exposing a bean of type MachineToMachineSecurityDsl
,
either by extending our default implementation, or creating your own.
XMLA DSL
This DSL configures the XMLA endpoint, which often needs a specific configuration because of Excel's constraints.
Its default implementation is AtotiServerXmlaDsl
.
If you wish to change its behavior, you can replace it by exposing a bean of type XmlaSecurityDsl
,
either by extending our default implementation, or creating your own.
Authentication Flow
A basic authentication flow comes bundled with the starter, adding the /login
and /logout
endpoints,
for logging in and logging out respectively. The login endpoint supports the redirectUrl
optional path parameter,
which specifies an URL to be redirected to after a successful login.
This flow may be configured with the following properties:
atoti:
server:
security:
login_page:
form: "file:login_page.html"
logo: "file:icon.png"
logout_page:
form: "file:logout_page.html"
logo: "file:icon.png"
The form
property of each page allows you to specify the entire form used for that page,
while the logo
property allows you to change the ActiveViam logo to one of your choosing.
For more details, see com.activeviam.springboot.atoti.server.starter.api.AtotiSecurityProperties.PageProperties
.
You may also want to disable the default authentication flow by using this property:
PropertiesNames.AUTHENTICATION_FLOW_ENABLED_PROPERTY
For more extensive changes
If these DSL are not enough to configure the security to your needs, you may opt to write your own security from scratch.
To do so, you may use the properties described in the PropertiesNames
class to disable the SecurityFilterChains that are not to your liking,
allowing you to write your own to secure the chosen endpoint.