Senaryo: Bireysel Kullanıcı Kaydı, Kimlik Yönetimi ve Workspace'e Giriş

Kayıttan organizasyon üyeliğine ve kontrollü ayrılışa uzanan kullanıcı yaşam döngüsü.

Özet

EventInn'in ana giriş kapısı: bir kişinin platformu keşfinden kayıt-kimlik-giriş zincirine, kişisel çalışma bağlamından organizasyona katılıma/ayrılığa uzanan uçtan-uca üyelik yolculuğu. CEO seçim-gerekçesi: "Ana sayfada ne olduğundan bağımsız, en temel senaryo olduğu için bunu seçtim."

Temel ilke: Kullanıcının kimliği kalıcıdır; organizasyon ilişkileri, roller ve çalışma bağlamları değişebilir. Bir organizasyon üyeliğinin sona ermesi, kişinin EventInn kimliğini veya diğer organizasyon ilişkilerini sona erdirmez.

Karar-Kapsamı (bu kaydın kabulü NEYİ kabul eder?)

Senaryo-kabulü = yolculuğun kapsam + hedef-sonuç kabulüdür. Şunların KABULÜ DEĞİLDİR:

• 21-UC'nin tek tek detayları (her UC kendi kaydıyla karara gelir),
• bireysel-tenant modeli (ADR-konusu),
• mevcut veri-modelinin korunacağı,
• Google-linking çözümü,
• geliştirme-başlangıcı (implementasyon ayrı kapı).

Aktörler ve bağlam

• Ana aktör: bireysel kullanıcı (gerçek kişi).
• Yardımcı aktörler: Google Identity Provider · EventInn Kimlik-Erişim sistemi · bildirim/e-posta altyapısı · organizasyon yöneticisi/sahibi · platform güvenlik-operasyon.
• Başlangıç durumu: kişi platformda hesapsızdır; e-posta/parola veya Google ile kayıt olabilir.

Temel domain ayrımları (10 kavram — aynı şey DEĞİLLER)

1. Person — gerçek insan; gereksiz mükerrer person YASAK (güvenli-mükerrer-yönetimi aşağıda).
2. Account — durumlu hesap: aktif / askıda / kilitli / kapatma-talebi.
3. Authentication identity — parola / Google / ileride diğerleri; bir hesaba birden çok yöntem bağlanabilir.
4. Session — anlık doğrulanmış erişim; kimlik DEĞİL, hesabın o anki oturum-hali.
5. Organization — tüzel/iş varlığı.
6. Membership — kişi↔organizasyon ilişkisi: davet-edildi / aktif / askıda / ayrıldı / iptal.
7. Role-Capability — üyelik üzerindeki yetki-bileşimi.
8. Workspace — o anki iş-bağlamı; kimlik DEĞİL.
9. Tenant — teknik izolasyon sınırı; iş-kavramı değil, veri-ayrımı düzlemi.
10. Resource-scope — yetkinin hangi kaynak-kümesine uygulandığı.

Kimlik-eşleme ve güvenli mükerrer-yönetimi

"Tek person" mutlak-kural değil, güvenli mükerrer-yönetimi hedefidir:

• Kimlik-anahtarı = provider_issuer + provider_subject (e-posta DEĞİL; email_verified=true yalnız SİNYALDİR, anahtar değildir).
• Eşleşme üç-durumlu değerlendirilir: confirmed_same_identity / suspected_duplicate / distinct_accounts.
• Yeterli kanıt olmadan otomatik hesap-birleştirme YASAK (birleştirme-ile-hesap-gaspı istisna-listesi maddesidir).

Senaryo akışı (özü)

1. Kişi EventInn'i keşfeder; e-posta/parola veya Google ile kayıt olur.
2. Kayıt tamamlandığında EventInn kişiyi kalıcı ve tekil bir gerçek-kişi kimliği olarak tanır.
3. Kullanıcı kendi hesap sayfasına ve kişisel çalışma bağlamına yönlendirilir; profil/güvenlik yönetir, kendi adına etkinlik projeleri başlatabilir.
4. Davet edildiği organizasyonları görür; kişisel↔kurumsal bağlamlar arasında geçiş yapar.
5. Sonradan organizasyona katılabilir/kurabilir, rol-yetki alabilir.
6. İlişki sona erdiğinde kişisel hesap SİLİNMEZ — yalnız o organizasyondaki üyelik/rol/yetkiler kapanır; yönettiği kurumsal işler uygun kişilere devredilir.

Kapsanan use-case'ler (21 UC — harita)

