# 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.
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.
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.
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",
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.
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
### 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`.
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.
