问题
I have an app that uses Windows Auth on aspnet 5 MVC 6 (obv using IIS + IISPlatformHandler)
How can I restrict access to a controller by AD group?
I have tried doing something like the following, but it won't work :( When I look at my user claims I see many groups and claims that look like SID's ex. {S-1-5-4}
[Authorize(Roles = "DOMAIN\\GROUP")
public class myController : Controller{...}
回答1:
As of July 2016, I find the following now works with .NET Core RTM (WebAPI):
[Authorize(Roles = @"DOMAIN\Group")]
Here are the project.json dependencies in case you would also like to test:
{
"title": "My App",
"copyright": "2016",
"description": "WebAPI",
"dependencies": {
"Microsoft.AspNetCore.Mvc": "1.0.0",
"Microsoft.AspNetCore.Server.IISIntegration": "1.0.0",
"Microsoft.AspNetCore.Server.Kestrel": "1.0.0",
"Microsoft.Extensions.Configuration.EnvironmentVariables": "1.0.0",
"Microsoft.Extensions.Configuration.FileExtensions": "1.0.0",
"Microsoft.Extensions.Configuration.Json": "1.0.0",
"Microsoft.Extensions.Logging": "1.0.0",
"Microsoft.Extensions.Logging.Console": "1.0.0",
"Microsoft.Extensions.Logging.Debug": "1.0.0",
"Microsoft.Extensions.Options.ConfigurationExtensions": "1.0.0",
"Microsoft.NETCore.App": {
"version": "1.0.0",
"type": "platform"
},
"Newtonsoft.Json": "9.0.1",
"NLog.Extensions.Logging": "1.0.0-rtm-alpha2"
},
回答2:
The problem with this is that DNX does not have system.DirectorySevices in it. I have started a discussion at the following github issue.
https://github.com/aspnet/Home/issues/1232#issuecomment-171264286
回答3:
We had to deal with this with current RC1 bits and tried to minimize customization since it looks like things will hopefully be fixed in RC2. What we ended up doing was creating a Constants class that had our AD group names that we cared about as the variable and then for the time being, the value for the constant is the SID. In our code, we then used the constant instead of hardcoding the SID value for the role. This way, when things are fixed in the future, we have the ability to just change out the values (replace the sids with the group names) for the constants instead of doing a search and replace through all the controllers. We also ended up writing a simple API so that we could pull back all the Name/Sid associations. The code for that is
[HttpGet("[action]")]
public List<Tuple<string, string>> GetSids()
{
List<Tuple<string, string>> results = new List<Tuple<string, string>>();
using (PrincipalContext pc = new PrincipalContext(ContextType.Domain))
{
using (GroupPrincipal gp = new GroupPrincipal(pc))
{
using (PrincipalSearcher searcher = new PrincipalSearcher(gp))
{
foreach (var found in searcher.FindAll())
{
if (found is GroupPrincipal)
{
results.Add(new Tuple<string, string>(found.Name, found.Sid.Value));
}
}
}
}
}
return results;
}
回答4:
I just faced a very similar situation where our roles and authorization levels would extensively deviate from what ASP.NET could natively provide. So, we built our own custom attribute inherited from AuthorizeAttribute and it worked very well!
I don't have experience with the AD component but a lucky search showed this developer did:
http://ricardodsanchez.com/2013/05/24/how-to-use-active-directory-groups-to-restrict-access-to-controller-actions-in-asp-net-mvc-and-make-your-application-even-more-secure/
His code looks straight forward and except for the AD piece seems to be just like the one we got working.
One thing to note: the current best practice for authorization is authorization policies. But even the most clever use of that pattern I doubt will get you an easy path to the AD. In case you're curious you can see that suggested method here.
来源:https://stackoverflow.com/questions/34746645/aspnet-5-mvc6-windows-auth-roles-authorize-attribute