ASP.NET MVC4 Безопасность, аутентификация и авторизация

Я работаю над новым проектом asp.net mvc4, использующим бета-версию Visual Studio 2011, и пытаюсь разобраться во всем, что касается безопасности. Это внутреннее приложение для внутренней сети, которое первоначально будет использовать единый вход, поэтому пользователю (пока) не будет предложено ввести идентификатор Windows / пароль. Компания имеет специальное приложение для хранения ролей для различных приложений и будет доступно через вызов хранимой процедуры. Он примет идентификатор входа пользователя и вернет некоторую коллекцию, содержащую роли, например, & quot; MyApp.Data & quot ;, & quot; MyApp.User, & quot; MyApp.Admin & quot ;. Так что же это называется - это пользовательский поставщик членства, пользовательский поставщик ролей или что-то еще?

Я читал о всех тонкостях авторизации, аутентификации, членства, ролей и т. Д., И в данный момент не вижу дерева для деревьев. Я читал, что существующие объекты ASP.NET Security были опробованы и протестированы, и если нет очень сложных требований, встроенных будет достаточно, поэтому я рад использовать то, что уже есть.

Так что, если пользователь уже вошел в сеть, это означает, что он аутентифицирован - правильно? Если так, то мне просто нужно реализовать авторизацию. Необходимо ли украшать каждый контроллер или действие атрибутом Authorize? Если да, то как работает «ABC»? часть [Authorize (Roles = & quot; ABC & quot;)] устанавливается, если я получаю роли из своего приложения для хранения пользовательских ролей?

Я прочитал несколько статей и постов в блоге, включая эту, от Джона Галлоуэя, но к концу заблудился:

Индивидуальная настройка аутентификации и авторизации

Так много вопросов ... если кто-нибудь знает хорошее описание высокого уровня того, как все это сочетается, то я весь слух :)

Ответы на вопрос(3)

Решение Вопроса

в отсутствие ответа, который дает общее представление о том, как все это сочетается, я думал, что до сих пор записывал свои выводы:

The company uses Active Directory to store user logon details, so as this is used for Membership I don't need a custom Membership provider. Once a user is logged on to the company network then they are authenticated. Adding a global Authorize filter ensures that any user accessing the system will need to be authenticated. Up to date info from Rick Anderson on msdn:

http://blogs.msdn.com/b/rickandy/archive/2012/03/23/securing-your-asp-net-mvc-4-app-and-the-new-allowanonymous-attribute.aspx

Так что в Global.asax я бы добавил:

public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
    filters.Add(new HandleErrorAttribute());
    filters.Add(new System.Web.Mvc.AuthorizeAttribute()); //new
}

Once a user is authenticated I then need to take care of Authorization. The company have an existing global data store for roles that I won't have update access to, only read access, so I can retrieve the roles for a given user via a stored proc call. It can take from a few days to a couple of weeks for the helpdesk to create roles after a request is made, so for this reason 2 standard roles will be initially created, User and Admin, and subsequent roles will be stored in our application database.

Along with these 2 standard roles subsequent roles are required such as Superuser, etc. These roles will have various rights depending on business rules etc. and will need to be stored in our application database. So for this scenario I will need to create a custom Role provider, add the appropriate asp.net role tables to my app database, and plug it into the web.config. Here's an ms page titled Managing Authorization Using Roles that I'm picking bits out of:

http://msdn.microsoft.com/en-us/library/9ab2fxh0.aspx

From what I've read so far the only tables I need for a custom role provider are Roles and UsersInRoles.

CREATE TABLE Roles ( Rolename Text (255) NOT NULL, ApplicationName Text (255) NOT NULL, CONSTRAINT PKRoles PRIMARY KEY (Rolename, ApplicationName) )

CREATE TABLE UsersInRoles ( Username Text (255) NOT NULL, Rolename Text (255) NOT NULL, ApplicationName Text (255) NOT NULL, CONSTRAINT PKUsersInRoles PRIMARY KEY (Username, Rolename, ApplicationName) )

