Úvod

O TeskaLabs SeaCat Auth¶

TeskaLabs SeaCat Auth je mikroslužba, která poskytuje autentizaci, autorizaci, správu identity, správu relací, a další funkce. Je navržena tak, aby sloužila jako řešení pro řízení přístupu a/nebo pro jednotné přihlašování (SSO) pro další mikroslužby a aplikace.

Seacat Auth implementuje OAuth 2.0, široce podporovaný autorizační protokol, což zajišťuje jeho kompatibilitu s mnoha aplikacemi. Seacat Auth také poskytuje nástroje, které usnadňují integraci aplikací, které nepoužívají OAuth, do ekosystému OAuth.

Seacat Auth také funguje jako poskytovatel OpenID Connect, nabízející užitečné funkce, jako je jednotné přihlašování (SSO) a autentizaci pomocí JSON webových tokenů (JWT).

TeskaLabs SeaCat Auth je projekt s otevřeným zdrojovým kódem.

Zdrojový kód je k dispozici na GitHub.
SeaCat Auth je postaven na ASAB frameworku od TeskaLabs.

Pokud chcete nainstalovat, nakonfigurovat nebo integrovat SeaCat Auth, nebo spravovat přístup uživatelů, navštivte Administrativní příručku.

Pokud potřebujete pomoc se svým uživatelským účtem v SeaCat Auth, navštivte Uživatelskou příručku.

Uživatelské rozhraní SeaCat Auth¶

SeaCat Auth zahrnuje intuitivní, kompletní uživatelské rozhraní.

Přihlašovací obrazovka

Obrazovky pro řízení přístupu

Obrazovka nastavení uživatelského účtu

Vyrobeno s v TeskaLabs

SeaCat Auth je produktem TeskaLabs.

Hlavní funkce TeskaLabs SeaCat Auth¶

Autentizace¶

Dvoufaktorová autentizace (2FA) / Vícefaktorová autentizace (MFA)
Podporované faktory:
- Heslo
- Časově založené jednorázové heslo (TOTP)
- SMS kód
- FIDO2 / WebAuthn
- YubiKey
- Idem Key
- Android telefon
- Apple TouchID / FaceID
- Další autentifikátory / klíče
- Podsíť (ROADMAP 🗺️)
- Hlavička požadavku (X-Header)
Autentizace mezi stroji
- API klíče (ROADMAP 🗺️)
Šifrování od konce k konci v přihlašovacích relacích

Autorizace¶

Kontrola přístupu na základě rolí (RBAC)
- Role
- Zdroje
Politiky (ROADMAP 🗺️)
Kontrola přístupu na základě atributů (ABAC) (ROADMAP 🗺️)

Správa identit¶

Federace uživatelských identit (aka ověření)
Dostupní poskytovatelé identit:
- LDAP a Microsoft Active Directory
- Google
- MongoDB
- Soubor (htpasswd)
- Slovník v paměti
- ElasticSearch
- MySQL
- Vlastní poskytovatel identit (třída Python 3)

Obecné¶

Víceuživatelský režim včetně správy nájemců pro další služby a aplikace
Správa relací
Jednotné přihlášení
OpenId Connect / OAuth2
Backend pro introspekci autorizace/autentizace pro NGINX
Interceptor autorizace/autentizace pro aplikace třetích stran (aka "Batman")
Kibana & ElasticSearch
Grafana
Docker registry / NGINX (ROADMAP 🗺️)
HTTP Základní autentizace
Mód provisioning
Strukturované logování přes Syslog 5424
Auditní stopa
Telemetrie
InfluxDB
Prometheus / OpenMetrics

Uživatelské rozhraní¶

Plná lokalizace / internacionalizace

Webové uživatelské rozhraní pro uživatele ¶

Přihlášení
Registrace nových uživatelů
Portál pro vlastní správu

Webové uživatelské rozhraní pro administrátory ¶

Správa ověření
Správa nájemců
Správa RBAC
Správa relací

Administrační manuál

Příručka pro správu¶

Co je v Příručce pro správu?

Použijte Příručku pro správu, pokud chcete:

Nainstalovat SeaCat Auth a integrovat ho do jiné aplikace jako komponentu pro autentizaci a autorizaci
Konfigurovat SeaCat Auth
Spravovat řízení přístupu (přihlašovací údaje, nájemci, role atd.) v aplikaci SeaCat Auth (webové UI)
Zjistit více o SeaCat Auth

Řízení přístupů

Řízení přístupu¶

Můžete spravovat přihlašovací údaje (uživatele), zdroje, role, nájemce, relace a klienty v uživatelském rozhraní SeaCat Auth. Pro více informací o těchto pojmech a jejich funkcích navštivte Key terms.

Klíčové pojmy¶

Přihlašovací údaje¶

Přihlašovací údaje jsou uživatelé. Přihlašovací údaje jsou reprezentovány uživatelskými jmény a mohou zahrnovat e-mailovou adresu a telefonní číslo jako doplňkové informace. Můžete přiřadit nájemce a role k přihlašovacím údajům, stejně jako spravovat relace přihlašovacích údajů.

Nájemce¶

Nájemce je jedna entita se svým vlastním souborem dat. Každý nájemce je izolovaný prostor, jako nájemci v bytovém domě nebo bloku bytů. Data každého nájemce jsou zcela oddělena od dat všech ostatních nájemců v uživatelském rozhraní.

Jeden nájemce může být přístupný více uživatelům a uživatelé mohou mít přístup k více nájemcům. Můžete řídit, kteří uživatelé mají přístup k kterým nájemcům, přiřazením přihlašovacích údajů k nájemcům nebo naopak.

Zdroje¶

Zdroje jsou nejzákladnější jednotkou autorizace. Jsou to jednotlivá a specifická oprávnění k přístupu.

Příklady:

Oprávnění k přístupu na konkrétní stránku
Oprávnění k odstranění konkrétního typu položky
Oprávnění k provádění změn v skupině souborů

Role¶

Role je kontejner pro zdroje. Protože zdroje jsou jednotlivá oprávnění, role je soubor oprávnění. Můžete přidat libovolný počet a kombinaci zdrojů do role.

Klient¶

Klienti jsou další aplikace a služby, které přistupují k aplikaci.

Relace¶

Relace je aktivní období přihlášení.

Přihlašovací údaje¶

Přihlašovací údaje jsou uživatelé. Přihlašovací údaje jsou reprezentovány uživatelskými jmény a mohou zahrnovat e-mailovou adresu a telefonní číslo jako doplňkové informace. Můžete přiřadit nájemce a role k přihlašovacím údajům, stejně jako spravovat relace přihlašovacích údajů.

Stránka přihlašovacích údajů¶

Na obrazovce Přihlašovací údaje můžete vidět informace pro každý soubor přihlašovacích údajů:

Jméno: Uživatelské jméno, se kterým se uživatel přihlašuje
Poskytovatel: Typ přihlašovacích údajů, který může být ext (člověk) nebo stroj.
Nájemci: Kteří nájemci jsou přiřazeni k přihlašovacím údajům
Role: Které role jsou přiřazeny k přihlašovacím údajům

Vytvoření nových přihlašovacích údajů¶

Chcete-li vytvořit nového uživatele, klikněte na Vytvořit nové přihlašovací údaje na stránce Přihlašovací údaje.
Vyberte poskytovatele z rozbalovacího seznamu: člověk nebo stroj.
Zadejte uživatelské jméno.
Zadejte e-mailovou adresu a telefonní číslo (volitelné).
Chcete-li uživateli zaslat pokyny k nastavení jeho hesla, vyberte Odeslat pokyny k nastavení hesla.
Klikněte na Vytvořit přihlašovací údaje.

Hromadné akce¶

Hromadné akce vám umožňují přiřadit více rolí a nájemců více uživatelům současně. Chcete-li přejít do režimu hromadných akcí, klikněte na Hromadné akce v horní části obrazovky.

Nájemci¶

Nájemce je jedna entita se svým vlastním souborem dat. Každý nájemce je izolovaný prostor, jako nájemci v bytovém domě nebo panelovém domě. Data každého nájemce jsou zcela oddělena od dat všech ostatních nájemců v uživatelském rozhraní. Jeden nájemce může být přístupný více uživatelům a uživatelé mohou mít přístup k více nájemcům.

Můžete řídit, kteří uživatelé mohou přistupovat k jakým nájemcům, přiřazením přihlašovacích údajů k nájemcům nebo naopak.

Na obrazovce Nájemci můžete vidět:

Jména nájemců
Datum, kdy byl nájemce vytvořen

Vytvoření nájemce¶

Klikněte na Nový nájemce na stránce Nájemci.
Zadejte jméno nájemce.
Klikněte na Vytvořit nájemce.

Přidání přihlašovacích údajů k nájemci¶

Na stránce Nájemci klikněte na nájemce.
Klikněte na Přiřadit přihlašovací údaje a vyberte přihlašovací údaje z rozbalovacího seznamu.

Zdroje¶

Zdroje jsou nejzákladnější jednotkou autorizace. Jsou to jednotlivá a specifická oprávnění k přístupu.

Jak používat zdroje

Chcete-li udělit přístup k zdrojům, seskupte zdroje do role a poté přiřaďte roli k přihlašovacím údajům. Jinými slovy, nemůžete přiřadit zdroje přímo k přihlašovacím údajům; přihlašovací údaje mohou mít přístup k zdroji pouze prostřednictvím role.
Můžete přiřadit stejný zdroj několika rolím.
Role může mít více zdrojů. Role může být přiřazena několika přihlašovacím údajům.

Na obrazovce Zdroje můžete vidět:

ID zdroje: Název zdroje
Popis: Uživatel vytvořený a pro člověka čitelný popis toho, jaké oprávnění zdroj uděluje
Vytvořeno: Datum a čas, kdy byl zdroj vytvořen

Vytvoření zdroje¶

Na obrazovce Zdroje klikněte na Nový zdroj.
Pojmenujte zdroj, zadejte krátký popis a klikněte na Vytvořit zdroj.

Smazané zdroje¶

Chcete-li zobrazit smazané zdroje, klikněte na Smazané zdroje na obrazovce Zdroje.
Chcete-li obnovit zdroj (znovu ho aktivovat), klikněte na kruhovou šipku na konci řádku zdroje.

Zahrnuté zdroje¶

Následující zdroje jsou automaticky k dispozici v instalaci SeaCat Auth:

seacat:tenant:create: Uděluje právo vytvořit nového nájemce
seacat:role:assign: Přiřadit a odebrat role nájemce.
seacat:role:edit: Vytvářet, upravovat a mazat role nájemce. To neumožňuje nositeli přiřadit zdroje systému SeaCat.
seacat:role:access: Hledat role nájemce, zobrazit podrobnosti o roli a seznam nositelů rolí.
seacat:tenant:assign: Přiřadit a odebrat členy nájemce, pozvat nové uživatele k nájemci.
seacat:tenant:delete: Smazat nájemce.
seacat:tenant:edit: Upravit údaje o nájemci.
seacat:tenant:access: Seznam nájemců, zobrazit podrobnosti o nájemci a vidět členy nájemce.
seacat:client:edit: Upravit a smazat klienty.
seacat:client:access: Seznam klientů a zobrazit podrobnosti o klientech.
seacat:resource:edit: Upravit a smazat zdroje.
seacat:resource:access: Seznam zdrojů a zobrazit podrobnosti o zdrojích.
seacat:session:terminate: Ukončit relace.
seacat:session:access: Seznam relací a zobrazit podrobnosti o relacích.
seacat:credentials:edit: Upravit a pozastavit přihlašovací údaje.
seacat:credentials:access: Seznam přihlašovacích údajů a zobrazit podrobnosti o přihlašovacích údajích.

