DataPallas Server is used by several people at once, so it needs to know who is at the keyboard and what that person is allowed to do. That is what this page is about: the account the server ships with, how to create accounts for your colleagues, what each role can and cannot do, and — if your organization already has Microsoft, Okta, or a directory of its own — how to let people sign in with the account they already have.

Table of Contents

• Start Here — the burst / burst Account
• Where Users Are Managed
• The Three Roles
• Creating a User
• Everyday Tasks
• Who Is Allowed To Do What
• Enterprise Sign-In — Use Your Company Accounts
  • Four Rules Worth Knowing First
  • 1. Microsoft — Entra ID (Azure AD) and Active Directory
  • 2. Okta — and Auth0, Ping Identity, OneLogin
  • 3. Google Workspace
  • Running Your Own Directory — LDAP, lldap, OpenLDAP, Keycloak
  • What Is Not Supported
  • Explore Data & Build Dashboards Comes Along For The Ride
• Troubleshooting

Start Here — the burst / burst Account

The first time you start DataPallas Server it creates one administrator account, burst with the password burst, and then tells everybody about it. This is what the login page looks like until you change that password:

Why the account exists. Convenience — so you can download DataPallas Server, start it and be up and running straight away, without hunting for a password first.

Why the notice exists. It is a reminder to change these credentials. Until you do, anyone who can open the login page can read them and sign in as an administrator.

What to do about it, in the first five minutes:

1. Sign in as burst / burst.
2. Open your own name in the top right of the screen, then Users.
3. Either Reset Password on the burst row and give it a real password, or — better — create a user with your own name and the ADMIN role, sign in as yourself, and delete burst.

The notice disappears on its own the moment you do. There is nothing to switch off and nothing to remember — the server checks the password itself.

Where Users Are Managed

User administration lives in one place: your own name in the top right of the screen → Users.

It is not in the Configuration sidebar and not in the settings screens — it is under your name, next to Sign Out, because that is where people look for "who am I and who else is here".

Under your name you also see the role you currently hold ("Administrator" above) — a quick way to check what you are signed in as before you start wondering why a screen is missing.

Two things to expect:

• You only see this menu entry if you are an ADMIN. If you are not, the entry is not there at all. Nothing is greyed out and nothing gives you an error message — a screen you may not use simply is not shown to you.
• On DataPallas Desktop the entry never appears, for anyone, because there are no users to manage.

The Users screen lists everybody in your DataPallas installation with their role and whether their account is active. From there you can create people, change what they are allowed to do, reset a forgotten password, temporarily lock somebody out, or remove them. The License tab next to it shows what your license entitles you to, including how many users it covers.

In the picture above only Reset Password is offered on the burst row, because that is the account being used to look at the screen — Disable and Delete are never offered on your own row.

The Three Roles

Every user has exactly one role. The roles are a ladder: each one can do everything the one below it can do, plus more.

A few things worth knowing:

• There is deliberately no read-only role. Everything there would be to look at — a finished report, a dashboard, an output file — is produced by running something, so anyone who needed to read it also needed to be able to run it. A fourth rung would have added a row to the picker and nothing else.
• You cannot change your own role, and you cannot disable or delete yourself. Those controls are switched off on your own row. It is the simplest way to make sure the last administrator cannot accidentally lock everyone out of the server.
• Your license may cap how many users you can create. If it does, creating one more is refused with a clear message rather than failing silently. Contact us to add seats.

Creating a User

1. Go to your name (top right) → Users.
2. Click New User.
3. Fill in a username, optionally an email address, a password, and pick a role. A one-line description of the role you picked is shown right under the picker, so you can see what you are handing out before you hand it out.
4. Click Create.

The new person can sign in immediately with the username and password you set.

Passwords are set and reset by an administrator, from this screen — there is no "change my own password" page. So if somebody wants a password only they know, or has forgotten the one they have, they ask an ADMIN to Reset Password on their row.

If the name is already taken you are told so straight away and nothing is created, so it is safe to try again.

Everyday Tasks

All of these are on the row of the person concerned, in your name → Users:

• Reset Password — set a new password for somebody who has forgotten theirs. You do not need to know their old one.
• Change role — the role picker on their row. The change takes effect the next time they load a screen.
• Disable — stops them signing in, and keeps everything else about the account intact. Use it for somebody on long leave, or for an account you want to close quickly while you look into something. It is fully reversible.
• Enable — lets a disabled account back in, with the same role it had before.
• Delete — removes the account for good. Use Disable if there is any chance you will want them back.

Searching and paging appear on their own once the list grows past a page, and the search box matches on name, email address and role — so "who is maria@…?" and "who are my administrators?" are both one search.

Who Is Allowed To Do What

The short version: ADMIN manages people and secrets, REPORT_AUTHOR builds things, JOB_OPERATOR runs them.

The longer version, which is worth reading once before you hand out roles:

• Only an ADMIN can create users, change roles, or reveal a stored database password. Only an ADMIN sees the Users and Connections screens at all.
• A REPORT_AUTHOR can use a database connection without being able to see its password. That is the point of the split: the person building the report does not need the credential, only the ability to read through it.
• A JOB_OPERATOR sees only the Processing screens. Configuration, Reports and Connections are not hidden behind a warning — they are simply not in their menu.

Enterprise Sign-In — Use Your Company Accounts

Out of the box DataPallas keeps its own small list of users, and for a lot of installations that is the end of the story. But if your organization already has a directory or a single sign-on system, you can point DataPallas at it — so people sign in with the account they already have, new joiners do not need a second one, and leavers lose access here the moment they lose it everywhere else.

This is configuration, not a plugin or a different download. You add a few lines to one file and restart:

<your DataPallas install>/config/application.properties

Once it is set up, a "Sign in with …" button appears on the login page, next to the ordinary username and password form.

Four Rules Worth Knowing First

These explain behaviour that otherwise looks like a bug:

1. Your local accounts keep working. DataPallas checks its own list first, then your directory. That is on purpose: if the directory is unreachable or misconfigured, you are not locked out of your own server. Keep one local administrator as your way back in.
2. Your directory says who someone is. DataPallas says what they may do. No directory knows what a REPORT_AUTHOR is, so the first time somebody signs in, DataPallas creates a local record for them to hold their role. That record has no password of its own — it exists only to carry the role.
3. Group membership is re-checked at every sign-in. Move somebody out of your admins group and they are demoted here the next time they log in. Nobody has to mirror the change by hand.
4. New people arrive as JOB_OPERATOR unless one of your groups says otherwise. A directory can hold thousands of accounts, so "this person works here" is taken to mean "they may run a report" — building and administering are granted deliberately, by group or per person.

1. Microsoft — Entra ID (Azure AD) and Active Directory

By a wide margin the most common answer to "what does your organization use". Both flavours are supported.

Microsoft Entra ID (formerly Azure AD) — the cloud one, and the one most organizations are on today. In the Azure portal, register DataPallas as an application, add a redirect URL of https://<your-datapallas-host>:9090/login/oauth2/code/entra, and under Token configuration add a groups claim. Then:

spring.security.oauth2.client.registration.entra.client-id=<application (client) ID>
spring.security.oauth2.client.registration.entra.client-secret=<client secret>
spring.security.oauth2.client.registration.entra.client-name=Microsoft
spring.security.oauth2.client.registration.entra.scope=openid,profile,email
spring.security.oauth2.client.registration.entra.authorization-grant-type=authorization_code
spring.security.oauth2.client.registration.entra.redirect-uri={baseUrl}/login/oauth2/code/{registrationId}
spring.security.oauth2.client.provider.entra.issuer-uri=https://login.microsoftonline.com/<tenant-id>/v2.0
 
# which of your groups gets which DataPallas role
datapallas.oidc.group-role-map.DataPallas-Admins=ADMIN
datapallas.oidc.group-role-map.DataPallas-Authors=REPORT_AUTHOR
datapallas.oidc.default-role=JOB_OPERATOR

One Microsoft-specific catch: Entra normally sends group IDs (long GUIDs) rather than group names, so either map the GUIDs, or use Entra App roles instead — those arrive by name and work as-is.

