Kompetencje · Dostęp i uprawnienia
Zakres obejmuje system autoryzacji zbudowany pod jedną uzgodnioną aplikację: konta, role, uprawnienia do ekranów, akcji i danych oraz sesję i token w oprogramowaniu. TensorFrog dostarcza warstwę dostępu w uzgodnionym modelu. Nie prowadzi logowania jako usługi dla wielu organizacji i nie zastępuje publicznego dostawcy tożsamości. Pierwszy etap: jedna aplikacja, jeden model uprawnień, wycena przed budową. Kontakt: [email protected].
Autoryzacja
To oprogramowanie dostępu do konkretnego rozwiązania: kto wchodzi, jaką ma rolę i co wolno na ekranie, w akcji albo na zbiorze danych. Model ustala się pod proces tej aplikacji — nie jako uniwersalna usługa logowania dla wielu produktów. TensorFrog buduje warstwę na uzgodniony zakres. Konta, sesja i token zostają w oprogramowaniu utrzymywanym z tą aplikacją. To nie jest publiczna usługa tożsamości ani abonament logowania dla wielu firm.
Cel i sposób pomiaru ustalamy wspólnie przed startem prac. Nie obiecujemy procentów oszczędności bez pomiaru stanu obecnego.
Użytkownik ma konto. Rola to nazwany zestaw uprawnień: odczyt, zapis, zatwierdzenie, eksport, administracja nadań. Uprawnienie jest sprawdzane na granicy: ekran, akcja albo zakres danych (własne rekordy, dział, całość — według procesu). Jedna osoba może mieć kilka ról, gdy tak stanowi model. Rola nie jest opinią w arkuszu: system odmawia operacji, której rola nie ma. Słownik ról i uprawnień ustala się przed budową; kolejna rola albo nowy zakres danych to osobny etap.
Pierwszy zakres dotyczy jednej aplikacji i jednego modelu uprawnień. Ekrany, akcje i dane biorą się z tego procesu — nie z katalogu uniwersalnych reguł. Druga aplikacja, drugi model albo wspólny katalog ról dla wielu systemów nie wchodzą w pierwszy etap. Integracja z istniejącym katalogiem kont firmy jest możliwa, gdy taki katalog jest w ofercie i ma opisany kontrakt. Decyzja o zakresie tożsamości zapada w wycenie, nie jako domyślna usługa.
Panel dla wskazanej roli administracyjnej wchodzi, gdy jest w zakresie: lista kont, nadanie i odebranie roli, podgląd bieżących uprawnień. Wniosek o dostęp i akceptacja — gdy proces tego wymaga. Osoba administrująca widzi, kto ma jaką rolę; nie widzi danych operacyjnych poza uzgodnionym zakresem. Panel nie zastępuje aplikacji, do której dostęp jest nadawany. Bez panelu nadania idą przez uzgodniony kanał (API albo import) — to osobna decyzja w ofercie.
Uzgodniona aplikacja woła warstwę dostępu przez API: kim jest użytkownik, jakie ma role, czy wskazana akcja jest dozwolona, jaki jest zakres danych. Odpowiedź wraca do tej samej sesji. Kontrakt opisuje typ sprawdzenia, identyfikator konta, kod uprawnienia i wynik. Sesja i token są częścią oprogramowania — wydanie, odświeżenie, wygaśnięcie i unieważnienie. Każde sprawdzenie ma limit i log. Baza — PostgreSQL, MSSQL albo MariaDB, według stacku aplikacji — trzyma konta, role, nadania i ślad. TensorFrog nie wydaje tokenów jako osobnej usługi poza tą aplikacją.
Zmiana roli, nadanie, odebranie, start sesji i nieudane sprawdzenie uprawnienia zostawiają ślad: kto, komu, jaką rolę albo jakie uprawnienie, kiedy, z jakiego źródła. Osoba administrująca widzi historię nadań. Osoba audytująca — gdy taka rola jest w modelu — widzi ten sam rejestr bez prawa do zmiany. Retencja logu według uzgodnionej polityki. To ślad w oprogramowaniu, które organizacja utrzymuje — nie zastępuje procedury prawnej ani rejestru państwowego.
Jedna aplikacja, jeden model uprawnień, wycena przed budową. Konta, dwie albo trzy role, sprawdzenie na uzgodnionych ekranach i akcjach, sesja i token, ślad nadania i odebrania. Panel administratora nadań — gdy jest w tej ofercie. Po odbiorze decyzja: kolejne role, zakres danych, wniosek o dostęp, druga aplikacja albo import z istniejącego katalogu kont — każda rzecz z osobną wyceną.
Opisz potrzebę biznesową — zaproponujemy technologię i kolejne etapy prac. Kontakt: [email protected]
Przejdź do kontaktuZobacz wszystkie kompetencje