Role¶

Role je kontejner pro zdroje. Protože zdroje jsou jednotlivá oprávnění, role je soubor oprávnění. Můžete přidat libovolný počet a kombinaci zdrojů do role.

Jak používat role

Přidejte zdroje do role, abyste vytvořili soubor oprávnění
Přiřaďte role k přihlašovacím údajům (uživatelům), abyste uživatelům udělili tento soubor oprávnění
Role může mít více zdrojů
Stejný zdroj může být přítomen v několika rolích
Více přihlašovacích údajů může mít přiřazenou stejnou roli

Vytvoření role¶

Na stránce Role klikněte na Vytvořit roli.
Pojmenujte roli a vyberte nebo zrušte výběr Globální role.
Klikněte na Vytvořit roli.

Úprava rolí¶

Na stránce Role klikněte na roli, kterou chcete upravit.
Chcete-li upravit zdroje v roli, klikněte na Upravit v sekci Zdroje.
Chcete-li přiřadit roli k přihlašovacím údajům, klikněte na Přiřadit přihlašovací údaje a vyberte uživatele ze seznamu rozbalovacího menu.

Klienti¶

Klient je entita, která využívá autentizační a autorizační služby poskytované autorizačním serverem. Tato autorizace umožňuje klientovi přístup k chráněným zdrojům. Jinými slovy, klienti jsou další aplikace připojené k SeaCat Auth.

Podívejte se na referenční stránku Clients pro více technických podrobností.

Stránka klientů¶

Na stránce klientů můžete vidět:

Název klienta: Název klienta
ID klienta: Needitovatelné, unikátní, automaticky generované ID. (Více zde.)
Vytvořeno: Datum a čas vytvoření
Klientská URI: URL domovské stránky klienta

Relace¶

Relace je aktivní období přihlášení.

Ukončení relace¶

Máte několik možností, jak ukončit relace. Ukončení relace odhlásí uživatele.

Na stránce Relace:

Klikněte na červenou ikonu na řádku relace
Klikněte na název relace, poté klikněte na Ukončit relaci
Chcete-li ukončit všechny relace (odhlásit všechny uživatele), klikněte na Ukončit všechny na stránce Relace

Instalace

Rychlý start¶

Toto je příručka pro rychlý start pro TeskaLabs SeaCat Auth, která vás rychle uvede do problematiky.

Požadavky¶

Následující seznam obsahuje všechny požadavky pro úspěšné nasazení SeaCat Auth:

Docker
docker-compose
Neomezené připojení k internetu

Poznámka: Tato příručka je určena pro Windows (s použitím WSL2 a Docker), Mac OS (s použitím Docker Desktop) a Linux.

Krok 1: Vytvoření nasazovacího adresáře¶

V této příručce předpokládáme, že SeaCat Auth bude nasazen do /opt/site-auth.

Poznámka: Nasazovací adresář také nazýváme "web".

Struktura nasazovacího adresáře:

/opt/site-auth
  seacatauth-conf/
    seacatauth.conf
  mongodb-data/
  nginx-conf/
    nginx.conf
  nginx-root/
    index.html
  seacat-auth-webui/
  seacat-webui/
  log/
  docker-compose.yml

Repozitář SeaCat Auth na GitHubu obsahuje šablonu nasazovacího adresáře v adresáři ./doc/docker. Tuto šablonu nasazovacího adresáře lze také stáhnout zde.

Krok 2: Úprava konfigurace SeaCat Auth¶

Nastavte SMTP server.
Nastavení uživatelského účtu v SeaCat Auth vyžaduje odeslání e-mailu s aktivačním odkazem.

Krok 3: Instalace webových uživatelských rozhraní¶

Nainstalujte SeaCat Auth Web UI do ./seacat-auth-webui/ z https://asabwebui.z16.web.core.windows.net/seacat-auth/master/seacat-auth-webui.tar.lzma
Nainstalujte SeaCat Web UI do ./seacat-webui/ z https://asabwebui.z16.web.core.windows.net/seacat-auth/master/seacat-auth-webui.tar.lzma

Krok 4: Spuštění SeaCat Auth¶

Proveďte docker-compose up -d v adresáři /opt/site-auth.

Nyní SeaCat Auth běží v takzvaném režimu provisioning. Můžete použít SeaCat Web UI k dokončení nastavení vytvořením uživatelů atd. Pro tento krok, prosím pokračujte k nastavení SeaCat Auth v režimu provisioning.

Další kroky¶

Nasazení SeaCat Auth s vlastním hostname a HTTPS¶

Tato část příručky předpokládá, že váš server má správné veřejné doménové jméno.

