Login and users

Note: this is an earlier, still incomplete version of the user guide. Updated documentation is in preparation; some screens and labels may differ from the current application.

This guide takes an administrator through every login setting, user attribute, group, user account, local registration, impersonation, API key, SSO provider, and personal security and access screen.

The examples were created on a clean SQLite installation. Accounts, groups, and keys shown here exist only for documentation. Secrets and personal attribute values have been removed from screenshots. In production, use your own names, domains, lifetimes, and least-privilege rules.

Login settings
User attributes
Groups
Users and local accounts
Local login and registration
Impersonation
API keys
Common SSO workflow
SAML
SAML proxy
CAS
OIDC
OAuth2
Personal profile: security and access
Verification and security checklist

Open Settings → Users → Login settings . This page enables authentication methods for the application. Enabling a provider only makes its configuration and menu available; every individual profile must still be saved, activated, tested, and mapped correctly.

Main switches

Local login enables username and password authentication stored by Simbioza.
SimpleSAMLphp, CAS, OIDC, and OAuth2 enable the corresponding SSO profile groups.
Break-glass local login keeps a separate direct administrator route available when normal local login is disabled. Protect that account with a strong unique password and use it only for recovery.
Login duration controls the inactivity period after which the session expires. Use a shorter period on administrative and shared devices.

“Profile active” is not the same as the green check mark. Active means that the profile may be used. The green check and Tested and operational status appear only after a successful provider test and valid required mappings. An active profile may still be non-operational.

2. User attributes

Open User attributes . The model normally includes e-mail, first name, and last name. Add an attribute when the application must store a value outside the basic profile, such as an institution, department, employee number, or an external directory role.

User attributes

Default and custom attributes in the English interface.

Adding an attribute

Enter a stable machine name in lowercase without spaces, such as affiliation .
Provide separate Croatian and English labels.
Choose the data type and configure Required , Registration , Profile , and Active independently.
Save it. The new field becomes available in user profiles and in every SSO profile mapping table.

Bilingual custom attribute example — The affiliation model field is labelled Ustanova / Institution, remains available to profiles and SSO mappings, and is excluded from self-registration.

Mapping connects a Simbioza model field to the exact attribute name returned by the provider. Attribute names are exact: mail , givenName , and given_name are different fields. Test first, inspect the returned names, and only then enter the mappings. An SSO mapping does not automatically add the field to the public registration form.

Which fields are included in self-registration? The administrator chooses this per attribute. Registration controls whether a field appears in the public form, while Required rejects an empty value in contexts where that field participates. When both settings are enabled, the field is mandatory during self-registration. A required attribute must also have a valid SSO mapping for a provider profile test to become operational. In this example, affiliation stores the institution supplied by a provider and appears in the profile, so it is intentionally excluded from registration.

3. Groups

Groups collect users and carry permissions. The Administrator group is a protected system group and should not be used as a normal business group. Create separate least-privilege groups for departments, projects, or roles.

Groups

System and example groups in the English interface.

Select New group and enter a clear name and description.
Assign only the permissions members actually need.
Save the group, then add or remove membership from the user detail screen.
Where supported by the installation, SSO users can also be assigned through a rule based on a mapped attribute.

Example group before saving — A documentation group before saving; labels follow the currently selected site language.

4. Users and local accounts

The Users screen provides a compact account list. ID and login columns are intentionally narrower so that the display name and actions remain readable on smaller screens.

Responsive user table

Balanced user table columns in the English interface.

Creating a local user

Select New user .
Enter a unique login identifier, display name, and e-mail.
Choose the local authentication source and assign a strong temporary password.
Require a password change on first login.
Assign only the required groups; administrator access must not be the default.

Create local user form

Example local account form with no password shown.

New user in the list — The documentation user after creation.

User details — Account state, linked providers, and group memberships.

Mandatory first-login password change — A temporary password forces the user to choose a new one before continuing.

On the detail page, verify account activity, authentication source, linked external identities, and group memberships. Deactivation is usually safer than deletion because it preserves the audit trail. Never manually replace an external provider's stable subject identifier.

Local login controls self-registration. Keep it disabled for closed systems and create accounts administratively or through trusted SSO. If registration is enabled, combine it with an appropriate privacy notice, bot protection, and e-mail verification process. The public form includes only user attributes whose Registration option is enabled; the SSO-only Institution field is therefore not shown here.

