{"id":2786,"date":"2006-01-09T23:42:26","date_gmt":"2006-01-10T04:42:26","guid":{"rendered":"http:\/\/www.soulhuntre.com\/items\/date\/2006\/01\/09\/joshua-flanagan-aspnet-role-provider-visual-studio-template\/"},"modified":"2006-01-09T23:42:26","modified_gmt":"2006-01-10T04:42:26","slug":"joshua-flanagan-aspnet-role-provider-visual-studio-template","status":"publish","type":"post","link":"http:\/\/legacyiamsenseiken.local\/2006\/01\/09\/joshua-flanagan-aspnet-role-provider-visual-studio-template\/","title":{"rendered":"Joshua Flanagan – ASP.NET Role Provider Visual Studio template"},"content":{"rendered":"
Of all the new providers that ASP.NET 2.0 introduces, I think the RoleProvider will be the most frequently implemented in a corporate IT environment. Intranet applications can usually take advantage of Windows integrated authentication for user identification. By default, this will create a WindowsPrincipal object that contains all of the user’s domain groups as roles to be used for authorization. However, it has been my experience that most applications do not use domain groups for their role-based authorization. It is more likely that they have a database (or some other store) that associates a user’s Windows login name with application specific roles.<\/p><\/blockquote>\n