SnapOtter/apps/docs/sv/guide/users-roles.md

---
description: "Hantera användare, inbyggda och anpassade roller, behörigheter, API-nycklar, team, sessioner och granskningsloggen i SnapOtter."
i18n_source_hash: bea8955f3aff
i18n_provenance: human
i18n_output_hash: 9af24cfc9c89
i18n_hash_version: 2
---

# Användare, roller och behörigheter {#users-roles-permissions}

SnapOtter levereras med tre inbyggda roller, 17 detaljerade behörigheter och stöd för anpassade roller med valfri åtkomstkontroll per verktyg. Den här sidan täcker hela auktoriseringsmodellen, API-nyckelscoping, teamhantering och granskningsloggning.

::: tip Relaterade sidor
[OIDC / SSO](/sv/guide/oidc) | [SAML SSO](/sv/guide/saml) | [SCIM-provisionering](/sv/guide/scim) | [Säkerhet och härdning](/sv/guide/security)
:::

## Användare {#users}

### Skapa användare {#creating-users}

Administratörer kan skapa användare via administratörspanelen eller `POST /api/auth/register`-slutpunkten. Varje användare har ett användarnamn, en roll, en teamtilldelning och en valfri e-postadress.

### Standardadministratör {#default-admin}

Vid första uppstart skapar SnapOtter ett standardadministratörskonto. Inloggningsuppgifterna kommer från miljövariabler:

| Variabel | Standard | Beskrivning |
|---|---|---|
| `DEFAULT_USERNAME` | `admin` | Användarnamn för det initiala administratörskontot |
| `DEFAULT_PASSWORD` | `admin` | Lösenord för det initiala administratörskontot |

Standardadministratören måste byta lösenord vid första inloggningen.

### Autentiseringsleverantörer {#authentication-providers}

Användare kan autentisera sig via flera metoder:

- **Lokal** - användarnamn och lösenord lagrade i SnapOtter-databasen
- **OIDC** - valfri OpenID Connect-leverantör (se [OIDC / SSO](/sv/guide/oidc))
- **SAML** - SAML 2.0-identitetsleverantörer (se [SAML SSO](/sv/guide/saml))
- **SCIM** - automatiserad provisionering från en identitetsleverantör (se [SCIM-provisionering](/sv/guide/scim))

### Inaktivera autentisering {#disabling-authentication}

Ange `AUTH_ENABLED=false` för att inaktivera autentisering helt. I det här läget används en syntetisk anonym användare med rollen `admin` för alla förfrågningar. Ingen inloggning krävs.

::: warning 
Att inaktivera autentisering ger full administratörsåtkomst till alla som kan nå instansen. Använd endast detta i betrodda miljöer.
:::

## Inbyggda roller {#built-in-roles}

SnapOtter inkluderar tre inbyggda roller. De kan inte ändras eller raderas.

### Admin {#admin}

Alla 17 behörigheter. Full kontroll över instansen.

`tools:use` `files:own` `files:all` `apikeys:own` `apikeys:all` `pipelines:own` `pipelines:all` `settings:read` `settings:write` `users:manage` `teams:manage` `features:manage` `system:health` `audit:read` `compliance:manage` `webhooks:manage` `security:manage`

### Editor {#editor}

7 behörigheter. Kan använda alla verktyg och hantera alla filer och pipelines, men kan inte komma åt administratörsfunktioner.

`tools:use` `files:own` `files:all` `apikeys:own` `pipelines:own` `pipelines:all` `settings:read`

### User {#user}

5 behörigheter. Kan använda verktyg och hantera sina egna resurser.

`tools:use` `files:own` `apikeys:own` `pipelines:own` `settings:read`

## Behörighetsreferens {#permissions-reference}

| Behörighet | Beskrivning |
|---|---|
| `tools:use` | Använd valfritt bearbetningsverktyg |
| `files:own` | Visa och hantera egna filer |
| `files:all` | Visa och hantera alla användares filer |
| `apikeys:own` | Skapa och hantera egna API-nycklar |
| `apikeys:all` | Visa alla användares API-nycklar |
| `pipelines:own` | Skapa och hantera egna pipelines |
| `pipelines:all` | Visa och hantera alla användares pipelines |
| `settings:read` | Visa instansinställningar |
| `settings:write` | Ändra instansinställningar |
| `users:manage` | Skapa och hantera användarkonton inom aktörens behörighetsgräns |
| `teams:manage` | Skapa, uppdatera och radera team |
| `features:manage` | Installera och hantera AI-funktionsbuntar |
| `system:health` | Åtkomst till health- och readiness-slutpunkter |
| `audit:read` | Visa granskningsloggen och lista roller |
| `compliance:manage` | Hantera GDPR-livscykel- och efterlevnadsfunktioner; destruktiva användaroperationer förblir auktoritetsbundna |
| `webhooks:manage` | Konfigurera utgående webhooks |
| `security:manage` | Hantera säkerhetsinställningar (IP-tillåtelselista, SSO-tvingande) |