Registration disabled — Recommended initial state for a closed application.

Registration enabled only for a controlled example.

Registration link — The login screen shows registration only after it is enabled.

Registration form — Public form with the selected registration fields; the Institution attribute used for SSO mapping is intentionally hidden.

After testing, restore the intended production state. Passwords should be unique, sufficiently long, and stored in a password manager. Administrators must never ask users for their current password.

6. Impersonation

Impersonate user temporarily opens the application in the selected user's context. Use it for permission and display diagnostics, not for performing business actions on behalf of the user.

Impersonation screen — Selecting an account for controlled support diagnostics. Select only the account needed for the support case.

The interface clearly indicates the active impersonated session.

Return to administrator — End the task by returning to your administrator account.

Impersonation does not test actual SSO authentication, MFA, or provider policy. Use the profile test or a dedicated test account for that purpose.

7. API keys

An API key acts as its owner. Scopes can only reduce the owner's existing permissions; they cannot grant permissions the owner does not have. Use a separate key per integration, a descriptive label, the shortest practical lifetime, and the smallest set of scopes.

API key administration in the English interface.

Direct key issuance

Select the owner and only the required scopes.
Set an expiry date and, where supported, a network restriction.
Create the key and immediately copy the secret to secure storage.
The secret is shown only once. If it is lost, revoke the key and issue a new one.

Least-privilege API key — An intentionally restricted key before creation.

One-time API secret — The secret has been removed from the screenshot.

Active API keys — Review and revoke active keys from this list.

User request and administrator approval

A user may request a key from the personal profile and explain its purpose. The administrator reviews owner, scopes, lifetime, and justification, then approves or rejects the request. After approval the user receives a notification and can reveal the secret once.

API key request form — The user requests a restricted key and states its purpose.

Request sent — The request waits for administrator review.

Pending API request — The administrator checks the request before approval.

Approved API request — Approval creates the key without revealing the secret to the administrator.

API key notification — The user is notified about the decision.

Approved request notification — The notification leads to one-time secret retrieval.

One-time API secret retrieval — The secret is removed and cannot be displayed again after closing.

Completed API request — The completed request remains auditable without exposing the secret.

8. Common SSO workflow

Register the application with the provider and enter only the necessary endpoints, Client ID, and secret.
Save the active profile. Existing secrets are never displayed while editing; leaving the secret field empty retains the server-side value.
Select Test profile before guessing mappings. Complete a real login to collect the provider's actual attributes.
Map subject, login, display name, and user fields from the returned names.
Test again. Only Tested and operational together with a green check confirms a complete profile.

Allowed domains

The list restricts login to organizational domains. Enter one domain per line or a comma-separated list. example.org allows that domain and its subdomains; a suffix such as hr permits identifiers whose domain ends in .hr . An empty list imposes no domain restriction.

Domain source attribute must be the real provider attribute containing a value such as user@example.org or a domain. It is required only when the allowed-domain list is populated. Do not use a display name or another mutable value.

Public callback addresses

The provider must return the browser to the public URL of the same installation. Include a subdirectory when one is used: for an application at https://simbioza.example.org/simbioza , enter that complete value as the public base URL. It is not the internal PHP-FPM, container, or database address. Register the exact callback URLs shown by the profile.

9. SAML

A SAML profile depends on a separately installed and correctly configured SimpleSAMLphp . Its autoloader, SP auth source, certificates, metadata, and return URLs must already work. The path to vendor/autoload.php and the auth source name must match that installation.

Initial SAML configuration — The profile is saved, but mappings are not yet confirmed.

First SAML test — Connectivity works and attributes were collected; values are redacted.

Launching the AAI login — The English Simbioza login screen starts the configured AAI@EduHr SSO flow without exposing credentials.

SAML mappings — Required mappings entered from the actual returned attributes.

Operational SAML profile

The repeated test confirms an operational SAML profile.

10. SAML proxy and child profiles

A proxy instance represents one SimpleSAMLphp auth source that can expose several upstream providers. The Default tab defines the shared autoload path, auth source, and base mapping. Additional child tabs inherit the shared connection settings while keeping their own attribute mappings.

A proxy has no Allowed domains or Domain source attribute fields. This is deliberate: upstream providers may return different identifiers and domains. Enforce restrictions at the proxy or upstream provider, not through one shared Simbioza domain rule.

