Skip to main content

Authentication

Currently, ACUBETotal supports 5 main ways of authentication:

  • Local credentials
  • Google OAuth
  • Github OAuth
  • LDAP Integration
  • Keycloak Integration

This authentication mechanism is built upon the next-auth authentication mechanisms, and enhanced using prisma adapters.

All authentication mechanisms can be defined by the different environment variables.

Organisations​

Users will only be allowed to view submissions in their own organisations. This makes it possible for each user to view only the submissions tagged to the organisations that are tagged to it.

danger

Users must belong to at least one organisation. Users not in an organisation will not be able to see any submissions.

info

Each user and submission can be tagged to multiple organisations.

The prisma container is responsible for performing all database schema migrations, including the user and organisation schema. Similarly, the container will perform the seeding of the database as well, including the creation of the default user anonymous, as well and the default organisations public and admin.

public organisation​

All users will be placed under the public organisation. By default, all submissions will also be tagged under the public organisation, unless other specified.

admin organisation​

Only users under the admin organisation will be able to view the admin page, from which he or she can administer the standard sys-admin actions. They will also be able to view all submissions, regardless of the organisations tagged to each submission.

Using ACUBETotal as an SSO service​

ACUBETotal can be used as an SSO service to enforce authentication on multiple subdomains. Set the NEXTAUTH_COOKIE_DOMAIN environment variable to the appropriate root domain.

info

SSO stands for Single Sign-On.

NGINX​

To automate authentication and redirecting unauthorized requests to the authentication server, you can make use of NGINX, specifically the auth_request directive. This is convenient, especially since we already use NGINX as a reverse proxy to host multiple subdomains on the same machine.

info

The ngx_http_auth_request_module module (1.5.4+) implements client authorization based on the result of a subrequest. If the subrequest returns a 2xx response code, the access is allowed. If it returns 401 or 403, the access is denied with the corresponding error code. Any other response code returned by the subrequest is considered an error.

Reference: NGINX auth_request documentation

server {
    location / {
        auth_request /auth;
        auth_request_set $new_cookie $sent_http_set_cookie;
        add_header Set-Cookie $new_cookie;
        ...
    }

    location /auth {
        internal;
        proxy_pass https://auth.acube.sg/api/auth/check;
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";
        proxy_set_header X-Original-URI $request_uri;
    }
    error_page 401 = @error401;

    # If the user is not logged in, redirect them to SSO auth
    location @error401 {
        return 302 https://auth.acube.sg/auth/sign-in/?callbackUrl=https://$host$request_uri;
    }
    ...
}

The above configuration will enforce you to be logged into ACUBETotal when accessing the domain with the above configuration.