Первый вариант,но только с разграничением прав на основе операций.Это позовляет автоматически настраивать интерфейс в зависимости от прав(загрузка только разрешенных модулей, скрытие элементов управления(пункты меню,кнопки и тд).
Роли на мой взгляд,весьма неудобны.

авторЕсли только первый вариант, то в итоге мы я так понимаю мы имеем сервер и базу, клиенты которых не имеют никаких ограничений по доступу к их информации и ХП и в обход авторизации приложения можно взять простенький SQL редактор, подключится к БД и творить что душе угодно.
Подобный вариант защиты годится только для 2-х звенки и расчитан только на неподготовленных пользователей, совершенно не приемлем для интернета.Здесь уже нужна 4-x звенка и БД будет за двумя firewall'ами,а отдельный сервис авторизации просто интергрируется с другими.

авторНу а роли (группы) - удобно, неудобно, вопрос спорный. По мне удобный - мне гораздо легче определить в виде ролей в разрезе функционала разные права и потом просто раздавать их пользователям. Или, если в ТЗ четко расписанное кол-во групп пользователей с их бизнес-процессами, создать группы пользователей с нужными правами на объекты БД и назначать пользователя в нужную группу
Конечно спорный,приложения бывают разными,но четко расписанное кол-во групп бывает редко,да и жескость в конструкции может выйти боком.У меня в последнем проекте несколько десятков видов документов,каждый из них может иметь от 3х до 8 статусов,помимо этого есть ограничения на просмотр списков,открытие,создание,редактирование.Если оперировать ролями, то нужно было бы создавать под каждый чих отдельную роль или их перечисление,сопоставить учетку надцати ролям,что,по мне, весьма неудобно.А так есть конкретное действие,к нему дается/запрещается доступ ролям приложения(по дожностям или отделам,группам LDAP),при необходимости конкретым пользователям(запись из справочника сотрудников или учетка LDAP).В большенстве случаев делаем запись для нового сотрудники и все.