Active Directory — the on-premises one, still running in a great many companies. People sign in with their ordinary domain account and there is nothing to register:

datapallas.ldap.enabled=true
datapallas.ldap.url=ldaps://dc01.corp.local:636
datapallas.ldap.domain=corp.local
datapallas.ldap.base-dn=dc=corp,dc=local
 
datapallas.ldap.group-role-map.DataPallas-Admins=ADMIN
datapallas.ldap.group-role-map.DataPallas-Authors=REPORT_AUTHOR
datapallas.ldap.default-role=JOB_OPERATOR

2. Okta

The largest of the independent identity providers, and the usual choice where Microsoft is not. Create a Web Application in Okta, set its sign-in redirect URI to https://<your-datapallas-host>:9090/login/oauth2/code/okta, and add a Groups claim to the ID token (Okta does not send one by default). The DataPallas side is the same shape as Microsoft's, with Okta's issuer URL:

spring.security.oauth2.client.registration.okta.client-id=<client ID>
spring.security.oauth2.client.registration.okta.client-secret=<client secret>
spring.security.oauth2.client.registration.okta.client-name=Okta
spring.security.oauth2.client.registration.okta.scope=openid,profile,email,groups
spring.security.oauth2.client.registration.okta.authorization-grant-type=authorization_code
spring.security.oauth2.client.registration.okta.redirect-uri={baseUrl}/login/oauth2/code/{registrationId}
spring.security.oauth2.client.provider.okta.issuer-uri=https://<your-org>.okta.com/oauth2/default
 
datapallas.oidc.group-role-map.DataPallas-Admins=ADMIN
datapallas.oidc.default-role=JOB_OPERATOR

Auth0, Ping Identity and OneLogin follow exactly this pattern — only the issuer URL and the name of the groups claim change.

3. Google Workspace

Very common in smaller and mid-sized organizations. Sign-in works the same way, with one limitation that is Google's rather than ours: Google does not tell applications which groups a person belongs to. So people can sign in with their Google account, but you assign their DataPallas role yourself on the Users screen. For most teams using Google Workspace that is perfectly reasonable — you are managing a handful of people, not a thousand.

Running Your Own Directory

If you do not have any of the above, or you want DataPallas to authenticate against something you control:

• LDAP — OpenLDAP, lldap, 389 Directory Server and ApacheDS all work. lldap in particular is small, easy to stand up, and a good way to test the whole path before you point DataPallas at a production directory.
• Keycloak — the most straightforward option if you want single sign-on but have no identity provider yet. Free, self-hosted, and it does the group-to-role mapping cleanly.

datapallas.ldap.enabled=true
datapallas.ldap.url=ldap://ldap.corp.local:389
datapallas.ldap.base-dn=dc=corp,dc=local
datapallas.ldap.user-dn-patterns=uid={0},ou=people
 
datapallas.ldap.group-search-base=ou=groups
datapallas.ldap.group-search-filter=(member={0})
datapallas.ldap.group-role-map.DataPallas-Admins=ADMIN
datapallas.ldap.group-role-map.DataPallas-Authors=REPORT_AUTHOR
datapallas.ldap.default-role=JOB_OPERATOR

What Is Not Supported

• SAML 2.0 — not supported. Almost every product that speaks SAML also speaks OIDC (Microsoft ADFS has since 2016, as have Okta and Ping), so use the OIDC route above. If you have a genuinely SAML-only provider, get in touch.
• Automatic joiner/leaver provisioning (SCIM) — not supported. DataPallas creates a person's record the first time they sign in instead.

Explore Data & Build Dashboards Comes Along For The Ride

You do not configure sign-in twice. The Explore Data & Build Dashboards app — the canvas, the dashboards and the AI Crew — has no login of its own; it asks DataPallas Server who you are. Turn on Microsoft sign-in and it uses Microsoft sign-in too, with nothing further to set up.

Troubleshooting

Next Steps

• Installation & Setup — install DataPallas Server
• Scheduling & Automation — run reports hands-off
• DataPallas Server Overview — Desktop and Server compared