APEX предоставляет несколько различных способов аутентификации пользователей. Одним из подходов является использование схемы аутентификации «Application Express» и просто создание пользователей APEX. Другой подход заключается в использовании схемы аутентификации «Учетная запись базы данных» и создании пользователей Oracle. Третий вариант - создать собственную схему аутентификации и реализовать собственные функции управления пользователями.
Application Express-аутентификация, как правило, проще всего развернуть для небольшого приложения, но со временем она становится громоздкой. Например, сложно дать администратору приложения возможность создавать учетные записи APEX. Вы не можете привязать учетную запись APEX к решению с единым входом. Нелегко интегрироваться с системами управления разрешениями, которые используют другие приложения. Если вы развертываете приложение в большой компании, последнее, что нужно отделу безопасности, - это еще одно место, где ему необходимо создавать учетные записи пользователей, управлять привилегиями, деактивировать учетные записи, когда кто-то покидает или меняет роли и т. Д.
Аутентификация базы данных имеет тенденцию быть более масштабируемой, чем аутентификация APEX, поскольку предоставление учетной записи базы данных Oracle, вероятно, уже является частью инфраструктуры аутентификации и авторизации вашей организации. С другой стороны, это все еще означает, что вы создаете пользователя базы данных Oracle для каждого пользователя, которого вы хотите создать в своем приложении, что, вероятно, включает в себя вызов администратора баз данных (технически вы можете создавать пользователей баз данных из своего приложения, но большинство администраторов баз данных) будут обеспокоены последствиями для безопасности). Если вы намереваетесь создать интернет-приложение с десятками тысяч пользователей, учетные записи базы данных могут стать громоздкими.
Держу пари, что подавляющее большинство средних и крупных приложений APEX используют собственную схему аутентификации. Это может включать создание таблицы USER, в которой вы сохраняете имя пользователя и хэш пароля, или запрос к хранилищу LDAP / AD. Такой подход обеспечивает наибольшую гибкость, поскольку вы можете кодировать все, что захотите, в систему аутентификации. Вы можете подключиться к любому пользовательскому решению для аутентификации / единого входа, используемому организацией. Это, вероятно, значительно упрощает создание новых пользователей из приложения (очевидно, в зависимости от того, как устроена система аутентификации).
Я предполагаю, что ваш менеджер ожидает, что вы будете писать собственную схему аутентификации для ваших приложений APEX.