n8n SSO (OIDC/SAML) i hardening: siguran pristup za timove i klijente

# Što ćete naučiti#

Ovaj vodič objašnjava praktične načine implementacije n8n SSO-a pomoću OIDC-a ili SAML-a, bilo nativno ili tako da n8n postavite iza identity-aware gatewaya. Također pokriva hardening za produkciju: RBAC i obrasce višekorisničkog/višetenantskog rada, upravljanje tajnama, mrežnu izolaciju i audit logiranje.

Ako self-hostate n8n za interni tim ili ga izlažete klijentima, SSO je tek prvi korak. Prava sigurnost dolazi iz slojevitih kontrola koje smanjuju blast radius kada je kompromitiran račun, token ili workflow.

Za osnovnu sigurnost Docker-a i deploymenta, pročitajte i: vodič za self-hostanje n8n-a uz Docker sigurnost. Za operativnu otpornost nakon puštanja u rad pogledajte: n8n obrada grešaka, ponovni pokušaji i alerting. Ako želite pomoć oko end-to-end implementacije, pogledajte Samioda automation services.

# Threat model: zašto n8n SSO nije dovoljan#

n8n je moćan jer se povezuje sa svime. Ta moć je ujedno i rizik: jedna kompromitirana korisnička sesija može izložiti credse, izmijeniti workflowe ili pokrenuti destruktivne akcije nizvodno.

Česti scenariji rizika koje viđamo u produkciji:

• Vanjski suradnik zadrži pristup dulje nego što je planirano jer je offboarding ručan.
• Procuri session cookie i zaobiđe MFA jer se MFA dogodio samo pri inicijalnom logiranju.
• Workflow koristi dugovječni API token spremljen u običnim environment varijablama.
• n8n UI je dostupan s javnog interneta uz samo password auth.
• Ne postoji audit trag koji bi odgovorio tko je promijenio workflow i kada.

SSO pomaže s centraliziranim identitetom, MFA-om i offboardingom. Hardening otežava kompromitaciju i ograničava štetu kad se ona dogodi.

🎯 Ključna poruka: Tretirajte n8n kao administratorsku konzolu za vaše poslovne sustave. SSO je brava na vratima, hardening je alarmni sustav, kamere i sef.

# Arhitekturne opcije za n8n SSO#

Postoje dva praktična načina implementacije n8n SSO-a:

1. 1
   Nativni SSO u n8n-u gdje je dostupan i prikladan za vaše izdanje i zahtjeve.
2. 2
   SSO na rubu (edge) s identity-aware gatewayem ili reverse proxyem koji provodi OIDC ili SAML prije nego što bilo koji zahtjev dođe do n8n-a.

Odabir ovisi o licenciranju, broju tenanata koje opslužujete i koliko kontrole trebate nad pravilima sesije, stanjem uređaja (device posture) i mrežnim pristupom.

Opcija A: Nativni SSO unutar n8n-a#

Nativni SSO je najčišće korisničko iskustvo: korisnici se prijavljuju preko IdP-a, n8n prima identity claimove, a vi možete izravnije mapirati korisnike i uloge.

Kad je nativni SSO dostupan, obično podržava OIDC (a u nekim postavkama i SAML). IdP može biti:

• Azure Entra ID
• Okta
• Keycloak
• Google Workspace
• Auth0

Praktične prednosti:

• Manje proxy “ljepila” za održavanje
• Bolja kontrola nad provisioningom korisnika i mapiranjem uloga, ovisno o mogućnostima
• Urednija podrška za logout tokove i lifecycle korisnika

Ograničenja:

• I dalje trebate edge sigurnosne kontrole za produkciju, posebno ako je n8n dostupan s interneta.
• SSO automatski ne rješava autorizaciju, tenancy, tajne ni audit logiranje.

Opcija B: SSO na rubu s gatewayem ili reverse proxyem#

Ako nativni SSO nije dostupan ili trebate jaču kontrolu pristupa, stavite n8n iza identity-aware gatewaya i tamo provodite autentikaciju i autorizaciju.