Získejte SSL certifikát (např. pomocí Let's Encrypt a ACME).
Šablona konfigurace Nginx pro HTTPS se nachází v nginx-conf/nginx-https.conf.
Zkontrolujte, že cesty k SSL klíči a certifikátu v konfiguraci Nginx ukazují na místa, kde se nachází váš SSL certifikát a klíč.
V seacatauth-conf/seacatauth.conf:
Změňte hostname public_api_base_url a auth_webui_base_url.
Volitelně můžete také nastavit [seacatauth:cookie] domain, aby odpovídalo vašemu hostname.
Spusťte služby pomocí docker-compose up -d a pokračujte k nastavení SeaCat Auth v režimu provisioning.

Vlastní hostname na localhostu¶

Pro spuštění SeaCat Auth lokálně s vlastním hostname jednoduše přidejte hostname do /etc/hosts na vašem stroji, například

127.0.0.1  auth.test.loc

Protože nemůžete získat důvěryhodný SSL certifikát prostřednictvím ACME challenge pro interní hostname, musíte vygenerovat self-signed SSL certifikát:

openssl req -x509 -newkey rsa:4096 -keyout nginx-conf/key.pem -out nginx-conf/cert.pem -days 365 -nodes

Poznámka, že self-signed certifikáty nejsou důvěryhodné a na většině zařízení vyvolávají varování. Měly by být používány pouze pro vývojové účely v místních prostředích.

Režim provisioning¶

Dále pokračujte k režimu provisioning.

Mód poskytování¶

Když nainstalujete novou čistou instanci SeaCat Auth, neexistuje žádný konvenční způsob přihlášení, protože neexistují žádné uživatelské účty. Mód poskytování vytváří dočasné superuživatelské přihlašovací údaje, které lze použít k přihlášení a vytvoření běžného účtu pro sebe.

Spuštění SeaCat Auth v módu poskytování¶

Existují dva způsoby, jak aktivovat mód poskytování: - První možností je spustit seacatauth.py s argumentem --provisioning

python3 seacatauth.py -c /conf/seacatauth.conf --provisioning

Druhou možností je nastavit proměnnou prostředí SEACAT_AUTH_PROVISIONING na 1 nebo TRUE, exportovat ji a spustit SeaCat Auth. To lze snadno provést v docker-compose.yml:

seacat-auth-svc:
  ...
  environment:
    - SEACAT_AUTH_PROVISIONING=1

Přihlášení¶

Když spustíte mód poskytování, následující text bude vytištěn do logu SeaCat Auth:

SeaCat Auth běží v módu poskytování.

Použijte následující přihlašovací údaje pro přihlášení:

    USERNAME:   superuser
    PASSWORD:   **************

Použijte tyto přihlašovací údaje k přihlášení.

V uživatelském rozhraní WebUI uvidíte, že byl vytvořen poskytovací nájemce a poskytovací role. Tyto jsou dočasné a budou automaticky smazány, když bude aplikace zastavena.

POZNÁMKA Přihlašovací údaje superuživatele jsou smazány a znovu vytvořeny s novým heslem pokaždé, když je aplikace restartována.

Nastavení prostředí¶

Vytvořte nájemce. Každý uživatel musí mít přiřazen alespoň jednoho nájemce, aby mohl vstoupit do SeaCat WebUI.
Vytvořte uživatelský účet. Heslo bude odesláno prostřednictvím e-mailu nebo SMS, v závislosti na tom, jaké kontaktní informace vyplníte. Ujistěte se, že je váš SMTP nebo SMS poskytovatel správně nastaven v konfiguraci SeaCat Auth.
Otevřete detail uživatele a přiřaďte nájemce, kterého jste vytvořili dříve, a role */superuser.
Nyní se můžete odhlásit z relace superuživatele poskytování.
Zkontrolujte, zda jste obdrželi odkaz na resetování hesla pro vaše nové přihlašovací údaje. Pokračujte k resetování hesla a poté se přihlaste!

POZNÁMKA Nepřiřazujte poskytovací nájemce nebo roli superuživatele poskytování žádnému jinému uživateli, protože je dočasná a bude smazána, když bude aplikace restartována a poskytování skončí.

Zakázání módu poskytování¶

Chcete-li zakázat mód poskytování, jednoduše spusťte aplikaci bez příznaku --provisioning a s SEACAT_AUTH_PROVISIONING nastaveným na 0 nebo úplně nezadaným (smazaným z docker-compose.yml).

Konfigurace

Minimální požadovaná konfigurace¶

SeaCat Auth je primárně konfigurován prostřednictvím souboru .conf. Pro obecné informace o konfiguraci (syntax atd.) se odkažte na příslušnou stránku v ASAB docs.

Příklad konfiguračního souboru¶

Takto může vypadat konfigurační soubor SeaCat Auth:

[general]
public_api_base_url=http://localhost/seacat_auth/api
auth_webui_base_url=http://localhost/auth
include=/conf/secret.conf

[logging:file]
path=/log/seacat-auth.log

[web]
listen=0.0.0.0 8082

[web:public]
listen=0.0.0.0 8081

[asab:storage]
type=mongodb
mongodb_uri=mongodb://mongo:27017/
mongodb_database=auth

[seacatauth:credentials]
policy_file=/conf/credentials-policy.json
ident_fields=username:ignorecase email:ignorecase

[seacatauth:credentials:mongodb:default]
mongodb_uri=mongodb://mongo:27017
mongodb_database=auth
tenants=yes
register=no

[seacatauth:credentials:htpasswd:file]
path=/conf/htpasswd

[seacatauth:google]
; client_id v secret.conf
; client_secret v secret.conf

[seacatauth:cookie]
name=SeaCatSCI
domain=localhost

[seacatauth:session]
expiration=1h
touch_extension=0.5
maximum_age=30d
; aes_key v secret.conf

[seacatauth:communication:email:smtp]
sender_email_address=info@teskalabs.com
host=smtp.sendgrid.net
ssl=no
starttls=yes
; user v secret.conf
; password v secret.conf

Credentials

Přihlašovací údaje¶

SeaCat Auth vyžaduje alespoň jednoho poskytovatele přihlašovacích údajů, aby správně fungoval. Ve výchozím nastavení používá poskytovatele s backendem MongoDB.

Politika přihlašovacích údajů¶

Je možné nakonfigurovat, které pole přihlašovacích údajů jsou povinná pro vytváření nebo registraci nových přihlašovacích údajů. Můžete také specifikovat, která pole přihlašovacích údajů mohou být upravována kým.

Konfigurace¶

Pro povolení vlastní konfigurace přidejte možnost policy_file do konfiguračního souboru služby a specifikujte cestu k vašemu souboru politiky:

[seacatauth:credentials]
policy_file=/path/to/credentials-policy.json

Možnosti politiky¶

Struktura souboru politiky následuje jednoduché schéma:

{
    "<field_name>": {
        "<context>": "<policy>"
    }
}

Je možné nakonfigurovat následující pole: - username - email - phone

Pro všechna tato pole existují dvě konfigurovatelné kontexty: creation a registration. Jejich možnosti politiky jsou: - disabled: Pole není v tomto kontextu povoleno. - allowed: Pole je povoleno, ale není povinné v tomto kontextu. - required: Pole je v tomto kontextu povinné (a nesmí být prázdné).

Pole email a phone mají další kontext: editable_by. Jeho možnosti politiky jsou: - nobody: Pole není editovatelné, ani superuživateli. - admin_only: Pole je editovatelné pouze superuživateli. - anybody: Pole je editovatelné kýmkoli. To také umožňuje aktualizaci pole ve vlastních přihlašovacích údajích.

Příklad souboru politiky¶

Následuje výchozí konfigurace politiky:

{
    "username": {
        "creation": "required",
        "registration": "required"
    },
    "email": {
        "creation": "required",
        "registration": "required",
        "editable_by": "anybody"
    },
    "phone": {
        "creation": "allowed",
        "registration": "allowed",
        "editable_by": "anybody"
    }
}

Poskytovatelé přihlašovacích údajů¶

MongoDB¶

MongoDB je výchozí úložiště pro SeaCat Auth.
Přihlašovací údaje následují předem definovanou schéma:

credential:
    _id: unikátní ID (bson.ObjectId),
    _c: čas vytvoření (UTC timestamp),
    _m: čas poslední úpravy (UTC timestamp),
    _v: verze (int),
    username: (str),
    email: (str),
    phone: (str),
    __password: hash hesla (str),
    suspended: (bool),
    data: další vlastní data (objekt),

Chcete-li přidat poskytovatele MongoDB, přidejte sekci [seacatauth:credentials:mongodb:<provider_name>] do konfigurace.

Příklad konfigurace¶

[seacatauth:credentials:mongodb:default]
mongodb_uri=mongodb://mongo:27017
mongodb_database=auth
tenants=yes
register=no

Externí MongoDB (`xmongodb`)¶

Vhodné pro externí Mongo databáze s přihlašovacími údaji, které neodpovídají schématu očekávanému výchozím poskytovatelem MongoDB.
Pouze pro čtení.
Chcete-li přidat poskytovatele XMongoDB, přidejte sekci [seacatauth:credentials:xmongodb:<provider_name>] do konfigurace.
Musíte specifikovat agregační pipeline dotazy list, get a locate.
Výstup agregačního dotazu by měl odpovídat schématu přihlašovacích údajů výchozího poskytovatele MongoDB, tj. objekt přihlašovacích údajů by měl obsahovat unikátní _id, email, __password a volitelně username a další pole. Použijte operaci $project k mapování vašich databázových polí na tyto aliasy. Další pole ve výstupu jsou považována za součást custom_data.

POZNÁMKA: Znak $ v dotazech musí být zdvojen jako $$ (únik je nutný ve formátu configparser).

Dotaz pro seznam

Používá se pro iteraci přes přihlašovací údaje, například v API pro seznam přihlašovacích údajů (GET /credentials).
Očekává se, že výsledek dotazu bude obsahovat _id, username, email, volitelně phone a suspended.

Dotaz pro získání

Používá se pro přístup k konkrétním přihlašovacím údajům, například v API pro detail přihlašovacích údajů (GET /credentials/<credentials_id>).
Očekává se, že výsledek dotazu bude obsahovat _id, username, email, __password, volitelně phone a suspended.
Použijte operaci $match s parametrem %(_id)s na místo ID přihlašovacích údajů.

POZNÁMKA: Použijte {"$$oid": %(_id)s} místo ObjectId(%(_id)s).

Dotaz pro lokalizaci

Používá se pro lokalizaci přihlašovacích kandidátů podle username, email, phone nebo jiných polí.
Očekává se, že výsledek dotazu bude obsahovat _id, volitelně username a email.
Použijte operaci $match s parametrem %(ident)s pro shodu přihlašovacích údajů podle identifikátoru (řetězec, který uživatel zadal do přihlašovacího formuláře).

Příklad konfigurace¶

[seacatauth:credentials:xmongodb:users]
mongodb_uri=mongodb://localhost:27017
database=test
collection=users
list=
    [
        {"$$project": {
            "_id": true,
            "username": true,
            "email": true,
            "phone": true,
            "suspended": true
        }}
    ]
get=
    [
        {"$$match": {
            "_id": {"$$oid": %(_id)s}
        }},
        {"$$project": {
            "_id": true,
            "username": true,
            "email": true,
            "phone": true,
            "suspended": true,
            "likes": true,
            "__password": true
        }}
    ]
locate=
    [
        {"$$match": {
            "$$or": [
                {
                    "username": %(ident)s
                },
                {
                    "email": %(ident)s
                }
            ]
        }},
        {"$$project": {
            "_id": true,
            "username": true,
            "email": true,
            "phone": true,
            "suspended": true
        }}
    ]

LDAP / ActiveDirectory¶

Pouze pro čtení
Deklarováno sekcí [seacatauth:credentials:ldap:<provider_name>] v konfiguraci

Příklad konfigurace¶

[seacatauth:credentials:ldap:external]
uri=ldaps://localhost:636
base=OU=Users,OU=Employees,DC=ThisCompany,DC=local
filter=(cn=*)
attrusername=sAMAccountName
tls_cafile=/conf/secret/local-ldap-cert.pem
tls_require_cert=allow

MySQL¶

Chcete-li přidat poskytovatele MySQL, přidejte sekci [seacatauth:credentials:mysql:<provider_id>] do konfigurace.
Může být nakonfigurován jako editovatelný nebo pouze pro čtení.

Poskytovatel pouze pro čtení¶

Poskytovatel MySQL je ve výchozím nastavení pouze pro čtení.
Dotazy list, get a locate musí být specifikovány.
Použijte klauzule AS k mapování výsledkových polí na očekávaná pole SeaCat Auth _id, username, email, phone, suspended a __password.
Kde je to nutné, použijte pojmenované bind proměnné ve stylu pyformat.

Dotaz pro seznam

Používá se pro iteraci přes přihlašovací údaje, například v API pro seznam přihlašovacích údajů (GET /credentials).
Očekává se, že výsledek dotazu bude obsahovat _id, username, email, volitelně phone a suspended. Použijte klauzule AS k přidání těchto aliasů k databázovým polím.
Použijte klauzuli ORDER BY pro zajištění konstantního pořadí.

Dotaz pro získání

Používá se pro přístup k konkrétním přihlašovacím údajům, například v API pro detail přihlašovacích údajů (GET /credentials/<credentials_id>).
Očekává se, že výsledek dotazu bude obsahovat _id, username, email, __password, volitelně phone a suspended. Použijte klauzule AS k přidání těchto aliasů k databázovým polím.
Použijte klauzuli WHERE s bind parametrem %(_id)s pro shodu databázového objektu podle jeho ID.
Další datová pole, která by měla být zahrnuta v objektu přihlašovacích údajů, musí být také uvedena v konfiguraci jako data_fields.

Dotaz pro lokalizaci

Používá se pro lokalizaci přihlašovacích kandidátů podle username, email, phone nebo jiných polí.
Očekává se, že výsledek dotazu bude obsahovat _id, volitelně username a email.
Použijte klauzuli WHERE s bind parametrem %(ident)s pro shodu přihlašovacích údajů podle identifikátoru (řetězec, který uživatel zadal do přihlašovacího formuláře).

Příklad konfigurace¶

[seacatauth:credentials:mysql:external]
host=localhost
port=3306
user=root
password=rootpassword
database=auth
data_fields=firstName lastName
list=
    SELECT `id` AS '_id', `userName` AS 'username', `userEmail` AS 'email', `userPhone` AS 'phone'
    FROM `users` 
    ORDER BY `id` ASC;
get=
    SELECT `id` AS '_id', `userName` AS 'username', `userEmail` AS 'email', `userPhone` AS 'phone', `userPwd` AS '__password', `userSuspened` AS 'suspended', firstName, lastName
    FROM `users` 
    WHERE `id` = %(_id)s;
locate=
    SELECT `id` AS '_id', `userName`, `userEmail`
    FROM `users` 
    WHERE (LOWER(`userName`) = %(ident)s) OR (LOWER(`userEmail`) = %(ident)s);

Editovatelný poskytovatel¶

Chcete-li povolit vytváření, aktualizaci a mazání uživatelů, specifikujte editable=yes v konfiguraci.
To vyžaduje specifikaci dotazů create, update a delete.

Příklad konfigurace¶

[seacatauth:credentials:mysql:external]
editable=yes
user=root
password=rootpassword
database=auth
data_fields=firstName lastName
list=
    SELECT `id` AS '_id', `userName` AS 'username', `userEmail` AS 'email', `userPhone` AS 'phone'
    FROM `users` 
    ORDER BY `id` ASC;
get=
    SELECT `id` AS '_id', `userName` AS 'username', `userEmail` AS 'email', `userPhone` AS 'phone', `userPwd` AS '__password',  `userSuspened` AS 'suspended', firstName, lastName
    FROM `users` 
    WHERE `id` = %(_id)s;
locate=
    SELECT `id` AS '_id', `userName`, `userEmail`
    FROM `users` 
    WHERE (LOWER(`userName`) = %(ident)s) OR (LOWER(`userEmail`) = %(ident)s);
create=
    INSERT INTO `users` 
    (`userName`, `userEmail`, `userPhone`) 
    VALUES (%(username)s, %(email)s, %(phone)s);
update=
    UPDATE `users` 
    SET `userEmail` = %(email)s, `userPhone` = %(phone)s, `userSuspened` = %(suspended)s, `userPwd` = %(__password)s
    WHERE `id` = %(_id)s;
delete=
    DELETE FROM `users` 
    WHERE `id` = %(_id)s;

Htpasswd¶

Pouze pro čtení
Chcete-li vytvořit poskytovatele htpasswd, přidejte sekci [seacatauth:credentials:htpasswd:<provider_name>] do konfigurace a specifikujte cestu k vašemu htpasswd souboru.
Nový htpasswd soubor můžete vytvořit pomocí příkazu htpasswd, například
```
htpasswd /opt/site/seacatauth-conf/htpasswd john-smith
```

Příklad konfigurace¶

[seacatauth:credentials:htpasswd:local]
path=/conf/htpasswd

V paměti (Slovník)¶

Neperzistentní editovatelný poskytovatel
Deklarováno sekcí [seacatauth:credentials:dict:<provider_name>] v konfiguraci

Příklad konfigurace¶

[seacatauth:credentials:dict:inmemory]

Authentizace a login

SeaCat Auth podporuje přihlášení prostřednictvím autentizačních poskytovatelů třetích stran. To umožňuje uživatelům používat svůj účet Google nebo Github k přihlášení do SeaCat Auth.

SeaCat Auth v současnosti podporuje tyto poskytovatele přihlášení:

Google
Office 365
Github
MojeID
Facebook
AppleID

Jakmile je externí přihlášení nakonfigurováno, jsou možnosti přihlášení k dispozici na přihlašovací obrazovce jako alternativa ke standardnímu přihlášení SeaCat Auth.

Každý uživatel může na své obrazovce Můj účet povolit nebo zakázat své možnosti externího přihlášení.

Nastavení externího přihlášení vyžaduje registraci a konfiguraci vašeho webu SeaCat Auth u příslušného poskytovatele a konfiguraci samotné služby SeaCat Auth.

Jakmile si vyberete, který poskytovatel přihlášení chcete nastavit, přejděte na jejich webové stránky a zaregistrujte svou aplikaci SeaCat Auth. Obdržíte Client ID a Client secret, které použijete v konfiguraci SeaCat Auth.

Většina poskytovatelů OAuth2 vyžaduje, abyste specifikovali seznam přesných autorizovaných přesměrovacích URI. Pokud je to váš případ, musíte poskytnout dvě URI v následujícím formátu:

<SEACAT_PUBLIC_API_BASE_URL>/public/ext-login/<LOGIN_PROVIDER_ID>
<SEACAT_PUBLIC_API_BASE_URL>/public/ext-login-add/<LOGIN_PROVIDER_ID>

Například, pokud vaše veřejné API SeaCat Auth běží na https://auth.example.xyz/auth/api/seacat_auth/ a chcete nakonfigurovat přihlášení s google, přidejte tyto adresy do seznamu autorizovaných přesměrovacích URI v Google API Credentials.

https://auth.example.xyz/auth/api/seacat_auth/public/ext-login/google
https://auth.example.xyz/auth/api/seacat_auth/public/ext-login-add/google

Jiní poskytovatelé (např. Github) nevyžadují seznam přesných URI, ale spíše jedinou cestu, se kterou všechny vaše přesměrovací URI začnou. V takových případech stačí poskytnout základní URL vašeho veřejného API SeaCat Auth, například

https://auth.example.xyz/auth/api/seacat_auth/public/

Nakonec můžete přidat sekci definující vašeho externího poskytovatele přihlášení do konfiguračního souboru SeaCat Auth. Budete potřebovat alespoň Client ID a Client secret, které jste obdrželi od svého poskytovatele přihlášení.

Název konfigurační sekce je vždy ve formátu [seacatauth:<LOGIN_PROVIDER_ID>]. Níže naleznete příklady konfigurace jednotlivých poskytovatelů přihlášení.

SeaCat Auth v současnosti podporuje následující externí poskytovatele přihlášení:

Google
Office 365
Github
Moje ID

Provider ID: google

Zaregistrujte svou aplikaci SeaCat Auth v Google API Credentials.

[seacatauth:google]
client_id=a2c4e6...
client_secret=1b3d5f...

Provider ID: office365

Zaregistrujte svou aplikaci SeaCat Auth v Azure Active Directory.

Kromě client ID a client secret vyžaduje přihlášení Office 365 také vyplnění vašeho tenant ID.

[seacatauth:office365]
tenant_id=def123...
client_id=a2c4e6...
client_secret=1b3d5f...

Provider ID: github

Zaregistrujte svou aplikaci SeaCat Auth ve svých Github developer settings.

[seacatauth:github]
client_id=a2c4e6...
client_secret=1b3d5f...

Provider ID: mojeid

Zaregistrujte se pro účet MojeID provider. Postupujte podle jejich dokumentace pro získání client ID a secret.

[seacatauth:mojeid]
client_id=a2c4e6...
client_secret=1b3d5f...

Provider ID: appleid

Zaregistrujte svou aplikaci v Apple Developer program Service ID settings pro získání client ID. Apple vrací e-mail a uživatelské jméno v odpovědi hned po volání OAuth2 /authorize, takže nepotřebujeme client_secret, protože nemusíme hitovat endpoint /token vůbec.

Dokumentace pro přihlášení pomocí Apple dokumentace

[seacatauth:appleid]
client_id=a2c4e6...

Když se neznámý uživatel přihlásí prostřednictvím externího poskytovatele identity, je možné spustit webhook na externí službu. Tato služba může registrovat uživatele a vrátit jejich credential ID. Pokud odpověď obsahuje platný credential_id, přihlášení probíhá úspěšně.

Pro povolení webhooku specifikujte URL webhooku v konfiguračním souboru:

[seacatauth:external_login]
registration_webhook_uri=http://localhost:8089/external-registration

Webhook je POST požadavek s JSON payload obsahujícím následující vlastnosti:

provider_type - typ poskytovatele identity (např. google nebo appleid),
authorization_response - parametry dotazu odpovědi bez autorizačního kódu,
user_info - OpenID UserInfo-like nároky o přihlášeném uživateli (povinné sub, volitelné email, preferred_username atd.). Skutečné nároky se liší mezi poskytovateli a také závisí na vašem rozsahu a konfiguraci klienta.

Úspěšná odpověď webhooku musí obsahovat platný credential_id vytvořených přihlašovacích údajů. Jinak je odpověď považována za chybu a přihlášení končí neúspěchem.

Požadavek:

POST /webhook_url
{
  "provider_type": "google",
  "authorization_response": {
    "scope": "email profile openid https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email",
    "authuser": "0",
    "prompt": "consent"
  },
  "user_info": {
    "iss": "accounts.google.com",
    "sub": "01234567890123456789",
    "email": "abcdefgh@gmail.com",
    "email_verified": true
  }
}

Odpověď:

{
  "credential_id": "mongodb:custom:abcd123456789"
}

Konfigurace SeaCat Auth pro odesílání e-mailů¶

SeaCat Auth může odesílat e-maily uživatelům, např. když zapomenou heslo atd. K tomu je nutné nakonfigurovat odchozí poštovní server, známý jako SMTP.

Obecná konfigurace SMTP¶

[seacatauth:communication:email:smtp]
sender_email_address=<user@email.info>
host=<hostname.example.com>
port=<25|if missing, default is guessed>
user=<username>
password=<password>
ssl=<yes|no>
starttls=<yes|no>

Konfigurace SMTP pro SendGrid¶

Na základě: https://sendgrid.com/docs/for-developers/sending-email/getting-started-smtp/

[seacatauth:communication:email:smtp]
sender_email_address=<user@email.info>
host=smtp.sendgrid.net
ssl=yes
starttls=no

# Uživatelské jméno je vždy `apikey`
user=apikey

# API klíč SendGrid z stránky API Keys SendGrid.
password=XX.xxxxxxxxxxxxxxxxxxxxxx.yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy

Integrace

Integrace aplikací se SeaCat Auth¶

TeskaLabs SeaCat Auth může být použit jako řešení Single Sign-On pro různé aplikace. Díky takové integraci můžete používat své Active Directory, LDAP nebo sociální přihlášení (např. Google, GitHub, Microsoft Office, ...) pro autentizaci uživatelů.

TheHive
ElasticSearch/Kibana
Grafana

NGINX¶

Aplikační brána pro TeskaLabs SeaCat Auth je NGINX. NGINX izoluje veřejnou síť (Internet) od interní privátní sítě a slouží jako takzvaný "interceptní bod" pro autentizaci. Více instancí NGINX může být provozováno současně.

Prohlížeč a příslušné webové a mobilní aplikace používají Access tokens nebo Cookies pro autentizační účely.

NGINX zachycuje příchozí požadavky z veřejné sítě a ve spolupráci s TeskaLabs SeaCat Auth vyměňuje Access tokens / Cookies za ID tokens a další nakonfigurované autentizační informace. ID Token je přidán NGINX do HTTP hlavičky příchozích požadavků.

ID Token je poté interně používán mikroservisy a zdrojem autentizace a autorizace.

Architektura¶

Autorizace pomocí cookies pro ne-OAuth klienty¶

Seacat Auth poskytuje autorizaci založenou na cookies pro starší webové stránky a aplikace, které nepodporují OAuth 2.0. Jeho PUT /nginx/introspect/cookie koncový bod je navržen tak, aby fungoval s reverzním proxy Nginx a jeho direktivou auth_request.

Tok autorizace pomocí cookies¶

(1) Uživatel chce získat přístup k obsahu klienta, například k webové aplikaci Kibana, která je chráněna introspekcí cookies. Seacat Auth zkoumá požadavek, aby zjistil, zda je autentizován a autorizován s platnou klientskou cookie. Pokud ano, uživateli je vrácen obsah klienta (7). Pokud ne, uživatel je veden procesem autorizace (2).

(2) Konec OAuth 2.0 autorizace kontroluje, zda je uživatel autentizován. Pokud ne, je veden procesem přihlášení (3). Pokud je autentizován, je přesměrován na vstupní bod klientské cookie (4).

(3) Seacat Auth vede uživatele procesem přihlášení, aby se vytvořila relace single sign-on a podrelace klienta (Kibana).

(4) Uživatel je přesměrován na vstupní bod cookie.

(5) Vstupní bod cookie odešle uživateli klientskou cookie, která slouží jako identifikátor nové klientské relace.

(6) Uživatel odešle autorizovaný požadavek na přístup na klientskou stránku.

(7) Server odpovídá požadovaným obsahem klienta.

Připojení aplikací OAuth¶

Nastavení introspekce OAuth2 pro webovou aplikaci¶

Nejprve zaregistrujte svou webovou aplikaci v sekci Klient v uživatelském rozhraní SeaCat. Získáte client_id, který je nezbytný pro požadavek na introspekci.

Nastavte umístění pro vaši aplikaci v konfiguraci Nginx:

location <APPLICATION_PATH> {
    proxy_pass <INTERNAL_APPLICATION_URL>;

    auth_request        /_oauth2_introspect;
    auth_request_set    $authorization $upstream_http_authorization;
    proxy_set_header    Authorization $authorization;

    error_page 401 /auth/api/openidconnect/authorize?<CLIENT_PARAMETERS>&redirect_uri=$request_uri;
}

<APPLICATION_PATH> je cesta, kde bude vaše aplikace přístupná uživatelům.
<INTERNAL_APPLICATION_URL> je interní URL vašeho aplikačního serveru.
<CLIENT_PARAMETERS> je dotazovací řetězec vašich registrovaných klientských parametrů, obvykle zahrnující client_id, response_type, scope. Všimněte si, že další parametry, jako například client_secret, mohou být vyžadovány v závislosti na typu a konfiguraci vašeho klienta. Příklad cesty s minimálními parametry: /auth/api/openidconnect/authorize?client_id=abc1230ZM3n37BmbtKrqqw&response_type=code&scope=openid&redirect_uri=$request_uri

Integrace s jinými aplikacemi

HTTP Cookies 🍪¶

SeaCat Auth poskytuje autentizaci založenou na cookies pro aplikace, které neimplementují OAuth2. Pro jednodoménové a vícedoménové nastavení je potřeba odlišná konfigurace.

Jednodoménové nastavení¶

Pokud všechny aplikace, které chcete chránit, běží na stejné doméně jako vaše služba SeaCat Auth (nebo její subdomény), musíte nakonfigurovat pouze hlavní cookie. Tato cookie je uživateli automaticky odeslána po úspěšném přihlášení.

Konfigurace služby¶

Hlavní cookie je nakonfigurována v sekci [seacatauth:cookie]. Dostupné možnosti konfigurace jsou: - name: Název cookie, výchozí hodnota je SeaCatSCI - domain: Doména cookie. Nemá žádnou výchozí hodnotu a musí být explicitně nakonfigurována.

POZNÁMKA: Aby cookie fungovala ve všech hlavních prohlížečích, musí doména cookie obsahovat alespoň dvě tečky (požadavek od Firefoxu). Například localhost nebo .xyz nemusí fungovat správně, ale .app.localhost nebo .example.xyz by měly fungovat bez problémů.

Příklad¶

[seacatauth:cookie]
domain=.service.xyz

Taková cookie je platná na doméně service.xyz a všech jejích subdoménách a subcestách, například auth.service.xyz nebo myapp.test.service.xyz/example.

Introspekce cookie je způsob autentizace a autorizace požadavků na chráněné místo. Každý uživatelský požadavek na takové místo je kontrolován, zda má platnou cookie SeaCat Auth v hlavičce. Pokud ano, požadavek pokračuje na chráněné místo. Pokud nemá platnou cookie, je uživateli odeslána odpověď HTTP 401 Not Authorized. Nebo může být uživatel přímo přesměrován na koncový bod autorizace.

Koncový bod introspekce cookie se nachází na cestě /nginx/introspect/cookie a používá POST požadavky. Dále má schopnost přidávat určité informace o uživateli do HTTP X-hlavic, například uživatelské jméno, role nebo nájemce. To se provádí pomocí add= dotazových parametrů v introspekčním volání. Podívejte se na kolekci SeaCat Auth Postman pro více informací o tomto koncovém bodu.

Konfigurace koncového bodu introspekce:

location = /_cookie_introspect {
    internal;
    proxy_method          POST;
    proxy_set_body        "$http_authorization";
    proxy_pass            <SEACAT_AUTH_SERVICE_URL>/nginx/introspect/cookie;
    proxy_ignore_headers  Cache-Control Expires Set-Cookie;
}

Příklad konfigurace chráněného místa pomocí cookie:

location / {
    proxy_pass <PROTECTED_LOCATION_URL>;

    auth_request        /_cookie_introspect;
    auth_request_set    $authorization $upstream_http_authorization;
    proxy_set_header    Authorization $authorization;
}

Vícedoménové nastavení¶

Pokud některé z vašich aplikací běží na jiných doménách než služba SeaCat Auth, musíte nastavit aplikaci cookie a koncový bod pro vstup cookie pro každou z těchto domén. Na rozdíl od hlavní cookie nejsou tyto cookies automaticky vydávány po přihlášení. Aby je bylo možné získat, je nutné provést volání požadavku na cookie.

❓ TODO: Tok uživatele bez autentizace ❓

Uživatel se pokouší přistupovat k chráněnému místu bez požadované aplikace cookie
Introspekce cookie NGINX selže a uživatel je přesměrován na koncový bod OIDC autorizace
Koncový bod autorizace přesměrovává uživatele na přihlašovací obrazovku
Uživatel se přihlásí
Uživatel je přesměrován na koncový bod žádosti o aplikaci cookie s autentizačním kódem v dotazovacím řetězci
Koncový bod žádosti o cookie vymění autentizační kód za cookie a přesměruje uživatele na předem nakonfigurovanou URL

Konfigurace¶

Každá cookie je nakonfigurována ve své vlastní sekci nazvané [seacatauth:cookie:<APP_DOMAIN_ID>]. <DOMAIN_ID> se používá v URL požadavku na cookie pro odpovídající doménu.

[seacatauth:cookie]
; Toto je hlavní cookie, je vyžadována jak v jednodoménovém, tak ve vícedoménovém nastavení
domain=auth.service.xyz

[seacatauth:cookie:myservice]
domain=my.service.xyz
redirect_uri=http://my.service.xyz/home

[seacatauth:cookie:anotherservice]
domain=service.elsewhere.xyz
redirect_uri=http://service.elsewhere.xyz/discover

redirect_uri určuje, kam je uživatel přesměrován po úspěšném požadavku na cookie.

GET /cookie/entry/<APP_DOMAIN_ID>

Vyměňuje autorizační kód za aplikaci cookie. Je nutné poskytnout dotazové parametry grant_type=authorization_code a code=...... v požadavku.

Např.:

GET http://my.service.xyz/auth/cookie/entry/myservice?grant_type=authorization_code&code=4x0fDvBTuSM3dWlp7t2560A4wtCB199dcbLU5pphe8AagCpM

Konfigurace NGINX¶

Každá z nakonfigurovaných domén musí mít proxy na introspekci cookie a požadavek na cookie koncové body. Koncový bod introspekce je nakonfigurován přesně stejně jako v případě jednodoménového nastavení:

location = /_cookie_introspect {
    internal;
    proxy_method          POST;
    proxy_set_body        "$http_authorization";
    proxy_pass            <SEACAT_AUTH_PUBLIC_API_INTERNAL_URL>/nginx/introspect/cookie;
    proxy_ignore_headers  Cache-Control Expires Set-Cookie;
}

<SEACAT_AUTH_PUBLIC_API_INTERNAL_URL> je interní základní URL vaší veřejné API SeaCat Auth.

Místa, která používají introspekci cookie, by měla nastavit svou chybovou stránku na koncový bod OIDC autorizace s scope=openid&response_type=code pro automatické vyzvání k přihlášení. URL pro přesměrování by měla směřovat na požadavek na cookie koncový bod s grant_type=authorization_code:

server_name <APP_DOMAIN>

...

location /auth/cookie_entry {
    proxy_pass <SEACAT_AUTH_PUBLIC_API_INTERNAL_URL>/cookie/entry/<APP_DOMAIN_ID>;
}

<APP_DOMAIN> je vaše aplikační doména, odlišná od domény SeaCat Auth.
<APP_DOMAIN_ID> je ID vaší aplikační domény, jak jste ji nakonfigurovali v konfiguraci služby SeaCat Auth.
<SEACAT_AUTH_PUBLIC_API_INTERNAL_URL> je interní základní URL vaší veřejné API SeaCat Auth.

location / {
    proxy_pass <PROTECTED_LOCATION_URL>;

    auth_request        /_cookie_introspect;
    auth_request_set    $authorization $upstream_http_authorization;
    proxy_set_header    Authorization $authorization;

    error_page 401 403 <SEACAT_AUTH_PUBLIC_API_URL>/openidconnect/authorize?response_type=code&scope=openid&client_id=signin&redirect_uri=<APP_DOMAIN>/auth/cookie_entry?grant_type=authorization_code;
}

<PROTECTED_LOCATION_URL> je interní URL vašeho chráněného místa.
<SEACAT_AUTH_PUBLIC_API_URL> je veřejné základní URL vaší veřejné API SeaCat Auth.

Připojení k Elasticsearch a Kibana¶

Toto je průvodce konfigurací SeaCat Auth jako proxy pro uživatele a role Kibana. Protože Kibana není kompatibilní s OAuth a podporuje pouze základní autentizaci, je integrace do prostředí Single Sign-On vyžaduje zvláštní přístup. Komponenta SeaCat Auth Batman (Basic Auth Token MANager) je navržena přesně pro tento úkol - "překládá" Seacat session cookies na základní autentizační hlavičky a synchronizuje uživatele Kibana/Elasticsearch s přihlašovacími údaji SeaCat Auth a jejich přístupovými právy.

Jak to funguje?¶

Tok pro použití Batman auth je téměř stejný jako tok cookie auth, jediným rozdílem je typ introspekce, který se používá. Místo koncového bodu PUT /nginx/introspect/cookie (který vyměňuje Seacat klientské cookie za ID token), Batman auth používá PUT /nginx/introspect/batman (který vyměňuje Seacat klientské cookie za základní autentizační hlavičku).

Příklad konfigurace¶

Nastavme autorizaci Seacat Batman pro naši aplikaci Kibana. Musíme mít aplikace Elasticsearch a Kibana spuštěné, stejně jako funkční instanci SeaCat Auth s Nginx reverzní proxy. Budeme muset nakonfigurovat tyto tři komponenty:

Aktualizovat konfiguraci SeaCat Auth o sekci [batman:elk], aby mohla používat Elasticsearch API pro synchronizaci uživatelů a správu jejich autorizace.
Vytvořit a nakonfigurovat Kibana klienta. Tento objekt klienta reprezentuje a identifikuje Kibana v komunikaci se SeaCat Auth.
Připravit potřebné serverové lokace v konfiguraci Nginx.

Konfigurace SeaCat Auth¶

Vytvořte sekci ELK Batman a zadejte základní URL Elasticsearch a API přihlašovací údaje, např.

[batman:elk]
url=http://localhost:9200
username=admin
password=elasticpassword

Konfigurace klienta¶

Použijte API klienta SeaCat Auth (nebo Seacat Admin UI) k registraci Kibana jako klienta. Tělo požadavku musí obsahovat čitelný client_name, pole redirect_uris obsahující URL webového rozhraní Kibana a cookie_entry_uri pro vaše hostname (tuto lokaci definujeme v konfiguraci Nginx níže). Doporučujeme také nastavit redirect_uri_validation_method na prefix_match, pokud chcete povolit okamžité přesměrování na podcesty Kibana. V našem případě můžeme poslat následující požadavek (nezapomeňte použít vaše skutečné hostname místo example.com!):

POST /client
{
    "client_name": "Kibana",
    "redirect_uri_validation_method": "prefix_match",
    "redirect_uris": [
        "https://example.com/kibana"
    ],
    "cookie_entry_uri": "https://example.com/seacat_auth/cookie"
}

Server odpoví s ID přiděleným našemu klientovi a dalšími atributy:

{
    "client_id": "RZhlE-D4yuJxoKitYVL4dg",
    "client_id_issued_at": 1687170414,
    "application_type": "web",
    ...,
    "cookie_name": "SeaCatSCI_QLFLEAU4D726UPA3"
}

V dalším kroku použijeme client_id a client_cookie.

Konfigurace Nginx¶

Minimální konfigurace vyžaduje definici následujících tří lokalit v nginx:

Lokalita klientské stránky: Ochráněná veřejná lokalita s webovou aplikací Kibana.
Introspekce klienta: Interní koncový bod používaný direktivou nginx auth_request.
Vstupní bod pro cookies klienta: Veřejný koncový bod, který vydává Seacat klientské cookie na konci úspěšného toku autorizace.

Lokalita klientské stránky¶

location /kibana/ {
    # Kibana upstream
    proxy_pass http://kibana_api;

    # Auth introspekční koncový bod
    auth_request /_kibana_introspection;

    # Předat Batman hlavičku získanou z introspekce SeaCat Auth do Kibana
    auth_request_set $auth_header $upstream_http_authorization;
    proxy_set_header Authorization $auth_header;

    # V případě, že introspekce zjistí neplatnou autorizaci, přesměrovat na OAuth autorizační koncový bod
    # !! Použijte skutečné client_id vašeho klienta a skutečné hostname vašeho webu !!
    error_page 401 https://example.com/auth/api/openidconnect/authorize?response_type=code&scope=cookie%20batman&client_id=RZhlE-D4yuJxoKitYVL4dg&redirect_uri=https://example.com$request_uri;

    # Hlavičky požadované Kibana
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
}

Introspekce klienta¶

location = /_kibana_introspection {
    internal;

    # Seacat Auth Batman introspekční upstream
    # !! Použijte skutečné client_id vašeho klienta !!
    proxy_method          POST;
    proxy_pass            http://seacat_auth_api/nginx/introspect/batman?client_id=RZhlE-D4yuJxoKitYVL4dg;

    proxy_set_header      X-Request-URI "$request_uri";
    proxy_ignore_headers  Cache-Control Expires Set-Cookie;

    # Cache odpovědi introspekce
    proxy_buffer_size     128k;
    proxy_buffers         4 256k;
    proxy_busy_buffers_size  256k;
    proxy_cache           kibana_auth;
    # !! Vyplňte skutečné cookie_name vašeho klienta !!
    proxy_cache_key       $cookie_SeaCatSCI_QLFLEAU4D726UPA3;
    proxy_cache_lock      on;
    proxy_cache_valid     200 10s;
}

Vstupní bod pro cookies¶

Musí být umístěn na stejném hostname jako chráněná lokalita klienta. Měl by být vystaven jeden vstupní bod pro cookies na hostname, sdílený všemi klienty založenými na cookies na tomto hostname.

location = /seacat_auth/cookie {
    # Seacat Auth cookie vstupní upstream
    proxy_method          POST;
    proxy_pass            http://seacat_auth_api/cookie/entry;

    # Přenést OAuth autorizační kód z dotazu do těla požadavku
    # !! Použijte skutečné client_id vašeho klienta !!
    proxy_set_header      Content-Type "application/x-www-form-urlencoded";
    proxy_set_body        $args;
}

Připojení k TheHive¶

Toto je průvodce konfigurací TheHive pro použití SeaCat Auth jako svého Single Sign-on (SSO) poskytovatele OAuth2.

Požadavky¶

Instalace SeaCat Auth s reverzním proxy a oběma webovými uživatelskými rozhraními.
TheHive

Konfigurace¶

auth {
    providers: [
        {name: session}
        {name: basic, realm: thehive}
        {name: local}
        {name: key}
        {
            name: oauth2
            clientId: "<CLIENT_ID>"
            clientSecret: "<CLIENT_SECRET>"
            redirectUri: "<THEHIVE_URL>/api/ssoLogin"
            responseType: "code"
            grantType: "authorization_code"
            authorizationUrl: "<PUBLIC_SEACAT_AUTH_API_URL>/openidconnect/authorize"
            authorizationHeader: "Bearer"
            tokenUrl: "<INTERNAL_SEACAT_AUTH_API_URL>/openidconnect/token"
            userUrl: "<INTERNAL_SEACAT_AUTH_API_URL>/openidconnect/userinfo"
            scope: ["openid"]
            userIdField: "email"
        }
    ]
}

user.autoCreateOnSso: true

<CLIENT_ID> a <CLIENT_SECRET> jsou OAuth2 klientské přihlašovací údaje, které vám vydal SeaCat Auth.
<THEHIVE_URL> je veřejná URL adresa, kde je The Hive dostupný.
<PUBLIC_SEACAT_AUTH_API_URL> je veřejná (přístupná z prohlížeče uživatele) URL adresa veřejného kontejneru SeaCat Auth.
<INTERNAL_SEACAT_AUTH_API_URL> je interní (přístupná z instance Hive) URL adresa veřejného kontejneru SeaCat Auth.

Další relevantní možnosti konfigurace naleznete v dokumentaci The Hive.

Použití autorizace Seacat v Grafaně¶

Tento návod vám ukáže, jak nastavit Grafanu, abyste mohli používat Seacat Auth pro přihlášení a řízení přístupu. Grafana má nativní podporu pro OAuth autorizační tok, takže její propojení se Seacat Auth je poměrně jednoduché.

Zaregistrujte nového klienta pro vaši aplikaci Grafana v sekci Clients v Seacat Admin UI. Poznamenejte si ID klienta.
Vytvořte následující ID zdrojů v sekci Resources v Seacat Admin UI (nebo si zvolte jiná jména, ale nezapomeňte je změnit v konfiguraci role_attribute_path v Grafaně níže):
- grafana:access: Bude mapováno na Grafanovu roli Viewer, která uživateli umožňuje procházet dashboardy a další data, ale ne vytvářet nebo měnit cokoliv.
- grafana:edit: Bude mapováno na Grafanovu roli Editor, která uživateli umožňuje procházet a upravovat dashboardy a další data.
Nakonfigurujte Grafanu tak, aby používala vaši instanci Seacat Auth jako Generic OAuth provider. To lze provést buď v konfiguračním souboru Grafany, nebo možná pohodlněji pomocí proměnných prostředí ve vašem souboru docker-compose.yaml, jak je následující:

services:
  grafana:
    image: grafana/grafana:10.3.1
    network_mode: host
    (...)
    environment:
      ## Required configuration options
      # URL, kde je Grafana přístupná v prohlížeči
      GF_SERVER_ROOT_URL: ${PUBLIC_URL}/grafana/
      # Povolit OAuth přihlášení
      GF_AUTH_GENERIC_OAUTH_ENABLED: true
      # ID klienta vydané Seacat Auth
      GF_AUTH_GENERIC_OAUTH_CLIENT_ID: ${GRAFANA_CLIENT_ID}
      # Tajemství klienta vydané Seacat Auth (zatím není podporováno)
      GF_AUTH_GENERIC_OAUTH_CLIENT_SECRET: ""
      # OAuth rozsahy, které Grafana požádá od Seacat Auth
      GF_AUTH_GENERIC_OAUTH_SCOPES: openid email profile
      # Veřejná URL adresa koncového bodu autorizace Seacat Auth OAuth
      GF_AUTH_GENERIC_OAUTH_AUTH_URL: ${PUBLIC_URL}/api/openidconnect/authorize
      # Interní URL adresa koncového bodu tokenů Seacat Auth OAuth
      GF_AUTH_GENERIC_OAUTH_TOKEN_URL: ${INTERNAL_SEACAT_AUTH_URL}/openidconnect/token
      # Interní URL adresa koncového bodu uživatelských informací Seacat Auth OAuth
      GF_AUTH_GENERIC_OAUTH_API_URL: ${INTERNAL_SEACAT_AUTH_URL}/openidconnect/userinfo

      ## Další užitečné konfigurační možnosti
      # Kam je uživatel přesměrován po stisknutí tlačítka "Odhlásit se"
      GF_AUTH_SIGNOUT_REDIRECT_URL: ${PUBLIC_URL}
      # Přeskočit přihlašovací obrazovku Grafany a automaticky přihlásit uživatele
      GF_AUTH_GENERIC_OAUTH_AUTO_LOGIN: true
      # Zakázat PKCE
      GF_AUTH_GENERIC_OAUTH_USE_PKCE: false
      # Zakázat obnovovací tokeny (zatím není podporováno)
      GF_AUTH_GENERIC_OAUTH_USE_REFRESH_TOKEN: false
      # Název poskytovatele OAuth zobrazený na tlačítku "Přihlásit se pomocí ..." na přihlašovací obrazovce Grafany
      GF_AUTH_GENERIC_OAUTH_NAME: Seacat Auth
      # Získat uživatelské jméno a jméno na obrazovce primárně z pole standardu OpenID Connect "preferred_username", s fallbackem na pole "username" a "sub"
      GF_AUTH_GENERIC_OAUTH_LOGIN_ATTRIBUTE_PATH: preferred_username || username || sub
      GF_AUTH_GENERIC_OAUTH_NAME_ATTRIBUTE_PATH: preferred_username || username || sub
      # Řídit oprávnění uživatelů pomocí autorizovaných zdrojů Seacat Auth:
      #   Následující výraz JMESPath přiřazuje uživateli roli Grafana v závislosti na autorizovaných zdrojích v jejich ID tokenu nebo Userinfo
      GF_AUTH_GENERIC_OAUTH_ROLE_ATTRIBUTE_PATH: >
        contains(resources."*"[*], 'authz:superuser') && 'Admin' 
        || contains(resources."*"[*], 'grafana:edit') && 'Editor' 
        || contains(resources."*"[*], 'grafana:access') && 'Viewer'
      # Zamezit přihlášení, pokud uživatel není autorizován pro žádný z zdrojů ve výrazu výše
      GF_AUTH_GENERIC_OAUTH_ROLE_ATTRIBUTE_STRICT: true

PUBLIC_URL je základní URL adresa, ze které je Seacat Auth přístupný z prohlížeče, například https://example.com.
INTERNAL_SEACAT_AUTH_URL je interní URL adresa soukromého webového kontejneru Seacat Auth, obvykle http://localhost:8900.
GRAFANA_CLIENT_ID je ID klienta vydané Seacat Auth.

POZNÁMKA: Výše uvedená konfigurace předpokládá, že backend Grafany komunikuje se serverem Seacat Auth přes zabezpečenou interní síť (obvykle VPN). Pokud tomu tak není a obě služby nemají sdílenou interní síť, nakonfigurujte GF_AUTH_GENERIC_OAUTH_TOKEN_URL a GF_AUTH_GENERIC_OAUTH_API_URL pomocí veřejných URL.

Pokud je toto vaše testovací prostředí a používáte samostatně podepsaný SSL certifikát, budete muset přidat také následující přepínač:

GF_AUTH_GENERIC_OAUTH_TLS_SKIP_VERIFY_INSECURE: true

Pro více informací o konfiguraci Grafana OAuth, odkazujte na její dokumentaci.

Pro vývojáře

REST API

REST API¶

Rámec ASAB, na kterém je postaven Seacat Auth, poskytuje koncový bod pro OpenAPI specifikace s Swagger UI (přečtěte si více v ASAB dokumentaci).

Swagger UI je k dispozici na cestě /doc.

OpenAPI specifikace jsou k dispozici na /asab/v1/openapi.

Postman¶

Pro prozkoumání Seacat API pomocí Postmanu si můžete stáhnout OpenAPI specifikace z /asab/v1/openapi jako soubor a importovat je do Postmanu jako novou kolekci.

Použití SeaCat Auth s Postmanem¶

Postman je užitečný vývojový nástroj pro ladění aplikací, které interagují se SeaCat Auth. Hlavní výhodou je, že Postman nativně zpracovává OAuth2.0 autentizaci a poskytuje nástroje pro správu autentizačních tokenů.

Požadavky¶

Běžící instance SeaCat Auth
Zkontrolujte sekci [general] v konfiguraci, abyste se ujistili, že proměnné auth_webui_base_url a public_api_base_url ukazují na skutečné URL vaší SeaCat Auth WebUI
Běžící instance SeaCat Auth WebUI
Auth WebUI je vyžadováno pro autentizaci v SeaCat Auth
Zkontrolujte směrování proxy (v Nginx), abyste se ujistili, že správně ukazuje na váš backend SeaCat Auth

Konfigurace prostředí Postman¶

Importujte OpenAPI specifikace z /asab/v1/openapi v SeaCat Auth API.
Nastavte prostředí SeaCat Auth Postman. Následující proměnné je třeba definovat:
BASE_URL by měla obsahovat základní URL vašeho SeaCat API, například https://my-domain.int/seacat/api/seacat_auth
AUTH_URL by měla obsahovat základní URL vašeho SeaCat Auth, například https://my-domain.int/auth. Používá se pro autentizaci vaší relace.

Vytvoření autorizované relace OAuth2¶

V panelu Collections otevřete kontextové menu vaší kolekce SeaCat Auth a zvolte Edit.
Přejděte na kartu Authorization.
Pro Authorization type vyberte OAuth 2.0
Požádejte o nový přístupový token a přihlaste se do vaší SeaCat Auth WebUI
Vaše relace Postman je nyní autentizována!

Detaily přístupového tokenu Postman¶

Typ udělení: "Authorization Code"
URL pro zpětné volání: http://localhost:8080/???? (???)
Auth URL: http://localhost:8080/openidconnect/authorize
URL přístupového tokenu: http://localhost:8080/openidconnect/token
Client Id: [jakýkoli řetězec]
Client Secret: [jakýkoli řetězec]
Scope: openid
State: [prázdný řetězec]
Autentizace klienta: Odeslat přihlašovací údaje klienta v těle

POZNÁMKA Některé API požadavky budou splněny pouze v případě, že máte přístup k specifickým administrátorským zdrojům (authz:superuser nebo authz:tenant:admin). Zkontrolujte popis těchto volání, abyste zjistili, zda existují nějaká omezení přístupu.

OAuth 2.0 v SeaCat Auth¶

Specifikace je k dispozici zde: https://tools.ietf.org/html/rfc6749

Protokolové koncové body¶

1. Protokolové koncové body (autorizovací služba, autorizátor)
3.1. Autorizovací koncový bod (autorizovací služba, autorizátor)
3.2. Tokenový koncový bod (autorizovací služba, zpracovatel tokenů)
3.2.1. Autentizace klienta (autorizovací služba, autorizátor)

Tok autorizace pomocí kódu¶

4.1. Tok autorizace pomocí kódu (autorizovací služba, autorizátor)
4.1.1. Žádost o autorizaci (autorizovací služba, autorizátor)
4.1.2. Odpověď na autorizaci (autorizovací služba, autorizátor)
4.1.2.1. Chybová odpověď (autorizovací služba, autorizátor)
4.1.3. Žádost o přístupový token (autorizovací služba, zpracovatel tokenů)
4.1.4. Odpověď na přístupový token (autorizovací služba, zpracovatel tokenů)

Obnovení přístupového tokenu¶

1. Obnovení přístupového tokenu (autorizovací služba, zpracovatel tokenů)

Zrušení tokenu OAuth 2.0¶

https://tools.ietf.org/html/rfc7009

OpenID Connect v SeaCat Auth¶

Specifikace je k dispozici zde: https://openid.net/specs/openid-connect-core-1_0-23.html

Autentizace pomocí toku autorizace kódu¶

3.1. Autentizace pomocí toku autorizace kódu (autorizovací služba, autorizátor)
3.1.1. Kroky toku autorizace kódu (autorizovací služba, autorizátor)
3.1.2. Autorizovací koncový bod (autorizovací služba, autorizátor)
3.1.2.1. Žádost o autentizaci (autorizovací služba, autorizátor)
3.1.2.2. Ověření žádosti o autentizaci (autorizovací služba, autorizátor)
3.1.2.3. Autorizátor ověřuje koncového uživatele (autorizovací služba, autorizátor)
3.1.2.4. Autorizátor získává souhlas/autorizaci koncového uživatele (autorizovací služba, autorizátor)
3.1.3.3. Úspěšná odpověď na token (autorizovací služba, zpracovatel tokenů)
3.1.3.4. Chybová odpověď na token (autorizovací služba, zpracovatel tokenů)
3.1.3.5. Ověření odpovědi na token (autorizovací služba, zpracovatel tokenů)
3.1.3.6. ID token (autorizovací služba, zpracovatel tokenů)

UserInfo Endpoint¶

5.3. UserInfo Endpoint (služba credentilasprovider, zpracovatel credentilasprovider)
5.3.1. Žádost o UserInfo (služba credentilasprovider, zpracovatel credentilasprovider)
5.3.2. Úspěšná odpověď na UserInfo (služba credentilasprovider, zpracovatel credentilasprovider)
5.3.3. Chybová odpověď na UserInfo (služba credentilasprovider, zpracovatel credentilasprovider)

Správná struktura se všemi informacemi (například ověření informací o uživateli) musí být implementována v budoucnu.

Nastavení OpenID Connect v WebUI¶

Výchozí cesta pro službu OpenID connect je openidconnect. OpenID connect (oidc) může také obsahovat externí URL OpenID connect. V takovém případě je URL přepsána pomocí URL v parametru oidc. Externí URL OpenID connect musí začínat na http:// nebo https://

Pro podrobnosti o konfiguraci se prosím odkažte na TeskaLabs Wiki

JWT token¶

https://connect2id.com/learn/openid-connect

Uživatelská příručka

Nápověda k účtu¶

Potřebujete pomoc při změnách ve svém účtu?

Můžete spravovat svůj účet v aplikaci SeaCat Auth (UI).

Změnit údaje o účtu
Změnit heslo
Přidat hardwarový klíč pro přihlášení
Přidat autentifikační aplikaci pro zabezpečení

Portál SeaCat Auth pro přihlášení vám umožňuje se přihlásit, začít znovu a získat pomoc s heslem.

Pro přihlášení zadejte své přihlašovací údaje: uživatelské jméno, telefonní číslo nebo e-mail a heslo.

Můžete přidat OTP autentifikátor nebo hardwarový klíč pro zvýšení bezpečnosti přihlášení.

Pokud jste zapomněli nebo ztratili své heslo:

Na přihlašovací obrazovce klikněte na Nemůžete se přihlásit?
Zadejte, co používáte k přihlášení (uživatelské jméno, e-mailovou adresu nebo telefonní číslo).
SeaCat Auth vám zašle e-mail s odkazem pro obnovení hesla.

Můžete se odhlásit několika způsoby. Pokud dojde k vypršení vaší relace s aplikací, budete automaticky odhlášeni.

Možnosti odhlášení:

Přejděte na Můj účet a klikněte na Odhlásit se.
Přejděte na Můj účet > Spravovat a klikněte na Odhlásit se.
Chcete-li se odhlásit ze všech zařízení, přejděte na Můj účet > Spravovat a klikněte na Odhlásit se ze všech zařízení.

Změna podrobností o účtu¶

Své e-mailové adresy nebo telefonní číslo můžete změnit kdykoli. Pokud používáte svou e-mailovou adresu nebo telefonní číslo pro přihlášení, vaše přihlašovací údaje se odpovídajícím způsobem změní.

Změna e-mailové adresy¶

Přejděte na Můj účet > Spravovat.
Klikněte na Spravovat e-mailovou adresu.
Zadejte svou novou e-mailovou adresu a klikněte na Potvrdit.

Změna telefonního čísla¶

Přejděte na Můj účet > Spravovat.
Klikněte na Spravovat telefonní číslo.
Zadejte své nové telefonní číslo a klikněte na Potvrdit.

Obnovení vašeho hesla¶

Heslo můžete obnovit kdykoli.

Ve vašem účtu¶

Přejděte na Můj účet > Změnit heslo, nebo přejděte na Můj účet > Spravovat a klikněte na Změnit heslo.
Zadejte své stávající heslo, nové heslo a zopakujte nové heslo.
Klikněte na Nastavit heslo.

Změna zapomenutého hesla:¶

Pokud jste zapomněli nebo ztratili své heslo:

Na přihlašovací obrazovce klikněte na Nemůžete se přihlásit?
Zadejte, co používáte k přihlášení (uživatelské jméno, e-mailovou adresu nebo telefonní číslo).
SeaCat Auth vám zašle e-mail s odkazem pro obnovení vašeho hesla.

Přidání OTP (jednorázového PIN) autentizátoru¶

Pokud chcete mít další vrstvu zabezpečení (vícefaktorová autentizace), můžete do svého účtu přidat generátor jednorázového PIN, například aplikaci pro autentizaci. Když máte aktivní aplikaci pro autentizaci, budete muset při každém přihlášení zadat jednorázový PIN a své heslo (pokud nemáte také aktivní hardwarový klíč, v takovém případě si můžete vybrat při přihlášení).

Přidání OTP autentizátoru¶

Vyberte aplikaci pro OTP autentizaci.
Přejděte na Můj účet > Spravovat.
Klikněte na Spravovat jednorázový PIN (OTP).
Naskenujte QR kód pomocí své aplikace pro autentizaci.
Zadejte kód, který vaše aplikace pro autentizaci poskytuje, a klikněte na OK pro potvrzení.
Klikněte na Aktivovat OTP.
Dokud máte aktivní OTP autentizátor, potřebujete své heslo a jednorázový PIN pro přihlášení.

Odebrání OTP autentizátoru¶

Přejděte na Můj účet > Spravovat.
Klikněte na Spravovat jednorázový PIN (OTP).
Klikněte na Deaktivovat OTP a klikněte na OK pro potvrzení.
Nyní již nepotřebujete OTP pro přihlášení.

Nastavení hardwarového klíče¶

Můžete nastavit hardwarový klíč jako autentizátor pro přihlášení. Pokud máte nastavený hardwarový klíč, můžete jej použít k přihlášení místo vašeho hesla.

Registrace autentizátoru hardwarového klíče¶

Přejděte na Můj účet > Spravovat.
Klikněte na Spravovat FIDO2/WebAuthn.
Klikněte na Registrovat nového autentizátora.

4. Postupujte podle pokynů ve vašem prohlížeči, abyste potvrdili registraci vašeho nového autentizátoru hardwarového klíče.
5. Nyní můžete použít svůj hardwarový klíč k přihlášení.

Přejmenování autentizátoru¶

Přejděte na Můj účet > Spravovat.
Klikněte na Spravovat FIDO2/WebAuthn.
Klikněte na ikonu tužky vedle autentizátoru, který chcete přejmenovat.

4. Přejmenujte autentizátor a klikněte na Uložit.

Zrušení registrace autentizátoru¶

Přejděte na Můj účet > Spravovat.
Klikněte na Spravovat FIDO2/WebAuthn.
Vedle autentizátoru, který chcete zrušit, klikněte na Zrušit registraci autentizátoru.
Pro potvrzení klikněte na Ok. Hardwarový klíč je odstraněn z vašeho účtu.

Reference

Architektura SeaCat Auth¶

Služba ověřování
Služba autorizace
Služba API
Služba nájemce
Služba přihlašovacích údajů
Služba relací
Služba oznámení
Služba auditu
Služba OpenIDConnect
Služba provisioning
Služba Batman
Služba Bouncer

Komponenty SeaCat Auth¶

Tato sekce objasňuje role různých komponent v ekosystému SeaCat Auth.

Webové uživatelské rozhraní¶

Existují dvě samostatná webová uživatelská rozhraní (uživatelské rozhraní):

SeaCat WebUI poskytuje grafické rozhraní pro správu SeaCat Auth.
SeaCat Auth WebUI poskytuje přihlašovací formulář, obrazovku pro resetování hesla a další obrazovky pro běžné uživatele.

Docker a Docker Compose¶

Celá instalace webu může být dockerizována a nasazena pomocí docker-compose, viz rychlý start.

Nginx¶

Nginx se používá k přesměrování požadavků přicházejících zvenčí prostředí na chráněná místa. Tyto požadavky jsou nejprve přesměrovány na SeaCat Auth, kde je vyhodnocen jejich stav autentizace. Pokud je již autentizován, je požadavek povolen do chráněného prostoru.

MongoDB¶

Je používán SeaCat Auth pro ukládání známých uživatelů a dalších souvisejících trvalých dat.

Zdroje¶

Řízení přístupu založené na rolích (RBAC)¶

Přihlašovací údaje¶

Sada přihlašovacích údajů obvykle odpovídá uživatelskému účtu, ale může to být také strojové přihlašovací údaje.

Nájemce¶

Nájemce je "skupina uživatelů, kteří sdílejí společný přístup se specifickými oprávněními k instanci softwaru".
Může to být společnost, oddělení, tým atd.
Podle definice může mít nájemce více uživatelů (sad přihlašovacích údajů).
Uživatel se může připojit k několika nájemcům.

Role¶

Role je pojmenovaná sada zdrojů, používá se k udělení přístupu uživatele k těmto zdrojům.
Uživatel může mít více rolí.
Role může být přiřazena více uživatelům.
Role nájemce jsou platné pouze pro jednoho konkrétního nájemce.
Globální role jsou platné napříč všemi nájemci.

Zdroje¶

Zdroj je identifikátor skutečného softwarového zdroje nebo akce provedené na tomto zdroji.
Mít přístup k zdroji znamená mít práva k tomu, co představuje (blog:post:create, my-repository:write, my-app:access atd.)
Jakýkoli zdroj může být přiřazen několika rolím.
Role může mít více zdrojů.
Zdroje nemohou být přiřazeny přímo k přihlašovacím údajům; přihlašovací údaje mohou mít přístup k zdroji pouze prostřednictvím role.

SeaCat Auth administrativní zdroje¶

`authz:superuser`¶

`authz:tenant:access`¶

`authz:impersonate`¶

Klienti¶

Klient je entita, která využívá autentizační a autorizační služby poskytované autorizačním serverem. Tato autorizace umožňuje Klientovi přístup k chráněným zdrojům. V běžném scénáři je Klient webová aplikace a Vlastník zdroje je backendová aplikace umístěná na vzdáleném serveru.

Než Klient může požádat o autorizaci, musí se zaregistrovat na autorizačním serveru a získat jedinečné ID. Registraci lze provést buď v Admin UI, nebo prostřednictvím Admin API.

Metadata klienta¶

Aktuální seznam metadat klienta podporovaných Seacat Auth lze získat pomocí API GET /client/features.

Kanonická metadata OAuth 2.0 a OpenID Connect¶

Definováno v OpenID Connect Dynamic Client Registration 1.0 a OAuth 2.0 Dynamic Client Registration Protocol.

`client_id`¶

NENÍ EDITOVATELNÉ Jedinečné ID Klienta. Ve výchozím nastavení je to neprůhledný řetězec generovaný autorizačním serverem. Je možné požádat o vlastní ID poskytnutím nekanonického parametru preferred_client_id v žádosti o registraci klienta. ID není možné upravit, jakmile je klient již registrován.

`client_name`¶

POŽADOVÁNO Lidsky čitelný název Klienta, který bude předložen koncovému uživateli.

`client_secret`¶

Tajný řetězec klienta OAuth 2.0. Tato hodnota je používána důvěrnými klienty k autentizaci na koncovém bodě tokenu. Je generována autorizačním serverem a není přímo editovatelná.

`client_uri`¶

URL domovské stránky Klienta.

`redirect_uris`¶

POŽADOVÁNO Pole hodnot URI pro přesměrování používané Klientem.

`application_type`¶

Typ aplikace. Výchozí hodnota, pokud je vynecháno, je web.

Podporované možnosti: web

`response_types`¶

JSON pole obsahující seznam hodnot response_type OAuth 2.0, které Klient deklaruje, že se omezí na používání. Pokud je vynecháno, výchozí hodnota je, že Klient použije pouze Response Type code.

Podporované možnosti: code

`grant_types`¶

JSON pole obsahující seznam Grant Types OAuth 2.0, které Klient deklaruje, že se omezí na používání. Pokud je vynecháno, výchozí hodnota je, že Klient použije pouze Grant Type authorization_code.

Podporované možnosti: authorization_code

`token_endpoint_auth_method`¶

Požadovaná metoda autentizace Klienta pro koncový bod tokenu. Pokud je vynecháno, výchozí hodnota je none.

Podporované možnosti: none

`code_challenge_method`¶

Metoda výzvy kódu (používá se v Proof Key for Code Exchange (PKCE)) kterou se Klient omezí na používání na koncovém bodě autorizace. Výchozí hodnota, pokud je vynecháno, je none.

Podporované možnosti:

none: PKCE je zakázáno.
plain: Výzva kódu je stejná jako ověřovatel kódu.
S256: Výzva kódu je odvozena od ověřovatele kódu pomocí hashovacího algoritmu SHA-256.

Nekanonic metadata¶

Toto jsou specifické funkce pro Seacat-Auth.

`preferred_client_id`¶

POUZE REGISTRACE Požaduje konkrétní client_id místo náhodně generovaného při registraci klienta.

`redirect_uri_validation_method`¶

Specifikuje metodu, jakým je validováno URI pro přesměrování používané v autorizačních požadavcích. Výchozí a doporučená hodnota je full_match.

Podporované možnosti:

full_match: Jediná možnost vyhovující OAuth2.0. Požadované URI pro přesměrování musí přesně odpovídat jednomu z registrovaných URI pro přesměrování.
prefix_match: Požadované URI pro přesměrování musí začínat jedním z registrovaných URI pro přesměrování a jejich hostname musí přesně odpovídat.
none: Neprovádí se žádná validace URI pro přesměrování. Není bezpečné.

`cookie_name`¶

NENÍ EDITOVATELNÉ Jedinečný název cookie odvozený z ID Klienta autorizačním serverem. Cookie s tímto názvem uchovává informace

`cookie_webhook_uri`¶

Webhook URI pro nastavení dalších vlastních cookies na vstupním bodu cookie. Musí to být back-channel URI a musí přijímat JSON PUT požadavek a odpovídat JSON objektem cookies k nastavení.

`cookie_entry_uri`¶

Veřejné URI vstupního bodu cookie klienta. Toto pole je povinné pro autorizaci založenou na cookies (včetně autorizace batman). Takový vstupní bod by měl být dostupný na každém hostname, kde jsou Klienti, kteří používají autorizaci založenou na cookies.

`cookie_domain`¶

Doména cookie klienta. Pokud není specifikováno, použije se výchozí doména cookie aplikace.

`authorize_uri`¶

URL koncového bodu autorizace OAuth. Užitečné při přihlašování z jiného než výchozího doménového jména.

`login_uri`¶

URL preferované přihlašovací stránky. Užitečné při přihlašování z jiného než výchozího doménového jména.

`authorize_anonymous_users`¶

Boolean hodnota specifikující, zda autorizovat požadavky s anonymními uživateli.

`anonymous_cid`¶

ID přihlašovacích údajů, které se používá pro autentizaci anonymních relací.

`session_expiration`¶

Vypršení relace klienta. Hodnota může být buď počet sekund, nebo řetězec časové jednotky, jako je 4 h nebo 3 d.

Session¶

Objekt session představuje autentizaci a autorizaci uživatele nebo stroje.
Dva základní typy session jsou root a client. Klientské session mohou být buď na základě přístupového tokenu, nebo na základě cookie. Dále existují speciální typy session: machine-to-machine a anonymní session.

Single Sign-On session (alias "root session")¶

Vytváří se při přihlášení uživatele.
Používá se jako důkaz autentizace uživatele (Single Sign-On) pro požadavky na autorizaci OAuth.
Unikátně identifikována pomocí cookie prohlížeče (ve výchozím nastavení nazývána SeaCatSCI).

Klientská session (subsession)¶

Používá se jako důkaz autorizace uživatele a klienta.
Vytváří se jako výsledek úspěšného požadavku na autorizaci OAuth na koncovém bodě /openidconnect/authorize.
Odvozuje se od root session; uživatelská root session je předpokladem pro vytvoření klientské session pro toho uživatele.
Unikátně identifikována buď pomocí tokenů OAuth 2.0, nebo pomocí HTTP cookie.

Klientská session na základě přístupového tokenu¶

Vytváří se požadavkem na autorizaci na /openidconnect/authorize s openid ve scopě.
Vhodná pro klienty, kteří podporují protokol OAuth 2.0.
Unikátně identifikována pomocí přístupového tokenu OAuth 2.0.

Vytváří se požadavkem na autorizaci na /openidconnect/authorize s cookie ve scopě.
Vhodná pro klienty, kteří nepodporují protokol OAuth 2.0.
Unikátně identifikována pomocí cookie prohlížeče.

Machine-to-machine (M2M) session¶

Speciální typ root session, který zahrnuje autentizaci a autorizaci klienta.
Slouží jako důkaz autentizace a autorizace v komunikaci stroj-stroj (bez zapojení lidského uživatele).

Anonymní session¶

Speciální typ session, která identifikuje neautentizovaného uživatele.
Používá se pro sledování návštěvníků na klientských místech, která lze navštívit bez autentizace.
Je to klientská session, která může existovat bez root session. Anonymní root session se vytváří pouze tehdy, když je potřeba propojit více anonymních klientských session.

Životní cyklus session¶

Když se koncový uživatel úspěšně přihlásí, vytvoří se Single Sign-On (root) session. Obsahuje identifikátor uživatele a podrobnosti o procesu autentizace uživatele: kdy k autentizaci došlo, jaké prostředky autentizace byly použity atd. Obvykle má dlouhou životnost (několik dní až měsíců). Uživatel obdrží HTTP cookie, které identifikuje tuto SSO session.
Když chce uživatel přistupovat k aplikaci klienta, aplikace požádá server Seacat Auth o autorizaci k přístupu k datům koncového uživatele a dalším zdrojům, což se obvykle provádí pomocí toku autorizačního kódu OAuth 2.0. Prvním krokem toku je požadavek na autorizaci, který, pokud je úspěšný, produkuje krátkodobou (ne déle než několik minut) klientskou session a autorizační kód, který slouží jako identifikátor session. Session obsahuje odkaz na Single Sign-On session koncového uživatele a podrobnosti o autorizaci, jako je identifikátor aplikace klienta (client ID) a požadovaný rozsah autorizace.
Klientská aplikace poté používá autorizační kód k provedení požadavku na token. Pokud je úspěšný, tento požadavek spotřebovává autorizační kód a produkuje sadu dlouhodobějších tokenů - přístupový token a ID token, které jsou platné několik hodin, a refresh token, který je platný několik dní až týdnů. Klientská session je prodloužena tak, aby trvala tak dlouho, jak refresh token, a aktualizována tak, aby obsahovala aktuální informace o uživateli a jejich autorizovaném tenantovi a zdrojích.
Klientská aplikace poté neustále používá přístupový token jako důkaz autorizace pro aplikace vlastníka zdrojů. Například frontendová aplikace Web UI (klient) posílá přístupový token s každým požadavkem REST API na backendovou aplikaci (vlastník zdrojů). Vlastník zdrojů může požádat autorizační server o ověření přístupového tokenu v tzv. introspekčním požadavku.
Když přístupový token vyprší, klientská aplikace může požádat o nový pomocí refresh tokenu. Tento požadavek vede k vydání nové sady tokenů (přístupový, refresh a ID) a klientská session je opět prodloužena, aby odpovídala novému refresh tokenu.
Když klientská session vyprší nebo když klient požádá o její ukončení, session je smazána spolu se všemi jejími aktivními tokeny.
Když vyprší Single Sign-On session nebo když se koncový uživatel odhlásí, session je neplatná a smazána spolu se svým cookie, spolu se všemi klientskými session, které byly otevřeny pod touto Single Sign-On session a jejich tokeny.

Úvod

O TeskaLabs SeaCat Auth¶

Uživatelské rozhraní SeaCat Auth¶

Hlavní funkce TeskaLabs SeaCat Auth¶

Autentizace¶

Autorizace¶

Správa identit¶

Obecné¶

Uživatelské rozhraní¶

Webové uživatelské rozhraní pro uživatele¶

Webové uživatelské rozhraní pro administrátory¶

Administrační manuál

Příručka pro správu¶

Řízení přístupů

Řízení přístupu¶

Klíčové pojmy¶

Přihlašovací údaje¶

Nájemce¶

Zdroje¶

Role¶

Klient¶

Relace¶

Přihlašovací údaje¶

Stránka přihlašovacích údajů¶

Vytvoření nových přihlašovacích údajů¶

Hromadné akce¶

Nájemci¶

Vytvoření nájemce¶

Přidání přihlašovacích údajů k nájemci¶

Zdroje¶

Vytvoření zdroje¶

Smazané zdroje¶

Zahrnuté zdroje¶

Role¶

Vytvoření role¶

Úprava rolí¶

Klienti¶

Stránka klientů¶

Relace¶

Ukončení relace¶

Instalace

Rychlý start¶

Požadavky¶

Krok 1: Vytvoření nasazovacího adresáře¶

Krok 2: Úprava konfigurace SeaCat Auth¶

Krok 3: Instalace webových uživatelských rozhraní¶

Krok 4: Spuštění SeaCat Auth¶

Další kroky¶

Nasazení SeaCat Auth s vlastním hostname a HTTPS¶

Vlastní hostname na localhostu¶

Režim provisioning¶

Mód poskytování¶

Spuštění SeaCat Auth v módu poskytování¶

Přihlášení¶

Nastavení prostředí¶

Zakázání módu poskytování¶

Konfigurace

Minimální požadovaná konfigurace¶

Příklad konfiguračního souboru¶

Credentials

Přihlašovací údaje¶

Politika přihlašovacích údajů¶

Konfigurace¶

Možnosti politiky¶

Příklad souboru politiky¶

Poskytovatelé přihlašovacích údajů¶

MongoDB¶

Příklad konfigurace¶

Externí MongoDB (xmongodb)¶

Příklad konfigurace¶

LDAP / ActiveDirectory¶

Příklad konfigurace¶

MySQL¶

Poskytovatel pouze pro čtení¶

Příklad konfigurace¶

Editovatelný poskytovatel¶

Příklad konfigurace¶

Htpasswd¶

Příklad konfigurace¶

V paměti (Slovník)¶

Webové uživatelské rozhraní pro uživatele ¶

Webové uživatelské rozhraní pro administrátory ¶

Externí MongoDB (`xmongodb`)¶