UC-01 kayıt-başlatma · UC-02 e-posta ve parola ile kayıt (e-posta mevcutsa yeni-person AÇMA → giriş/kurtarmaya yönlendir; username pilot-kapsamı-DIŞIDIR — giriş salt-e-posta) · UC-03 Google-kayıt (sessiz e-posta-eşleşme-birleştirmesi YASAK) · UC-04 parola-giriş · UC-05 Google-giriş (bağlı değilse güvenli kayıt/bağlama-akışı) · UC-06 mevcut-hesaba-Google-bağlama (re-auth + başka-hesaba-bağlıysa otomatik-taşıma YASAK + audit + bildirim) · UC-07 mükerrer-hesap-önleme (güvenli-mükerrer-yönetimi kurallarıyla; §Kimlik-eşleme) · UC-08 onboarding (şirket kurmaya / kalıcı tip seçmeye ZORLANMAZ) · UC-09 hesap-sayfası (profil / giriş-yöntemleri / güvenlik / oturumlar / bildirim / organizasyonlar / davetler / workspace'ler / kapatma-veri-talepleri) · UC-10 kişisel çalışma-bağlamı (org'suz çalışabilme; taslak brief/shortlist; teknik-modeli ADR'ye AÇIK-SORU) · UC-11 varsayılan-başlangıç-bağlamı (ilk=onboarding · tek-ws=o · çok-ws=son-kullanılan · erişim-bitti=güvenli-kişisel · davet-varsa-bildirim) · UC-12 organizasyon-oluşturma (kişisel kimlik org-kimliğine DÖNÜŞMEZ) · UC-13 davet-alma-kabul · UC-14 bağlam-geçişi (eski-ws yetkileri yeniye TAŞINMAZ) · UC-15 ws-bazlı rol-capability (yetki = membership+role+capability+resource-scope+policy bileşimi) · UC-16 son-ws-hatırlama (erişim bittiyse açma + açıkla) · UC-17 üyelik-sonlanması (kişisel hesap korunur) · UC-18 rol ve iş-varlığı devri (kritik devir tamamlanmadan kapanış bloke edilebilir) · UC-19 hesap-kurtarma · UC-20 Google-kaldırma (önkoşul: başka doğrulanmış yöntem) · UC-21 hesap-kapatma (senaryo-2 adayı — §Ek-UC tablosu; membership-termination ≠ account-closure).

7-küme yapısı (UC-kayıt üretim-kümeleri)

Kayıt-üretimi bu kümelerle dispatch edilir; AI-CEO/Müdür incelemesinden gelen zorunlu-analiz başlıkları kümelere işlenmiştir:

1. Kayıt ve rıza/hukuk-yönetimi — UC-01, UC-02, UC-08. + Rıza-yönetimi başlığı: KVKK-consent kodda VAR (kayıt-anı kvkk_consent_at); kural-olarak yazılacak.
2. Giriş, oturum ve kimlik-doğrulama güvenliği — UC-04, UC-19, UC-24. + Güvenlik-listesi: brute-force koruması · hesap-enumeration önleme (kayıt/reset yanıt-eşitliği) · reset-token güvenliği (tek-kullanım, süre, tahmin-dirençli) · re-auth (hassas işlemler önünde yeniden-doğrulama).
3. Kimlik-bağlama (Google/OIDC) — UC-03, UC-05, UC-06, UC-07, UC-20. + OIDC-kontrolleri: state · nonce · redirect-URI doğrulaması · issuer+subject anahtar-doğrulaması.
4. Hesap-sayfası ve kişisel çalışma-bağlamı — UC-09, UC-10, UC-11.
5. Organizasyon ve davet — UC-12, UC-13 (+UC-25 dilim-1B'de).
6. Bağlam-geçişi ve yetki — UC-14, UC-15, UC-16, UC-26. + Kural: yetkisiz-workspace-erişimi backend'de reddedilir — UI-switcher güvenlik-mekanizması DEĞİLDİR.
7. Üyelik-sonlanması ve devir — UC-17, UC-18 (+UC-28 dilim-1C'de). UC-21 hesap-kapatma senaryo-2 adayıdır.

Pilot dikey-dilimleri (1A / 1B / 1C)

Her dilim UCDEP-uyumlu bağımsız readiness + kabul-kapısı taşır:

• Pilot-1A — Bireysel çekirdek: kayıt → kimlik → giriş → hesap-sayfası → kişisel-bağlam (küme 1-4 çekirdeği).
• Pilot-1B — Kurumsal katılım: organizasyon-oluşturma → davet-yaşam-döngüsü (UC-25 dahil) → bağlam-geçişi + yetki (küme 5-6).
• Pilot-1C — Kontrollü ayrılış: üyelik-sonlanması → devir-doğrulama → son-owner-bloğu (UC-28 dahil) (küme 7).

Ek-UC değerlendirme tablosu (AI-CEO önerileri — Müdür-kalibrasyonu: hepsi pilota GİRMEZ)

UC	Konu	Karar
UC-30	İdempotent olay-işleme	Pilota kural olarak (çift-işlenen-olay istisnasının kuralı; 🔴 reuse-not: HasIdempotencyKey trait mevcut-kodda VAR)
UC-24	Hassas-işlem öncesi re-auth	Pilota kural olarak (küme-2)
UC-26	Yetkisiz-workspace backend-reddi	Pilota kural olarak (küme-6)
UC-25	Davet yaşam-döngüsü (süre/iptal/yeniden-gönderim)	Dilim-1B
UC-28	Son-owner ayrılış-bloğu	Dilim-1C
UC-22	E-posta değişimi	PARK (sonraki-dilim/senaryo-2)
UC-23	Aktif-oturumlar ekranı + uzaktan-kapatma	PARK
UC-27	Hesap askıya-alma (güvenlik-operasyon)	PARK
UC-29	Veri dışa-aktarma (KVKK)	PARK
UC-21	Hesap-kapatma	Senaryo-2 adayı — membership-termination ≠ account-closure; bu senaryo üyelik-sonlanmasını kapsar, hesap-kapatma ayrı yolculuktur

Kritik istisna / kötüye-kullanım listesi (35 madde — analiz-girdisi)

1. Aynı e-posta ile çift-yöntem (parola + Google).
2. Google-alias e-posta varyantları.
3. Google-identity'nin başka hesaba bağlı olması.
4. Davet e-postası ≠ kayıt e-postası.
5. Çoklu organizasyon üyeliği.
6. Erişimi kalkan son-workspace.
7. Sahibin devirsiz ayrılması.
8. Ayrılan çalışanın erişimi.
9. Kişisel→kurumsal yanlış aktarım.
10. Kurumsal→kişisel veri sızıntısı.
11. Çalınmış Google hesabı.
12. Birleştirme yoluyla hesap gaspı.
13. Davet linkinin başkası tarafından kullanımı.
14. Workspace değişiminde eski tenant/cache kalıntısı.
15. Kapanan membership'in açık oturumu.
16. Çift işlenen olay (duplicate event).
17. Devirsiz sahipsiz kalan varlık.
18. Credential-stuffing / parola-püskürtme (password-spray).
19. Brute-force parola denemesi (tek-hesap odaklı).
20. Hesap-enumeration (kayıt/giriş/reset yanıt-farklarından hesap-varlığı sızması).
21. Reset-token tahmini, tekrar-kullanımı veya süresiz-geçerliliği.
22. Reset-linkinin yanlış kanala/kişiye gitmesi.
23. Oturum-sabitleme (session fixation).
24. Oturum-çalma (session hijacking — çerez/token sızıntısı).
25. Yetki-değişiminde oturumun yeniden-üretilmemesi (privilege-change sonrası eski oturum).
26. CSRF ile kimlik-bağlama/kritik-işlem tetikleme.
27. OAuth authorization-code'un ele geçirilmesi / tekrar-oynatılması (code interception/replay).
28. state parametresi eksikliği/doğrulanmaması (OAuth CSRF).
29. nonce tekrar-oynatması (ID-token replay).
30. Redirect-URI manipülasyonu (open-redirect üzerinden token-sızdırma).
31. IdP mix-up (yanlış sağlayıcıya kimlik-teslimi).
32. Rıza-ekranı oltalaması (consent-phishing).
33. Token/oturum-kimliklerinin log/URL üzerinden sızması.
34. Refresh-token çalınması ve uzun-ömürlü kötüye-kullanım.
35. Davet-token brute-force / davet-linki enumeration.

İlk pilot sınırı

Kapsam: kayıt → kimlik → giriş → hesap-sayfası → kişisel-bağlam → davet-kabul → kurumsal-ws-geçiş → üyelik-kapatma → devir-doğrulama. Kapsam-dışı: ödeme/abonelik · venue-onboarding · gelişmiş RFQ · broker · impersonation · enterprise-SSO · SCIM · çoklu-IdP · username-ile-giriş · hesap-kapatma (UC-21, senaryo-2).

Pilot başarı kriterleri (20 madde)

1. Tek kişi, çift kayıt-yönteminde iki person'a bölünmez (güvenli-mükerrer-yönetimi kurallarıyla).
2. Organizasyonsuz kayıt ve çalışma mümkündür.
3. Kişisel ≠ kurumsal bağlam ayrımı her yüzeyde korunur.
4. Çoklu-workspace görünür ve gezilebilirdir.
5. Bağlam-geçişinde veri ve yetki izolasyonu tamdır (taşıma/sızıntı yok).
6. Kişisel hesap, üyelik-sonlanmasında korunur.
7. Kritik görev/varlık sahipsiz kalmaz (devir-doğrulama).
8. Kimlik-yetki değişimleri audit-izlidir.
9. Senaryo→UC→kural→ADR→uygulama→test→kanıt zinciri kurulur.
10. E-posta mevcutken ikinci person açılmaz; kullanıcı giriş/kurtarmaya yönlendirilir.
11. Sessiz e-posta-eşleşme-birleştirmesi hiçbir akışta yoktur.
12. Kimlik-bağlama yalnız re-auth sonrası ve audit+bildirimle gerçekleşir.
13. Google-kaldırma yalnız başka doğrulanmış yöntem varken mümkündür.
14. Onboarding, kullanıcıyı şirket-kurmaya veya kalıcı-tip-seçmeye zorlamaz.
15. Davet-kabul, davet-durum-makinesine uyar (süresi-geçmiş/iptal-edilmiş davet kabul edilemez).
16. Yetkisiz-workspace erişimi BACKEND'de reddedilir (UI-gizleme yeterli sayılmaz).
17. Hassas işlemler re-auth gerektirir.
18. Olay-işleme idempotenttir (çift-olay çift-etki üretmez).
19. Erişim-sonlandırma SLA-çerçevesi: membership sonlanınca — yeni istek = HEMEN red · access-token ≤ X dk içinde geçersiz · refresh-token = DERHAL iptal · uzun-ömürlü bağlantılar ≤ Y sn içinde düşürülür (X/Y değerleri ilgili ADR'de bağlanır).
20. Kimlik-doğrulama yüzeyleri enumeration-dirençlidir (yanıt-eşitliği) ve brute-force korumalıdır.

Muhtemel ADR başlıkları (UC + kural kabulünden SONRA yazılır; numara registry'den — sıradaki boş CAN-DEC-ADR-NNN)

• Person / account / identity ayrımı ve veri-modeli.
• Google-OAuth bağlama + güvenli-mükerrer-yönetimi (issuer+subject anahtarı).
• Kişisel-bağlam modeli.
• Bireysel-tenant gerekli mi (AI-CEO temkini: otomatik-tenant varsayım değil; yer-gerçeği: mevcut sistem kayıt anında taze-tenant açıyor, users.tenant_id NOT NULL — soru "koru mu?").
• Organization–membership–workspace ilişkisi.
• Context-switch + yetki-kapsamı.
• Offboarding + devir.
• Audit ve güvenlik-olayları.
• Session/token yaşam-döngüsü (SLA X/Y değerleri dahil).
• Davet ve membership state-machine.
• Account-lifecycle ve veri-saklama (senaryo-2 hazırlığı).

Bağımlılıklar (CAN-GOV-UCDEP-001 standardı)

Bağımlılık-listesi bu taslakta BEYAN EDİLMEMİŞTİR (boş-alan-yazılmaz kalibrasyonu): Canon karar-bağımlılıkları henüz kayıt olmayan ADR-başlıklarına işaret eder; uygulama-bağımlılıkları 7-küme UC-kayıtlarıyla birlikte, mevcut-kod gerçeklik-denetimi (Pilot-1 7-küme denetimi, 2 Tem) referans alınarak beyan edilecektir. readiness.definition: draftable — decision_ready İLANI, bağımlılık-beyanının gerçeklik-denetimi (Pre-Audit) sonrasına aittir (UCDEP §Bağımlılık-beyanı doğrulaması). extensions.analysis_status yalnız inceleme-anlarında ve kanıt-referanslı commit ile güncellenir (UCDEP §Kanıttan-türetilen durum ruhu).

İzlenebilirlik

upstream: CAN-STR-PHASES-001 (stratejik-işletme-kaynağı — senaryonun İŞ-gerekçesi bu fazlama-stratejisinden gelir). governed_by: CAN-GOV-UCDEP-001 (senaryo bu standardın KURALLARINA tabidir — kaynak değil, yönetişim-çerçevesi). Kaynak: strategy/proposals/pilot1_uyelik_senaryosu_ceo_kaynak_metni_v1.md (CEO chat-metni birebir arşivi, 2 Tem 2026) + AI-CEO senaryo-incelemesi (3 Tem 2026, Müdür-kalibrasyonlu REV-1) — otorite bu Canon-kaydındadır. downstream: türetilir, elle yazılmaz (7-küme UC-kayıtları geldiğinde oluşacaktır).

---

CAN-REQ-SCN-001 · requirements/normative · governance_status: accepted (Human-CEO KAPSAM-kabulü, 3 Tem 2026 — §Karar-Kapsamı geçerli; yürürlük/effective AYRI kapı) · scenario v1 REV-1 (AI-CEO incelemesi + Müdür-kalibrasyonu işlendi, 3 Tem 2026; kaynak: Human-CEO senaryo-anlatımı, 2 Tem 2026).