## Anpassade roller {#custom-roles}

Administratörer med behörigheten `security:manage` kan skapa anpassade roller via administratörspanelen eller roles-API:et. Att lista roller kräver `audit:read`.

### Skapa en anpassad roll {#creating-a-custom-role}

```bash
curl -X POST http://localhost:1349/api/v1/roles \
  -H "Authorization: Bearer si_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "reviewer",
    "description": "Can use tools and view all files",
    "permissions": ["tools:use", "files:own", "files:all", "settings:read"]
  }'
```

Rollnamn måste vara 2-30 tecken, gemena alfanumeriska med bindestreck och understreck.

### Delegerade administrationsgränser {#delegated-administration-boundaries}

Alla 17 behörigheter kan delegeras genom anpassade roller, men en administrativ behörighet gör inte den rollen likvärdig med den inbyggda `admin`-rollen. Användarmutationer godkända av `users:manage`, destruktiva operationer godkända av `compliance:manage` och anpassade rollhantering auktoriserad av `security:manage` begränsas av skådespelarens nuvarande auktoritet:

- Inbyggda roller följer `admin` > `editor` > `user`; anpassade roller är under inbyggda roller.
- Målets behörigheter måste innehållas av skådespelarens **effektiva** behörigheter. En scoped API-nyckel kan därför inte utöva behörigheter som utelämnas från dess scope.
- En målrolls verktygsåtkomst ska innehållas av aktörens egen verktygsåtkomst.
- Ett inaktiverat konto kontrolleras mot sin ursprungliga roll när den rollen registreras som `disabled:<original-role>`.
- Att ta bort en anpassad roll kräver också behörighet att tilldela den inbyggda `user` reserv; funktionshindrade medlemmar förblir inaktiverade som `disabled:user`.

Globala autentiseringsuppgifter och konfiguration är strängare: utfärdande eller återkallande av SCIM-token och import av instanskonfiguration kräver den inbyggda `admin`-rollen med fullständig effektiv administratörsbehörighet.

### Behörigheter på verktygsnivå {#tool-level-permissions}

Anpassade roller kan valfritt begränsa vilka verktyg användare får komma åt. Två lägen finns tillgängliga:

| Läge | Beteende | Licenskrav |
|---|---|---|
| `category` | Begränsa per modalitet (bild, video, ljud, dokument, fil) | Inget (gratis) |
| `tool` | Begränsa per enskilt verktygs-ID | Kräver enterprise-funktionen `per_tool_permissions` |

När läget `tool` är satt men enterprise-funktionen inte är tillgänglig, degraderar SnapOtter graciöst och tillåter åtkomst till alla verktyg.

```json
{
  "name": "image-only",
  "permissions": ["tools:use", "files:own"],
  "toolPermissions": {
    "mode": "category",
    "allowed": ["image"]
  }
}
```

### Radera en anpassad roll {#deleting-a-custom-role}

När en anpassad roll raderas tilldelas alla användare som tilldelats den automatiskt om till rollen `user`.

## Team {#teams}

Team grupperar användare för lagrings- och lagringshantering. Ett `Default`-team skapas vid första uppstart.

| Fält | Typ | Beskrivning |
|---|---|---|
| `name` | string | Unikt teamnamn (1-50 tecken) |
| `storageQuota` | number | Lagringsgräns per team i byte (fungerar utan enterprise) |
| `retentionHours` | number | Radera utdata automatiskt efter så här många timmar (kräver `team_retention_overrides`, enterprise) |
| `legalHold` | boolean | Förhindra automatisk radering av teammedlemmars filer (kräver `legal_hold`, enterprise) |

::: info 
Teamet `Default` kan inte raderas. Team som fortfarande har medlemmar kan inte raderas. Tilldela om medlemmar först.
:::

## API-nycklar {#api-keys}

Användare kan generera API-nycklar för programmatisk åtkomst. Varje nyckel använder prefixet `si_` och visas endast en gång vid skapandet.

### Scopade behörigheter {#scoped-permissions}

API-nycklar kan valfritt bära en `permissions`-array. När den är satt är de effektiva behörigheterna för en förfrågan **snittet** av användarens rollbehörigheter och nyckelns scopade behörigheter. Detta innebär att en API-nyckel aldrig kan eskalera bortom användarens egna behörigheter.

```bash
curl -X POST http://localhost:1349/api/v1/api-keys \
  -H "Authorization: Bearer si_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "CI pipeline key",
    "permissions": ["tools:use", "files:own"],
    "expiresAt": "2027-01-01T00:00:00Z"
  }'
```

### Utgång {#expiration}

