Poniżej przedstawiono kilka przykładowych sposobów, w jakie użytkownicy zazwyczaj korzystają z Identity Applications w organizacji.
Ella (użytkownik końcowy) odzyskuje zapomniane hasło za pomocą funkcji samoobsługi tożsamości podczas logowania.
Domyślnie w aplikacji OpenText Identity Manager używana jest funkcja Self Service Password Reset (SSPR), która umożliwia użytkownikom modyfikowanie swoich haseł. Jednak w Identity Applications można wykorzystywać inne metody zarządzania zapomnianymi hasłami.
Erik (użytkownik końcowy) wyszukuje w swojej lokalizacji wszystkich pracowników mówiących po niemiecku.
Eduardo (użytkownik końcowy) przegląda schemat organizacyjny, odnajduje Ellę i klika ikonę wiadomości e-mail, aby wysłać do niej wiadomość.
Poniżej przedstawiono przykład objaśniający przepływ żądania dotyczącego ról i zasobów w systemie:
Figura 1-3 Przykładowy scenariusz przypisania roli
Maxine (menedżer ról) tworzy role biznesowe Pielęgniarka i Lekarz oraz role informatyczne Administrowanie lekami i Wypisywanie recept. Maxine tworzy kilka zasobów, które są wymagane dla tych ról, oraz powiązanie tych zasobów z rolami.
Maxine (menedżer ról) definiuje relację między rolami Pielęgniarka i Administrowanie lekami, wskazując, że rola Pielęgniarka zawiera rolę Administrowanie lekami. Max definiuje również relację między rolami Wypisywanie recept i Lekarz, wskazując, że rola Lekarz zawiera rolę Wypisywanie recept.
Chester (oficer bezpieczeństwa) definiuje ograniczenie rozdziału obowiązków, które wskazuje na istnienie potencjalnego konfliktu między rolami Lekarz i Pielęgniarka. To oznacza, że w normalnych warunkach ten sam użytkownik nie powinien być przypisany jednocześnie do obu ról. W pewnych okolicznościach osoba żądająca przypisania roli może chcieć wymuszenia zniesienia tego ograniczenia. Aby zdefiniować wyjątek rozdziału obowiązków, osoba zgłaszająca żądanie przypisania musi przedstawić uzasadnienie.
Ernest (użytkownik końcowy) przegląda listę dostępnych dla niego ról i żąda przypisania do roli Pielęgniarka.
Amelia (użytkownik zatwierdzający) odbiera powiadomienie o żądaniu zatwierdzenia w wiadomości e-mail, która zawiera adres URL. Klika łącze, zapoznaje się z formularzem zatwierdzenia oraz akceptuje go.
Arnold (menedżer ról) żąda przypisania Ernesta do roli Lekarz. Otrzymuje powiadomienie o występowaniu potencjalnego konfliktu między rolą Lekarz i rolą Pielęgniarka, do której Ernest został już przypisany. Przedstawia uzasadnienie dotyczące utworzenia wyjątku od ograniczenia rozdziału obowiązków.
Edward (użytkownik zatwierdzający rozdział obowiązków) otrzymuje wiadomość e-mail z powiadomieniem o konflikcie rozdziału obowiązków. Zatwierdza zgłoszone przez Arnolda żądanie wymuszenia zniesienia ograniczenia rozdziału obowiązków.
Amelia (użytkownik zatwierdzający) otrzymuje wiadomość e-mail z powiadomieniem o żądaniu zatwierdzenia dotyczącym roli Lekarz. Zatwierdza zgłoszone przez Arnolda żądanie przypisania Ernesta do roli Lekarz.
Bill (audytor ról) przegląda raport dotyczący naruszeń i wyjątków rozdziału obowiązków (SoD) i widzi, że Ernest został przypisany zarówno do roli Lekarz, jak i Pielęgniarka. Ponadto zauważa on, że Ernest został przypisany do zasobów powiązanych z tymi rolami.
Ernie (użytkownik końcowy) przegląda listę dostępnych dla niego zasobów i żąda dostępu do systemu Siebel*.
Amy (użytkownik zatwierdzający) odbiera powiadomienie o żądaniu zatwierdzenia w wiadomości e-mail, która zawiera adres URL. Klika łącze, zapoznaje się z formularzem zatwierdzenia oraz akceptuje go.
Ernest sprawdza stan poprzedniego żądania dotyczącego dostępu do systemu Siebel (zostało ono przesłane drugiej osobie do zatwierdzenia). Widzi, że jest ono dalej rozpatrywane.
Amy udaje się na urlop, więc wprowadza informację o swojej tymczasowej niedostępności. Podczas jej nieobecności nie są jej przypisywane nowe zadania zatwierdzania.
Amy otwiera listę zadań zatwierdzania i widzi, że jest ich zbyt wiele, aby mogła na czas sama wszystkie przetworzyć. Dlatego też przypisuje niektóre zadania swoim współpracownikom.
Pat (asystent ds. administracyjnych, pełnomocnik Amy) otwiera listę zadań Amy i wykonuje w jej imieniu zadanie zatwierdzania.
Max (menedżer) przegląda listę zadań pracowników w swoim dziale. Wie, że Amy jest na urlopie, więc przypisuje zadania do innych pracowników działu.
Max wysyła żądanie utworzenia konta bazy danych dla pracownika działu, który bezpośrednio mu podlega.
Max przypisuje Dana jako autoryzowanego delegata Amy.
Dan (który jest teraz delegowanym użytkownikiem zatwierdzającym) odbiera zadania Amy podczas jej nieobecności.
Max przyjmuje pracownika na bezpłatny staż. Informacje na temat stażysty nie powinny być wprowadzane do systemu kadrowego. Administrator systemu tworzy rekord użytkownika dla stażysty i żąda nadania mu dostępu do programu Notes, usługi Active Directory* i systemu Oracle*.
Poniżej przedstawiono przykład objaśniający przepływ zgłoszenia do pomocy technicznej w systemie:
Figura 1-4 Przykład dotyczący stanowiska pomocy technicznej
Emily (użytkownik końcowy) złożyła wniosek o dostęp do drukarki biurowej. Wniosek ten jest w stanie oczekiwania przez dłuższy czas. Dlatego wysłała ona zgłoszenie do pomocy technicznej.
Helen (użytkownik stanowiska pomocy technicznej) otrzymuje powiadomienie o zgłoszeniu pomocy technicznej na swojej liście zadań.
Helen analizuje problem i stwierdza, że ten wniosek jest przypisany do Amy (osoba zatwierdzająca).
Wniosek jest w stanie oczekiwania w systemie, ponieważ Amy jest nieobecna.
Helen ma uprawnienie do zmiany przypisania żądań wykonania zadania. Zmienia przypisanie tego żądania do Mathew (menedżera Amy).
Mathew otrzymuje wniosek i zatwierdza go. Emily może uzyskać dostęp do drukarki biurowej.
Helen aktualizuje i zamyka zgłoszenie do pomocy technicznej.