Uobičajeni obrasci:

• Nginx ili Traefik s OIDC middlewareom
• oauth2-proxy s OIDC providerom
• Cloudflare Access, Google IAP, Azure AD Application Proxy, Okta Access Gateway
• Zero-trust gateway koji može provoditi device posture, IP restrikcije i step-up MFA

Praktične prednosti:

• Brza implementacija uz postojeći enterprise IdP
• Snažne policy kontrole: IP allowliste, geo restrikcije, usklađenost uređaja, MFA po aplikaciji
• Možete izbjeći izravno izlaganje n8n-a javnom internetu

Ograničenja:

• Mapiranje IdP grupa u n8n uloge je teže osim ako n8n podržava čitanje headera ili tokena za autorizaciju.
• Morate pažljivo spriječiti “bypass” pristup n8n-u mimo gatewaya.

Brza usporedna tablica#

# OIDC vs SAML za n8n SSO#

OIDC je moderni default za web aplikacije. SAML je i dalje čest u enterprise okruženjima, posebno gdje su postojeći IdP-ovi i politike “SAML-first”.

Koristite ovo pravilo:

• Odaberite OIDC osim ako imate strogi zahtjev za SAML.
• Odaberite SAML kada klijent to nalaže ili je vaš IdP setup primarno SAML.

Osnove OIDC-a koje trebate konfigurirati#

Za OIDC su važni pojmovi:

• Authorization Code flow s PKCE kad je moguće
• ID token za identitet, access token za API pozive
• Kratko trajanje sesija i politika refresh tokena pod kontrolom IdP-a
• Claimovi za email, ime i pripadnost grupama

Preporučeni defaulti:

• Zahtijevajte MFA na IdP-u za sav pristup n8n-u
• Postavite trajanje sesije na 8 do 12 sati za zaposlenike, kraće za vanjske suradnike
• Koristite conditional access: blokirajte rizične države, zahtijevajte usklađene uređaje za admine

Osnove SAML-a koje trebate konfigurirati#

Za SAML fokusirajte se na:

• Potpisane assertions i potpisane responseove
• Kratku valjanost assertiona, tipično 5 do 10 minuta
• Strogu ACS URL validaciju i audience restriction
• Provedite MFA na IdP-u

SAML može biti siguran, ali pogrešne konfiguracije su česte. Auditirajte IdP postavke tako da druga osoba pregleda konfiguraciju.

⚠️ Upozorenje: Nemojte se oslanjati na “SSO enabled” kao dokaz sigurnosti. Najčešći failure je ostaviti izravan put do n8n-a koji zaobilazi SSO — obično kroz otvoren port, alternativni hostname ili interni load balancer.

# Referentna implementacija: Edge OIDC s oauth2-proxy#

Ovaj obrazac je praktičan kada želite snažnu kontrolu pristupa bez duboke integracije aplikacije.

Tok na visokoj razini:

1. 1
   Korisnik otvara n8n.example.com
2. 2
   Reverse proxy prosljeđuje prema oauth2-proxy
3. 3
   oauth2-proxy preusmjerava na IdP za OIDC login
4. 4
   Nakon uspjeha, oauth2-proxy prosljeđuje zahtjev prema n8n-u

Minimalni docker-compose primjer#

Uzmite ovo kao polazišnu točku i prilagodite svom okruženju. Pokrenite n8n na privatnoj mreži i izložite samo proxy.

version: "3.8"
services:
  n8n:
    image: n8nio/n8n:latest
    environment:
      - N8N_HOST=n8n.example.com
      - N8N_PROTOCOL=https
      - N8N_PORT=5678
      - N8N_ENCRYPTION_KEY=change-me-32-plus-chars
    networks:
      - internal
 
  oauth2-proxy:
    image: quay.io/oauth2-proxy/oauth2-proxy:v7.7.1
    command:
      - --provider=oidc
      - --oidc-issuer-url=https://idp.example.com/realms/main
      - --redirect-url=https://n8n.example.com/oauth2/callback
      - --email-domain=*
      - --upstream=http://n8n:5678
      - --cookie-secure=true
      - --cookie-samesite=lax
      - --set-authorization-header=true
      - --pass-user-headers=true
    environment:
      - OAUTH2_PROXY_CLIENT_ID=n8n
      - OAUTH2_PROXY_CLIENT_SECRET=replace-me
      - OAUTH2_PROXY_COOKIE_SECRET=replace-with-32-bytes-base64
    networks:
      - internal
      - public
 
  nginx:
    image: nginx:1.27
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
    ports:
      - "443:443"
    networks:
      - public
      - internal
 
