Skip to main content

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.

Installation​

<dependency>
    <groupId>com.activeviam.springboot</groupId>
    <artifactId>atoti-server-starter</artifactId>
    <version>6.1.2</version>
</dependency>

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.