Once all this is setup I need to figure out how to merge the 2 standard roles (User and Admin) from the global data store with the custom roles stored in my app database, and if I can use (e.g.) [Authorize(Roles="Admin, Superuser")] on a Controller/Action or if I need to subclass AuthoriseAttribute and do something more clever.

I just realised that as I use AD for authentication I need a way of adding / injecting the collection of roles the current user is a member of. So although I don't need any custom membership provider functionality I still have to interact with httpContext.User to update its Roles collection.

 Ciaran Bruen15 авг. 2013 г., 12:09
@EduardoRascon без проблем рад, что вы нашли это полезным
 15 авг. 2013 г., 01:09
Было очень мило с вашей стороны потратить время и поставить такой хороший ответ. Спасибо.

обновленный совместно с вашим RoleProvider, должен быть всем, что нужно для получения списка ролей, связанных с аутентифицированным пользователем. Помните, что RolePrincipal уже будет содержать надлежащий идентификатор WindowsIdentity.

Вам не нужен пользовательский атрибут авторизации. RolePrincipal / RoleProvider будет извлекать необходимые роли и работать со стандартным атрибутом Authorize.

То, что кажется немного странным, это то, что вы хотите иметь роли, характерные для вашего приложения, но вы говорите, что вы также хотите, чтобы роли, связанные с пользователями Windows, были также из отдельного корпоративного магазина. Как вы сказали, вы хотите объединить их. Мне это не кажется правильным. Либо вы хотите управлять ролями на корпоративном уровне для своего приложения, либо вы хотите управлять ими на локальном уровне. Как правило, вы не будете делать оба.

Но если это действительно то, что вы хотите сделать, то это звучит так, как будто ваш RoleProvider должен выполнить вызов службы (например, WCF) или вызов AD, чтобы получить дополнительную информацию. Возможно, имена "групп" пользователю Windows могут служить «роли». Затем вы отфильтруете только те группы, которые относятся к вашему приложению, и объедините их с ролями, найденными в ваших локальных базах данных ролей.

Как только вся эта информация будет собрана, обязательно попросите roleManager сохранить информацию о роли в файле cookie. Нет смысла проходить этот хуллабалу с каждым запросом пользователя.

что через Active Directory), то вы ищете механизм авторизации, который сопоставляет роли с пользователями. Один из вариантов, который у вас есть, - это загрузить роли пользователя в текущий сеанс после успешного завершения. Затем создайте пользовательский атрибут авторизации, который будет проверять, имеют ли текущий сеанс необходимые роли, с которыми вы работаете

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited=true, AllowMultiple=true)]
public class CustomAuthorizationAttribute : AuthorizeAttribute
{
   protected override bool AuthorizeCore(HttpContextBase httpContext)
   {         
      IPrincipal user = httpContext.User;
      if (!user.Identity.IsAuthenticated)
      {
          return false;
      }

     //check your users against a database and return true or false
      return base.AuthorizeCore(httpContext);
   }
}

Тогда вы можете использовать атрибут, как это

[CustomAuthorization]
public ActionResult SomeAction()
{
   return View();
}

UPDATE

AuthorizeCore - это метод, который будет использоваться для проверки того, должен ли этот пользователь иметь доступ к соответствующему методу действия. В рамках этого метода вы можете проверить свойство httpContext.User.Identity.Name в вашей базе данных или в месте хранения ваших ролей. Если вы используете проверку подлинности Windows через Active Directory, HttpContext.User.Identity должен быть экземпляромWindowsIdentity

 Ciaran Bruen25 мая 2012 г., 11:52
Привет спасибо за это. Компания использует Active Directory для управления пользователями / входа в систему и т. Д., Но у них есть отдельное приложение, которое обрабатывает управление ролями для своих различных окон и веб-систем. Это возвращает список ролей для данного пользователя и вызывается через сохраненный процесс. Я видел статьи о настройке атрибута авторизации, так что, вероятно, сделаю это, но я хотел бы найти хорошее руководство высокого уровня о том, как все это сочетается.
 Ciaran Bruen25 мая 2012 г., 13:01
Кроме того, что делает AuthorizeCore ... как я могу использовать его для "проверки пользователей по базе данных"?

Ваш ответ на вопрос