V každé aplikaci, ve které se vyskytují uživatele, je typicky nutné nějakým způsobem řešit úkony jako autentizaci a autorizaci uživatelů, registraci uživatelů nebo správu uživatelů administrátorem aplikace, nějakou forma obnovení hesla, nastavení a správu oprávnění uživatelů, blokování účtu při pokusu o jeho prolomení, možnost zapamatování přihlášení a další.
Na stráně databáze to pak znamená ukládat kromě uživatelů samotných i jejich přihlašovací informace nebo vazbu na externí systém, ze kterého uživatelé pochází, nastavení jejich oprávnění, informaci o blokaci jejich účtů, počtu neplatných pokusu o změnu hesla, informaci o posledním přihlášení, historii použitých hesel apod.
V naší společnosti jsme pro výše uvedené úkoly vyvinuli vlastní samostatnou komponentu nazvanou IMP.Security, která je je snaží řešit obecně.
Tato komponenta přitom není omezena pouze pro ASP.NET aplikace, ale je použitelná i například ve WPF aplikacích a existuje ve verzi pro .NET Framework 4 i pro .NET Framework 4.5. Také jsem již v minulosti naznačil, že použití forms autentizace v kombinaci s membership providerem je v současnosti v praxi mnohdy již nedostačující. To je hlavní důvod proč současná verze komponenty IMP.Security již forms autentizaci ani memberhip provider model nepoužívá a místo toho interně využívá Windows Identity Foundation (WIF).
Součástí zmíněné komponenty je s výjimkou tabulky pro vlastní uživatele (*) i definice jinak v podstatě jednotného databázového schéma, které bych chtěl v tomto článku ukázat.
Toto databázové schéma má následující podobu:
(klikněte na obrázek pro zvětšení)
V některých aspektech se toto schéma liší od toho používaného například ve výchozím Membership/Role provideru nebo případně novějších ASP.NET Universal Providers.
Schéma je navrženo pro podporu těchto klíčových vlastností:
- V jedné databázi může být zavedeno více aplikací používající stejnou sadu uživatelů (single sign-on), ale jinou sadu oprávnění.
- Nastavení jednotlivých oprávnění není vázáno přímo na uživatele, ale na profil práv. Uživatele se stejným oprávněním pak jednoduše mají navolen stejný profil práv.
- Databáze podporuje uložit pro každého uživatele více přihlašovacích účtů.
- Existuje více typů uživatelských účtů. Kromě “standardního” přihlašování uživatelským jménem a heslem (aplikační účet), lze uložit i Windows přihlášení nebo jinou vazbu na externí systém.
- Datum a čas posledního přihlášení uživatele se udržuje pro každý typ přihlašovacího účtu samostatně.
- U aplikačního účtu lze udržovat datum poslední změny hesla, počet neplatných pokusu o změnu hesla, čas posledního takového pokusu nebo příznak o uzamčení účtu.
- Pro obnovení zapomenutého hesla lze k účtu uložit jedinečný kód s omezenou časovou platností.
- Lze uložit historii uživatelem dříve použitých hesel.
(*) Vlastní názvy tabulek a jejích sloupců se mohou v případě potřeby konkrétní aplikace od uvedeného “referenčního” schéma lišit.