Я не уверен, что вы подразумеваете под одно-и много-ролевым приложением. Ранее я создавал приложения, в которых есть несколько ролей базы данных SQL Server, каждая из которых имеет группу пользователей домена Windows, которой разрешена эта роль. Таким образом, управление пользователями полностью в Active Directory с соответствием 1-1 между группой домена и ролью базы данных.
Обычно мы не управляли безопасностью в самом приложении, за исключением явно декларативного характера при создании базы данных, где каждому объекту был предоставлен доступ с определенными ролями в соответствии с проектом. Как правило, в простом случае мы полагались на роль db_datareader, предоставляемую для общего использования неспецифическим группам пользователей, таким как администраторы баз данных и сети для устранения неполадок, а также составители отчетов или бизнес-аналитики для специальных отчетов. Фактическим пользователям приложения будет предоставлено право выполнять соответствующие SP, чтобы иметь возможность изменять любые данные (таким образом, все создание или изменение данных осуществлялось через SP, и это могли делать только явные члены группы AD ThisAppsUsers). Любые расширенные SP (скажем, слияние или удаление учетных записей) будут доступны только группе AD ThisAppsAdmins. И это было обычно все, что нам нужно для приложений среднего размера. Для более сложной функциональности также можно было запрашивать AD напрямую для пользовательских атрибутов (пользователь является администратором только для этой учетной записи клиента, а для других - просто пользователь)
Этот же метод может использоваться с именами входа SQL Server, но, конечно, отдельные имена входа SQL Server должны быть добавлены к ролям базы данных, а у вас нет богатства AD и вам нужно создать какую-то службу каталогов. в вашу базу данных.
Возможность даже использовать AD может быть невозможна для многих приложений, поэтому в этом случае архитектуре безопасности, очевидно, придется обслуживать эту модель.