Tenant separerar organisationer och data. Project väljer medlemskap, schema och körningsomfång inom tenant. Aktivt Project är ett signerat och servervaliderat sessionsbeslut, inte ett kosmetiskt filter.
Säkerhet och styrning
Säkerhetsbeslut förblir serverägda och omfångsbundna.
Synlighet i webbläsaren är inte en behörighetsgräns. Skyddade routes, applikationstjänster och repository-predikat utvärderar identitet, tenant, projekt och behörighetskontext på nytt när operationen kräver det.
Säkerhet och styrning
Varje autentiserad begäran måste stämma med ett aktivt aktörsbundet JTI i registret, tenant- och användartillstånd, aktuell policygiltighet, inaktivitetstimeout och aktiv Project-kontext. Registerfel, saknat signeringsmaterial, återkallelse eller identitetsavvikelse stängs säkert i stället för att falla tillbaka till anonym eller inaktuell webbläsarkontext.
SAML-metadata, inloggning och ACS per tenant, länkning/JIT av extern identitet, domänpolicy och MFA-evidens intygad av IdP är implementerade. Endpoint-generering använder det serverägda publika ursprunget och AuthnRequest-korrelation använder kortlivad, signerad och provider-/request-bunden state.
Analytics RLS är serverägd och skyddad. Ett runtime-filter från klienten kan inte förfalska metadata om RLS-ursprung, och cache-identiteter omfattar behörighets- och RLS-omfång i stället för att enbart förlita sig på SQL-text.
Inloggningsuppgifter, tokens, authorization headers, privata nycklar och material för signerade URL:er hör inte hemma i publika metadata, chatprompter eller generella audit-payloads. Maskerad text är inte en användbar inloggningsuppgift. Engångsvis visning är avgränsad, skyddad enligt konfiguration, kortlivad och registrerad utan att hemligheten sparas i generell evidens.
Tenant och Project är aktiv säkerhetskontext.
Tenant separerar organisationer och data. Project väljer medlemskap, schema och körningsomfång inom tenant. Aktivt Project är ett signerat och servervaliderat sessionsbeslut, inte ett kosmetiskt filter.
Sessionsregistret är auktoritativt efter inloggning.
Varje autentiserad begäran måste stämma med ett aktivt aktörsbundet JTI i registret, tenant- och användartillstånd, aktuell policygiltighet, inaktivitetstimeout och aktiv Project-kontext. Registerfel, saknat signeringsmaterial, återkallelse eller identitetsavvikelse stängs säkert i stället för att falla tillbaka till anonym eller inaktuell webbläsarkontext.
Project-byte är en CSRF-skyddad serveråtgärd som utfärdar ny kontext utan att förlänga den ursprungliga token- eller policygiltigheten.
Utloggning sker med en CSRF-skyddad POST; lösenordsbyte, lösenordsåterställning och kontoborttagning återkallar aktiva sessioner.
JSON-begäranden får strukturerat autentiseringsfel och borttagning av cookies; webbläsarnavigering rensar kontexten före omdirigering.
SAML levereras med tydliga avgränsningar.
SAML-metadata, inloggning och ACS per tenant, länkning/JIT av extern identitet, domänpolicy och MFA-evidens intygad av IdP är implementerade. Endpoint-generering använder det serverägda publika ursprunget och AuthnRequest-korrelation använder kortlivad, signerad och provider-/request-bunden state.
SAML skapar inte Project-medlemskap; användaren behöver fortfarande behörig tenant- och projektåtkomst.
TOTP, WebAuthn, återställningsutmaningar och ett fullständigt gränssnitt för sessionsinventering och återkallning i applikationen är inte aktuella funktioner.
En lösenords-MFA-policy som inte stöds avvisas i stället för att lagras som en falsk kontroll.
RLS och runtime-filter är inte utbytbara.
Analytics RLS är serverägd och skyddad. Ett runtime-filter från klienten kan inte förfalska metadata om RLS-ursprung, och cache-identiteter omfattar behörighets- och RLS-omfång i stället för att enbart förlita sig på SQL-text.
Hemligheter hålls utanför generell evidens.
Inloggningsuppgifter, tokens, authorization headers, privata nycklar och material för signerade URL:er hör inte hemma i publika metadata, chatprompter eller generella audit-payloads. Maskerad text är inte en användbar inloggningsuppgift. Engångsvis visning är avgränsad, skyddad enligt konfiguration, kortlivad och registrerad utan att hemligheten sparas i generell evidens.
Aktuell IAM-styrka anges exakt.
Modulspecifika behörighetskontrakt finns, men en universell beständig negativ behörighet och plattformsövergripande DENY-wins-sammanslagning är inte färdig. MFA- och step-up-beteende i applikationen får inte antydas utöver de nuvarande identitetsleverantörs- och sessionskontrollerna.
Nästa steg
Börja med flödet där tvetydighet inte får förekomma.
Ta med de system, ansvariga, regler, leveranskrav och evidenskrav som är viktiga.
Diskutera ett kritiskt flöde