C# breezejs和EF6中基于角色的安全性

我在一个项目中使用Breeze.js、AngularJS、Web API和EF6，该项目有3个主要的安全角色。让我们说高水平、中水平和低水平。在这些示例中，我有Person、Company、lowleversecret、MediumLevelSecret和HighLevelSecret实体

安全问题1: 在第一个示例中，我希望能够确保对整个实体的访问。所有安全角色（低级、中级和高级）都应该能够访问个人实体。只有具有匹配角色级别或更高级别的用户才能访问包含特权信息的机密实体

例如，我可能有

class Person {
    public int Id { get; set; }
    public string Name { get; set; }

    public LowLevelSecret LowLevelSecret { get; set; }
    public MediumLevelSecret MediumLevelSecret { get; set; }
    public HighLevelSecret HighLevelSecret { get; set; }
}

其中低级机密、中级机密和高级机密看起来像这样：

class LowLevelSecret {
    public int Id { get; set; }
    public string Secret { get; set; }
}
class MediumLevelSecret {
    public int Id { get; set; }
    public string Secret { get; set; }
}
class HighLevelSecret {
    public int Id { get; set; }
    public string Secret { get; set; }
}

private string _p;
public string P 
{ 
  get 
  { 
    if (UserRoles.HasAny("role-a","role-b"))
      return _p;
    return null; 
  }
  set { _p = value; }
}

我有一个控制器，每个人和公司都有一个IQueryable类型：

class BreezeController : ApiController {
    [HttpGet]
    public string Metadata()
    {
        return _repository.Metadata;
    }
    [HttpPost]
    public SaveResult SaveChanges(JObject saveBundle)
    {
        var result = _repository.SaveChanges(saveBundle);
        return result;
    }
    [HttpGet]
    public IQueryable<Person> People()
    {
        return _repository.People;
    }
    [HttpGet]
    public IQueryable<Company> Companies()
    {
        return _repository.Companies;
    }
}

如何限制访问，如所述，以便不同的用户角色可以访问同一公司实体的不同部分。我可以编写一个投影查询来只获取我想要的位，但是没有什么可以阻止用户为整个实体编写自己的查询。我假设这里的关键可能是对每个访问级别使用不同的DTO？这是如何工作的，以便在保存时将所有内容拼凑在一起，等等，这样它就知道要更新哪个实体

安全问题3 控制器中的SaveChanges方法接受一个变更包。似乎没有任何东西可以阻止具有较低级别访问权限的用户向他们不能更改的实体提交更改。即使普通客户端代码不允许这样做，他们也可以编写自己的或手动创建并提交

我认为最好的解决方案是覆盖BeforeSavingEntity方法并检查更改，以确保用户角色可以接受这些更改？手动检查每个中高级属性的更改并比较用户角色是否是确保安全性的唯一方法？是否有一个良好的可扩展模式，可用于在大量实体上执行这些检查和其他业务逻辑。我找不到任何好的实际例子来说明如何在更大的项目场景中正确地实施这些业务规则

---

感谢您的帮助和建议，

这是一个相当有争议的问题，因为您正试图通过使用IQueryables之类的查询来限制敏感信息的公开。这是一个可怕的设计缺陷，你可能会给自己带来很多麻烦

不要将您的应用程序设计为可能根据客户端的角色公开信息，因为这些角色的安全性不高。不要这样做。在公开iQueryTable中的数据之前，需要限制iQueryTable在业务逻辑中可以访问的数据

也不要依靠储蓄来总是正确的。从未。这是一个非常糟糕的设计，我希望你在投入生产之前寻求专业人士的帮助

---

有关更多信息，请参阅此问题/答案-

好问题。。。嗯，问题（复数）！我的任务是实现基于角色的安全性。昨天我实现了基于角色的安全性来保存。事实上，我在saveEntity（）之前实现了检入。。。按照你描述的方式。这看起来确实是一个昂贵的手术，但我不知道还有更好的方法

那么，您可以通过替代BeforeSaveEntities（）来进行一些优化

至于如何为查询实现基于角色的安全性。。。我还在研究：）我有一些想法。但是，我还没有能够实施它们，还不能说它们是否有效。尽管如此，以下是我的想法：

1） 与保存算法非常相似，检查实体——在执行查询之后，但在将结果发送到客户端之前。但是，我不知道如何在执行和发送到客户端之间插入检查代码（通过回调或其他方式）：(

2） 将smarts添加到POCO，以根据用户角色检查受限实体和属性。例如，而不是：

public string P {get;set;}

你会有这样的东西：

class LowLevelSecret {
    public int Id { get; set; }
    public string Secret { get; set; }
}
class MediumLevelSecret {
    public int Id { get; set; }
    public string Secret { get; set; }
}
class HighLevelSecret {
    public int Id { get; set; }
    public string Secret { get; set; }
}

private string _p;
public string P 
{ 
  get 
  { 
    if (UserRoles.HasAny("role-a","role-b"))
      return _p;
    return null; 
  }
  set { _p = value; }
}

---

这看起来很恶心，因为POCO应该是哑巴。POCO需要能够从某处读取用户角色。。。也许是HTTP会话。我不太清楚这将如何工作。

谢谢您的反馈。我知道当前设置存在严重的安全/设计问题。这就是为什么我发布文章寻找安全的建议/替代实现。关于如何实现安全解决方案,你有什么反馈吗?PW Kad@:我想问题是如何确保服务器上的访问安全。你的回答以及病房的链接答案都没有帮助。如何实际应用安全性？特别是：如何防止恶意客户端将非限制表的查询扩展到限制表。并且，允许有条件地访问表——基于用户的权限。