1.6 Примеры типового использования приложений Identity

Здесь приведены некоторые примеры типового использования приложений Identity в рамках предприятия.

1.6.1 Как работает самообслуживание учетной записи

  • Элла (конечный пользователь) при помощи функций самообслуживания учетной записи восстанавливает забытый пароль для входа в систему.

    По умолчанию Identity Manager использует решение Self Service Password Reset (SSPR), чтобы позволить пользователям изменять свои пароли. Однако приложения, определяющие подлинность, могут использовать другие средства управления забытыми паролями.

  • Эрик (конечный пользователь) выполняет поиск всех сотрудников своего офиса, говорящих по-немецки.

  • Эдуардо (конечный пользователь) просматривает структурную схему, находит Эллу и щелкает значок электронной почты, чтобы отправить ей сообщение.

1.6.2 Как работать с функциями и ресурсами

Ниже приведен пример с описанием запроса потока ролей и ресурсов в системе.

Рисунок 1-3 Пример сценария назначения функции

  • Оксана (менеджер ролей) создает бизнес-роли "Медсестра" и "Врач" и ИТ-роли "Дает лекарства" и "Выписывает рецепты". Оксана создает различные ресурсы, необходимые для данных ролей, и связывает эти ресурсы с ролями.

  • Оксана (менеджер ролей) определяет отношение между ролями "Медсестра" и "Дает лекарства", указывая, что в состав роли "Медсестра" входит роль "Дает лекарства". Она также определяет отношение между ролями "Выписывает рецепты" и "Врач", указывая, что роль "Выписывает рецепты" входит в состав роли "Врач".

  • Григорий (сотрудник службы безопасности) определяет ограничение распределения обязанностей, в котором указано, что между ролями "Врач" и "Медсестра" существует потенциальный конфликт. Он заключается в том, что одному пользователю в обычных условиях не должны назначаться обе роли одновременно. В некоторых случаях пользователь, запросивший назначение роли, возможно, пожелает переопределить это ограничение. Чтобы определить исключение при разделении обязанностей, пользователь, запросивший назначение, должен предоставить обоснование.

  • Алла (конечный пользователь) просматривает список доступных ей ролей и запрашивает назначение роли "Медсестра".

  • Нина (утверждающий пользователь) получает по электронной почте уведомление (содержащее URL-адрес) о запросе, требующем подтверждения. Она щелкает ссылку, получает форму подтверждения и с ее помощью подтверждает запрос.

  • Василий (менеджер ролей) запрашивает назначение Алле роли "Врач". Он уведомляется о том, что между ролью "Врач" и ролью "Медсестра", которая уже назначена Алле, существует потенциальный конфликт. Василий предоставляет обоснование тому, чтобы для ограничения распределения обязанностей было сделано исключение.

  • Олег (пользователь, утверждающий распределение обязанностей) по электронной почте получает уведомление о конфликте распределения обязанностей. Он утверждает запрос Василия на переопределение ограничения распределения обязанностей.

  • Нина (утверждающий пользователь) получает по электронной почте уведомление о запросе, требующем подтверждения, для роли "Врач". Она утверждает запрос Василия на назначение Алле роли "Врач".

  • Сергей (аудитор ролей) просматривает отчет о нарушениях и исключениях распределения обязанностей и видит, что Алле назначены обе роли — и "Врач", и "Медсестра". Кроме того, он видит, что Алле были назначены ресурсы, соответствующие этим ролям.

1.6.3 Как обрабатывать запросы

  • Эрни (конечный пользователь) просматривает список доступных ему ресурсов и делает запрос на доступ к системе Siebel*.

  • Эми (утверждающий пользователь) получает по электронной почте уведомление (содержащее URL-адрес) о запросе, требующем подтверждения. Она щелкает ссылку, получает форму подтверждения и с ее помощью подтверждает запрос.

  • Эрни проверяет состояние сделанного им ранее запроса на доступ к Siebel (который в этот момент передан на подтверждение следующему сотруднику). Он видит, что запрос все еще выполняется.

  • Эми собирается в отпуск, поэтому указывает, что временно будет отсутствовать. На время ее отсутствия новые задачи подтверждения ей не назначаются.

  • Эми открывает список своих задач подтверждения; видит, что их слишком много, чтобы обработать своевременно; и передает некоторые из них своим сотрудникам.

  • Пэт (ассистент администрации, действующий как доверенное лицо Эми) открывает список задач Эми и выполняет вместо нее задачи подтверждения.

  • Макс (менеджер) просматривает списки задач сотрудников своего отдела. Он знает, что Эми в отпуске, поэтому перераспределяет задачи среди других сотрудников своего отдела.

  • Макс запрашивает из базы данных учетные записи сотрудников, подчиненных ему непосредственно.

  • Макс назначает Дэна на роль уполномоченного делегата Эми.

  • Дэн (теперь делегат утверждающего) во время отсутствия Эми получает ее задачи.

  • Макс привлекает к работе без оплаты стажера, который не будет зарегистрирован в отделе кадров. Системный администратор создает пользовательскую запись для этого стажера и делает запрос на предоставление ему доступа к Notes, Active Directory* и Oracle*.

1.6.4 Порядок работы службы поддержки

Ниже приведен пример с описанием потока сообщения о проблеме для службы поддержки в системе.

Рисунок 1-4 Пример для службы поддержки

  • Юлия (конечный пользователь) запросила доступ к офисному принтеру. Этот запрос был отложен на продолжительный период. Поэтому она отправила сообщение о проблеме в службу поддержки.

  • Елена (пользователь службы поддержки) получает уведомление о сообщении о проблеме для службы поддержки в списке своих задач.

  • Елена анализирует проблему и узнает о том, что запрос назначен Ольге (подтверждающий).

  • Запрос отложен в системе, так как Ольга находится вне офиса.

  • У Елены имеется разрешение на переназначение запросов задач. Она переназначает этот запрос Матвею (менеджеру Ольги).

  • Матвей просматривает запрос и подтверждает его. Юлия получила доступ к офисному принтеру.

  • Елена обновляет и закрывает сообщение о проблеме для службы поддержки.