Архитектура пользовательских поставщиков
184ASP.NET --- Безопасность в ASP.NET --- Архитектура пользовательских поставщиков
Ранее вы узнали все необходимые детали аутентификации и авторизации пользователей в ASP.NET с применением механизма аутентификации с помощью форм. Вам известно, что при аутентификации с помощью форм вы сами отвечаете за управление пользователями (и ролями, если нужна аутентификация на основе ролей) в специальном хранилище.
К счастью, ASP.NET включает в себя интерфейсы Membership API и Roles API, которые предоставляют готовую платформу управления пользователями и ролями. Эту платформу можно расширить с помощью механизма поставщиков, которые реализуют доступ к лежащему в основе хранилищу данных. Ранее были использованы поставщики по умолчанию для SQL Server, которые поставляются вместе с ASP.NET.
Заменить реализацию по умолчанию, работающую с SQL Server, можно за счет построения собственных поставщиков членства и ролей. Это предоставляет возможность замены лежащего в основе хранилища информации о пользователях и ролях, не затрагивая веб-приложения.
Ранее вы узнали множество подробностей об интегрированных службах членства и ролей. Эти службы предоставляют в ваше распоряжение готовые решения для управления пользователями и ролями с аутентификацией с помощью форм. Как объяснялось, эта модель может быть расширена за счет так называемых пользовательских поставщиков, как показано на рисунке ниже:
При реализации собственных поставщиков следует опираться на архитектуру, представленную на рисунке. Пользовательский поставщик всегда базируется на низшем уровне в многоуровневой модели, обеспечиваемой интерфейсами членства и ролей ASP.NET. Важно знать, что все прочие основанные на поставщиках API-интерфейсы в ASP.NET структурированы аналогичным образом. Поэтому реализация пользовательских поставщиков для Profiles API или механизмов персонализации ASP.NET очень похожа.
Как можно видеть из базовой архитектуры, службы членства и ролей не зависят друг от друга. Поэтому поставщики членства и ролей имеют разные базовые классы; вдобавок информацию о членстве и ролях можно сохранять в разных системах заднего плана. Хорошим примером может служить служба Roles Service с Windows-аутентификацией.
Прежде чем приступать к изучению подробностей реализации пользовательских поставщиков, важно понять, зачем вообще может понадобиться создавать собственный поставщик членства. Ниже описано несколько распространенных причин:
Необходимо использовать существующую базу данных пользователей и ролей, которая основана на схеме, отличной от стандарта ASP.NET.
Необходимо использовать базу данных, отличную от Microsoft SQL Server.
Необходимо использовать необычное хранилище данных (такое как XML-файл, веб-служба или служба каталогов LDAP).
Необходимо реализовать дополнительную логику аутентификации. Хорошим примером могут служить многие реализации правительственных веб-сайтов, где пользователи должны аутентифицироваться, указывая три значения: имя, идентификатор подписки и пароль.
Если вы просто хотите хранить собственную информацию в дополнение к информации, хранимой реализацией по умолчанию, то разрабатывать для этого собственный поставщик не рекомендуется. Поскольку Membership API предоставляет доступ к ключу, уникально идентифицирующему пользователя в хранилище, лучше добавить собственные таблицы для хранения дополнительной информации и информации соединения через уникальный ключ пользователя с записями пользователей в хранилище стандартного поставщика членства. В качестве альтернативы для хранения этих дополнительных свойств можно реализовать профили пользователей. Это намного проще, чем строить собственный поставщик для добавления нескольких дополнительных значений.
Внутри приложения доступ к уникальному ключу пользователя осуществляется через свойство ProviderUserKey класса MembershipUser. В следующей статье вы узнаете, как распространяется уникальный ключ на свойство ProviderUserKey класса MembershipUser.
