ActionFilter, вероятно, является хорошей отправной точкой, но в зависимости от вашей архитектуры вы можете решить, достаточно ли хороша защита периметра.
Если вы, по сути, создаете однослойное приложение ASP.NET MVC (и для этого могут быть совершенно разумные причины), ActionFilter обеспечит достаточно хорошую защиту и в то же время очень простую в применении.
С другой стороны, если ваше приложение представляет собой многослойное приложение, защита в глубину является более подходящей. В этом случае вам следует рассмотреть возможность применения логики авторизации в модели предметной области или, возможно, даже на уровне доступа к данным. Это гарантирует, что если вы когда-нибудь разработаете другое приложение, основанное на той же доменной модели (например, веб-сервис), логика авторизации будет по-прежнему применяться.
Независимо от того, что вы делаете, я настоятельно рекомендую основывать фактическую реализацию авторизации на IPrincipal.
Если говорить более конкретно, то, о чем вы здесь спрашиваете, лучше всего смоделировано с помощью авторизации на основе ACL: установите ACL для каждого профиля пользователя, который по умолчанию предоставляет доступ только самому себе и администратору. Если / когда вам позже понадобится расширить приложение, чтобы разрешить делегированный доступ к профилям других пользователей (я не знаю, насколько это реалистично в вашем конкретном случае), вы можете просто сделать это, добавив новую запись в ACL.
В таком случае оценка доступа включает в себя получение ACL для запрошенного ресурса и проверку, включен ли текущий пользователь (IPrincipal) в этот ACL. Такая операция, скорее всего, будет включать в себя внепроцессные операции (поиск ACL в базе данных), поэтому наличие ее в качестве неявной части приложения путем ее скрытия за ActionFilter звучит так, будто потенциально может скрыть некоторые проблемы с производительностью. В таком случае я хотел бы сделать модель авторизации более понятной / видимой.