IIdentity和IPrincipal接口

Question

我一直分别看到IPrincipal和IIdentity接口，但我没有看到任何令人信服的理由，所以我有自己的接口，将两者结合在一起：

public interface IUser : System.Security.Principal.IIdentity, System.Security.Principal.IPrincipal {
    string Role { get; set; }
}

然后，我将接口实现为：

public class User : IUser {
    public string Role { get; set; }

    public System.Security.Principal.IIdentity Identity {
        get { return this; }
    }

    public string AuthenticationType {
        get { throw new System.NotImplementedException(); }
    }

    public bool IsAuthenticated {
        get { throw new System.NotImplementedException(); }
    }

    public string Name {
        get { throw new System.NotImplementedException(); }
    }

    public bool IsInRole(string role) {
        throw new System.NotImplementedException();
    }
}

这是闻吗？我这里有安全问题吗？

Answer 1

虽然在某些情况下需要将主体与标识分离，但在许多应用程序中，情况并非如此，这种区别只会使代码复杂化。在应用程序中处理安全性的最佳方式在很大程度上取决于特定应用程序的个别需求。

Martin的文章处理角色深入分析了可用于实现基于角色的安全性的不同模式，以及每种模式的必要性。

通常，您不能假设将主体从标识中分离出来的解决方案是所有应用程序的最佳解决方案。我遇到过许多场景，这些场景没有必要，只添加了额外的类。在这种情况下，最好合并这两个接口。

此外，这些是接口，而不是类。接口表示实例与定义之间的“有”关系，其中类表示"is“关系。OP示例中的User实例是一个同时具有标识和主体(安全上下文)的对象。您总是可以将事情分解为更复杂的层次，但是如果应用程序功能没有表明需要将类分离，那么为什么要这样做呢？

Answer 2

这些接口用于处理用户的身份信息。

• IIdentity：标识对象代表代码运行的用户。
• IPrincipal：主体对象表示代码所代表的用户的安全上下文，包括该用户的标识(IIdentity)和他们所属的任何角色。

从文档来看，您的实现看起来很奇怪。您将永久地将用户的身份链接到固定的角色。据我所知，用户可能在不同的时间对不同的角色进行操作。。这提供了更好的封装。我看到的主要‘设计’问题是，您的身份现在包含一个身份，其中包含一个身份，在内部，.一个身份，还有..。你说对了。

此外，也许IIdentity和IPrincipal的默认实现已经可以帮助您了？看一看通用实现。