Перед мной скоро встанет такая проблема:
мне надо сделать авторизацию на админ сайте для е-магазина.

Где разные пользователи будут иметь разные права.
Пользователи (поставщики, продавцы и покупатели) должны по разному: видеть, исправлять и удалять данные о заказах.

Задача тривиальна, но я в первый раз сталкиваюсь с этим.
Что бы не изобретать лисопед - посоветуйте какие нибуть схемы реализации, UML диаграммы или что почитать.

Все должно быть сделано в архитектуре MVC.
Знаю что: Прокси-паттерн, полиморфизм тут к месту.
Также планирую использовать хранимые процедуры в MySQL:
- доступ к базе (по возможности) только через процедуры
- наделить юзеров правами запускать ту или иную процедуру

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

Увы, управление доступом -- это не один какой-то конкретный паттерн.

Crazy, все верно
это гораздо больше чем паттерн в его классическом понимании (из книги "Банды Четырех").

Но все же инфы на эту тему довольно много.
Я искал в гугле по этим ключевым словам:
security model
security pattern
policy pattern
authorization model
authorization pattern


Я еще не разбирался, но этот линк выглядит многообещающим:
http://www.securitypatterns.org/patterns.html

http://en.wikipedia.org/wiki/Computer_security_model

Кстати, встроенные процедуры в MySQL для управления доступом - рулезная вещь!!

Допустим в PHP у нас есть группы пользователей: админы, продавцы, покупатели.
Аналогично на MySQL сервере создаем юзеров: admin, seller, buyer (через них мы будем делать соединение к БД).

На странице "Годовой отчет" каждому нужно получить разную информацию.
Но PHP вызывает один тот же SQL запрос для всех! Допустим: CALL get_report();

Наша процедура get_report() внутри проверяет через какого юзера сделано соединение к БД и выдает нужные данные.
см. SELECT USER();

Так как каждый захочет фильтровать/сортировать данные как ему захочется, процедура должна принять много параметров:
CALL get_report(здесь, очень, много, параметров)

Как этого можно избежать:
Процедура не выдает RESULTSET, а создает временную таблицу, см. CREATE TEMPORARY TABLE.
Пользователь может выбрать данные из временной таблицы.

Хитрость:
Что бы наделить пользователя привилегиями на чтение из временной таблицы:
1. сначала создаем обыкновенную пустую таблицу с таким же названием.
2. наделяем привилегиями
3. удаляем таблицу

Временные таблицы содаются отдельно для каждого соединения с БД.
Так что потери данных (при возникновении двух одинаковых таблиц) быть не должно.

------------------
Увы, в MySQL приходится иметь дело с временными таблицами (в глобальном пространстве), т. к. язык не предусматривает передачу данных другими средствами (например массивом).

Я проблем тут не вижу:
- писать в SQL процедурах всю бизнес-логику нет смысла и даже вредно.
- ИМХО временные таблицы помощнее массивов (учитывая язык запросов).

Так что для своих целей PL/SQL очень даже.