#Access Control

#Security concept

Security can be configured for the server and per application separately. Using different user base per application and for Admin Console access enables easy multi-tenant deployments.

To set up security for the server, use the "Server Config" page in Admin Console Overview. Application security is part of application's config screen.

Both server and application security use the same configuration options.

First, select the security module from the list of built-in modules.

#Available modules

Advanced security modules are distributed through Webswing Client Portal and are available only to Webswing Customers. It is recommended to extract the security modules distribution archive to webswing/security folder. This way the Admin Console will find them automatically.

#Configuration

#Keycloak vs OIDC

OIDC security module, can integrate directly with Keycloak and with other providers, like Okta, Active Directory, Azure. Using the Keycloak module requires definition of the providers as realms in Keycloak.

Keycloak integration is an extension of the OIDC module that allows the setup of multiple realms to be used as identity providers. When user logs-in realm is selected as a url parameter ?realm=master This is useful in specific use cases where users are forwarded to webswing from different sources or if administrators and users are defined in different places, this way they can be united in one security module.

#OpenID Connect with Keycloak

#OpenID Connect with OKTA Configuration

#SAML2 with Onelogin

#Isolate security context per browser tab

If you want to have a separate security context in each tab that you open in the same browser, you can use securityContextPerTab configuration parameter.

#Hashing the password in Embedded security module

In order to prevent plaintext password in the webswing.config and webswing.log hashing of the password is available. Webswing automatically hashes the passwords enterd in the Admin Console.

Open Admin Console > Applications > Security Module Config, change the password and click Apply.

The password can be hashed programmatically by creating a small JUnit test:

package org.webswing.server.services.security.modules.configtest;

import org.junit.Test;
import org.webswing.server.services.security.modules.embeded.HashUtil;

public class TestPasswordHash {

    @Test
    public void test() {
        String password = HashUtil.hash("password".toCharArray());
        System.out.println("Hashed password is: " + password);
    }

}

#Webswing Action

Webswing has a finely defined set of different actions that can be executed by a user. Actions are grouped by Access Types. Default Access Types are basic, support, admin.

Default mapping of actions to access types is:

AccessTypes are mapped to Roles.

Default mapping of access type to role is:

These mappings can be customized by implementing {@link RolePermissionResolver} interface.

Please have a look at default implementation in org.webswing.server.common.model.security.WebswingAction

#Maven Dependency

Webswing provides a security api when you need a custom security module. In your project you need to setup maven repository and dependency on webswing-server-security-api like:

<repositories>
        <repository>
            <id>webswing-public</id>
            <url>https://dev.webswing.org/public/nexus/repository/webswing-public/</url>
        </repository>
</repositories>

<dependencies>    
    <dependency>
        <groupId>org.webswing</groupId>
        <artifactId>webswing-server-security-api</artifactId>
        <version>23.1</version>
    </dependency>
</dependencies>

In case you need help with security setup, contact support@webswing.org