networks:
  internal:
    internal: true
  public:
    external: false

Minimalni primjer Nginx reverse proxya#

Ovo pretpostavlja da oauth2-proxy radi auth i da n8n nije izravno dostupan.

server {
  listen 443 ssl;
  server_name n8n.example.com;
 
  location / {
    proxy_pass http://oauth2-proxy:4180;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

Što dodati u produkciji:

• TLS certifikate kroz vaš standardni ACME proces
• Stroge security headere na rubu
• Rate limiting za smanjenje brute force napada i “scan noisea”

💡 Savjet: Dodajte eksplicitnu network politiku tako da samo reverse proxy može razgovarati s n8n-om. U Kubernetesu je to NetworkPolicy. U Dockeru koristite internal network i nemojte publishati port n8n containera.

# RBAC i izolacija tenanata za timove i klijente#

SSO odgovara na pitanje “tko si ti”. RBAC odgovara na pitanje “što smiješ raditi”.

U praksi trebate definirati uloge oko n8n operacija:

• Kreatori workflowa
• Operateri koji mogu pokretati ili onemogućavati workflowe
• Auditori s read-only pristupom
• Administratori instance

Predloženi RBAC model#

Ako vaš n8n setup podržava projekte ili workspaces, provodite razdvajanje po klijentu ili odjelu. Ako ne, tretirajte svakog klijenta kao zasebnu n8n instancu kako biste smanjili rizik curenja podataka.

Deployments za više klijenata: kada odvajati instance#

Zasebne instance se preporučuju kada:

• Klijenti traže odvojene SSO tenante ili IdP-ove
• Workflowi obrađuju klijentske PII ili financijske podatke
• Morate omogućiti klijentski specifične audit exporte
• Ugovorni uvjeti zabranjuju pristup podacima između klijenata

Tipičan obrazac je jedna n8n instanca po klijentu, deployana iz istog infrastrukturnog templata uz per-klijent tajne i odredišta za logiranje.

# Upravljanje tajnama: prestanite tretirati credse kao konfiguraciju#

n8n workflowi često sadrže API credse koji su praktično “ključevi kraljevstva”. Spremanje u obične environment varijable ili razbacivanje po workflow nodeovima ne skaluje.

Principi koji prolaze audit#

• Šifrirajte tajne u mirovanju i rotirajte ih po rasporedu
• Ograničite tko može kreirati ili uređivati credse u n8n-u
• Koristite odvojene credse po okruženju i po klijentu
• Preferirajte short-lived tokene kad je moguće

Praktične opcije setupa#

Minimalni hardening korak:

• Postavite N8N_ENCRYPTION_KEY na snažnu, stabilnu vrijednost i spremite je u siguran secret store.
• Ne rotirajte ga olako. Rotacija bez plana migracije može učiniti postojeće šifrirane credse nečitljivima.

Primjer: generiranje jakih tajni#

# 32 bytes base64 za cookie secret ili random ključeve
openssl rand -base64 32
 
# 64 hex znakova za duge encryption ključeve
openssl rand -hex 32

# Mrežna izolacija i kontrola izloženosti#

Ako je vaš n8n UI javan, morate pretpostaviti da će biti skeniran. Shodan i slični alati indeksiraju izložene servise brzo, često unutar nekoliko dana.

Ciljevi hardeninga:

• Učinite n8n dostupnim samo kroz vaš gateway
• Ograničite outbound pristup samo na potrebna odredišta
• Odvojite bazu i Redis od javnih mreža

Preporučeni mrežni raspored#

• Public: samo load balancer ili reverse proxy
• Private: n8n app, baza, queue workeri, Redis
• Admin: ograničen pristup za SSH ili kubectl, idealno preko VPN-a ili zero-trusta

Kontrola outbound egressa je važna za workflowe#

Workflowi mogu zvati proizvoljne URL-ove. Ako napadač dobije edit pristup, može eksfiltrirati podatke na webhook endpoint.

Ublažavanja:

• Egress allowliste za produkcijska okruženja
• DNS filtering gdje je moguće
• Odvojena okruženja za development i production workflowe

ℹ️ Napomena: Egress kontrola je jedna od sigurnosnih mjera s najvećim ROI-jem za automation platforme. Ograničava eksfiltraciju podataka čak i kad je račun kompromitiran.

Za dublji baseline hardeninga deploymenta pratite: vodič za self-hostanje n8n-a uz Docker sigurnost.

# Audit logiranje i praćenje promjena koje stvarno pomaže#

Morate brzo moći odgovoriti na ova pitanja:

• Tko se prijavio i odakle
• Tko je promijenio workflow, credential ili webhook endpoint
• Koje su egzekucije dotaknule osjetljive sustave
• Što je palo i koliko često

Što logirati#

Minimalno:

• Auth događaje na vašem IdP-u ili gatewayu
• Access logove na reverse proxyu
• n8n execution logove, uključujući naziv workflowa i status egzekucije
• Administrativne akcije: promjene korisnika, ažuriranja credentiala, uređivanja workflowa

Gdje slati logove#

Centralizirajte logove u jedno od:

• ELK ili OpenSearch
• Datadog
• Grafana Loki
• Cloud-native logging poput CloudWatcha ili Stackdrivera

Alertovi koji smanjuju mean time to detect#

Postavite alertove na:

• Višestruke neuspješne prijave unutar 5 minuta
• Prvu prijavu iz nove države za privilegirane uloge
• Nagli rast broja egzekucija workflowa ili error ratea
• Promjene workflowa izvan radnog vremena
• Bilo kakve promjene na credential objektima

Operativno, uparite ovo s robusnim handlingom grešaka i notifikacijama. Siguran sustav koji tiho pada i dalje je poslovni rizik. Koristite: n8n obrada grešaka, ponovni pokušaji i alerting.

# Kontrolni popis hardeninga za produkciju za n8n SSO deployments#

Koristite ovaj checklist za svako okruženje. Poanta je dosljednost, ne savršenstvo prvog dana.

Identitet i pristup#

Autorizacija i RBAC#

Tajne i zaštita podataka#

Mreža i sigurnost platforme#

Monitoring i audit#

# Ključne poruke#

• Implementirajte n8n SSO s OIDC-om ili SAML-om nativno ili preko identity-aware gatewaya i osigurajte da ne postoji bypass put do n8n-a.
• Koristite RBAC i izolaciju tenanata kako biste minimizirali blast radius, te preferirajte odvojene instance za klijentska okruženja koja obrađuju osjetljive podatke.
• Tretirajte credse kao produkcijske tajne: zaštitite N8N_ENCRYPTION_KEY, ograničite uređivanje credentiala i koristite vault ili secret manager gdje je potrebno.
• Zaključajte mreže: izložite samo proxy, izolirajte servise na privatnim mrežama i ograničite outbound egress da spriječite eksfiltraciju podataka.
• Centralizirajte audit logove i kreirajte akcijske alertove za rizične prijave, promjene workflowa i skokove u egzekucijama.

# Zaključak#

SSO je baseline, ne cilj. Siguran n8n deployment kombinira SSO, RBAC, upravljanje tajnama, mrežnu izolaciju i audit logiranje u jedan koherentan, ponovljiv predložak koji možete primijeniti kroz okruženja i klijente.

Ako želite da Samioda dizajnira i implementira hardened n8n platformu sa SSO-om, izolacijom tenanata i monitoringom produkcijske razine, kontaktirajte nas putem naših automation usluga i pomoći ćemo vam to isporučiti sigurno.