Nycklar accepterar en valfri `expiresAt`-tidsstämpel. Utgångna nycklar avvisas vid autentiseringstillfället.

## Granskningslogg {#audit-log}

SnapOtter registrerar säkerhetsrelevanta händelser i en strukturerad granskningslogg som lagras i databastabellen `audit_log`.

### Visa granskningsloggen {#viewing-the-audit-log}

```
GET /api/v1/audit-log?page=1&limit=50&action=LOGIN_FAILED&from=2026-01-01T00:00:00Z&to=2026-12-31T23:59:59Z
```

Kräver behörigheten `audit:read`. Stöder paginering (`page`, `limit`) och filter (`action`, `ip`, `from`, `to`).

### Granskning av verktygsoperationer {#tool-operation-auditing}

::: warning 
`TOOL_EXECUTED`-händelser loggas **inte** som standard. De aktiveras via någon av två vägar:

1. Ange administratörsinställningen `auditToolOperations` till `true`.
2. Inneha en aktiv licens med funktionen `audit_export` (tillgänglig på både team- och enterprise-planer).

Utan någon av dessa registreras inte enskilda verktygskörningar i granskningsloggen.
:::

### Exportera {#exporting}

```
GET /api/v1/enterprise/audit/export?format=csv&from=2026-01-01T00:00:00Z
```

Kräver behörigheten `audit:read` och enterprise-funktionen `audit_export` (tillgänglig på både team- och enterprise-planer). Stöder CSV- och JSON-format, filtrerat efter `action`, `actorId`, `targetType`, `targetId`, `from` och `to`.

### Manipuleringsbeständig signering {#tamper-resistant-signing}

När det är aktiverat signeras varje granskningsloggpost med en HMAC härledd från `DATA_ENCRYPTION_KEY`. Detta kräver:

1. Att ange `DATA_ENCRYPTION_KEY` i din miljö.
2. Att aktivera administratörsinställningen `tamperResistantAudit`.
3. En enterprise-licens med funktionen `tamper_resistant_audit`.

### Lagring {#retention}

Ange `AUDIT_RETENTION_DAYS` för att automatiskt rensa gamla poster. Standarden är `0`, vilket innebär att poster behålls på obestämd tid.

### Händelsereferens {#event-reference}

| Händelse | Kategori |
|---|---|
| `LOGIN_SUCCESS`, `LOGIN_FAILED` | Autentisering |
| `OIDC_LOGIN_SUCCESS`, `OIDC_LOGIN_FAILED` | Autentisering |
| `SAML_LOGIN_SUCCESS`, `SAML_LOGIN_FAILED` | Autentisering |
| `LOGOUT` | Autentisering |
| `USER_CREATED`, `USER_UPDATED`, `USER_DELETED` | Användarhantering |
| `PASSWORD_CHANGED`, `PASSWORD_RESET` | Användarhantering |
| `MFA_ENROLLED`, `MFA_DISABLED`, `MFA_VERIFIED`, `MFA_VERIFY_FAILED` | MFA |
| `MFA_CHALLENGE_ISSUED`, `MFA_RECOVERY_USED`, `MFA_RESET` | MFA |
| `ROLE_CREATED`, `ROLE_UPDATED`, `ROLE_DELETED` | Roller |
| `API_KEY_CREATED`, `API_KEY_DELETED` | API-nycklar |
| `SETTINGS_UPDATED`, `IP_ALLOWLIST_UPDATED` | Inställningar |
| `FILE_UPLOADED`, `FILE_DELETED` | Filer |
| `TOOL_EXECUTED` | Verktyg (opt-in) |
| `SCIM_USER_PROVISIONED`, `SCIM_USER_UPDATED`, `SCIM_USER_DEPROVISIONED` | SCIM |
| `SCIM_GROUP_SYNCED` | SCIM |
| `LEGAL_HOLD_APPLIED`, `LEGAL_HOLD_RELEASED` | Efterlevnad |
| `GDPR_EXPORT_INITIATED`, `GDPR_USER_PURGED`, `GDPR_TEAM_PURGED` | Efterlevnad |
| `CONFIG_EXPORTED`, `CONFIG_IMPORTED` | Konfiguration |

## Sessionshantering {#session-management}

Sessioner är cookie-baserade, styrda av `SESSION_DURATION_HOURS` (standard: 168 timmar / 7 dagar).

### Rolländringar ogiltigförklarar sessioner {#role-changes-invalidate-sessions}

När en administratör ändrar en användares roll raderas alla den användarens aktiva sessioner. Användaren måste logga in igen för att plocka upp sina nya behörigheter.

### Säkerhetsspärrar {#safety-guards}

- **Skydd för sista administratören**: den sista kvarvarande administratören kan inte degraderas till en lägre roll. API:et returnerar ett fel om du försöker.
- **Förhindrande av självradering**: administratörer kan inte radera sitt eget konto via API:et.