Proxy provider selection — The real proxy login offers AAI@EduHR, Facebook, and Google, explaining the three child profiles.

Default / AAI@EduHR

First default proxy test — Attributes collected before mapping, with values removed.

Default proxy mappings — Mappings for the default AAI source.

Operational default proxy profile

Default proxy tab after the successful repeated test.

Facebook

Operational Facebook child profile

Facebook child tab after successful mapping and test.

Google

Operational Google child profile

Google child tab after the successful repeated test.

11. CAS

A CAS profile needs the server base URL and its login, validation, and logout endpoints. If a private CA chain is used, provide a readable certificate path. Never disable TLS validation to work around an incorrect certificate configuration.

Initial CAS configuration — The CAS connection is prepared but mappings are not complete.

First CAS test — CAS authentication returns attributes; values are redacted.

CAS mappings — Stable subject, login, display name, and model fields mapped from the test.

Operational CAS profile

The repeated test confirms the CAS profile.

12. OIDC

OIDC uses a Client ID and secret, authorization, token, userinfo, and optionally end-session endpoints. Scope must include openid , followed only by required data such as profile and email . Public redirect base URL is the complete public base address of this installation, including a subdirectory where present.

Initial OIDC configuration — OIDC endpoints and public base URL before mapping.

First OIDC test — OIDC claims collected before mapping, with values removed.

OIDC mapping and domain — Subject, login, display name, user fields, and domain source mapped from actual claims.

Operational OIDC profile

The repeated test confirms OIDC and displays the green check.

Use a forced-login parameter such as max_age=0 only when the provider supports it and Force login is enabled. Otherwise leave it blank to preserve a valid existing SSO session.

13. OAuth2

OAuth2 uses authorization, token, and userinfo endpoints plus the scopes required for user data. If the provider supports OpenID Connect, prefer OIDC because it standardizes identity and token validation. OAuth2 logout may require a dedicated endpoint, redirect parameter name, or hint; enter only values required by the provider documentation.

Initial OAuth2 configuration — OAuth2 profile before attribute mapping.

First OAuth2 test — Userinfo attributes collected through a real login, with values removed.

OAuth2 mapping and domain — Mappings and domain restriction entered from the test result.

Operational OAuth2 profile

The repeated test confirms the OAuth2 profile.

14. Personal profile: security and access

Open Personal profile from the user menu. The main section shows identity and custom attributes. Security and access displays group membership, local password state, linked external logins, and API key requests.

Personal profile

Personal data and custom attributes in the English interface.

Security and access expanded — Groups, local login, linked providers, and API requests in one place.

Link an external account only while you control both identities. Remove unknown or unused links, but first confirm another login method remains available. Change local passwords through this secure form, never through e-mail or an administrator message.

15. Verification and security checklist

Keep at least one controlled administrator login available; store the break-glass account outside normal daily use.
For every SSO profile, verify exact callback URLs, TLS certificates, minimum scopes, and secret rotation.
Do not accept an active checkbox as proof. Require the green operational state after the repeated test.
The subject must be an immutable provider identifier. Login and e-mail may change and are not always suitable primary identifiers.
Test domain restrictions with both an allowed and a denied test account.
Regularly review administrators, group memberships, linked external logins, active API keys, and pending requests.
Never put passwords, client secrets, tokens, API secrets, or raw personal attributes in screenshots, documentation, tickets, or source control.
After testing, remove or deactivate documentation accounts and keys that are no longer required.

Once profiles have been tested, mappings confirmed, domain rules verified, and a safe administrator path preserved, the Simbioza authentication subsystem is ready for a controlled production rollout.

Comentarios

Aún no hay comentarios.

Debes iniciar sesión para añadir un comentario.

Login and users

Login and users

Contents

1. Login settings

Main switches

2. User attributes

Adding an attribute

3. Groups

4. Users and local accounts

Creating a local user

5. Local login and registration

6. Impersonation

7. API keys

Direct key issuance

User request and administrator approval

8. Common SSO workflow

Allowed domains

Public callback addresses

9. SAML

10. SAML proxy and child profiles

Default / AAI@EduHR

Facebook

Google

11. CAS

12. OIDC

13. OAuth2

14. Personal profile: security and access

15. Verification and security checklist

Comentarios