ChatGPT解决这个技术问题 Extra ChatGPT

What is the meaning and difference between subject, user and principal?

In the context of security frameworks, a few terms commonly occur subject, user and principal, of which I have not been able to find a clear definition and the difference between them.

So, what exactly do these terms mean, and why are these distinctions of subject and principal needed?


T
T.Rob

These are hierarchical in the way that genus, species and individual are hierarchical.

Subject - In a security context, a subject is any entity that requests access to an object. These are generic terms used to denote the thing requesting access and the thing the request is made against. When you log onto an application you are the subject and the application is the object. When someone knocks on your door the visitor is the subject requesting access and your home is the object access is requested of.

Principal - A subset of subject that is represented by an account, role or other unique identifier. When we get to the level of implementation details, principals are the unique keys we use in access control lists. They may represent human users, automation, applications, connections, etc.

User - A subset of principal usually referring to a human operator. The distinction is blurring over time because the words "user" or "user ID" are commonly interchanged with "account". However, when you need to make the distinction between the broad class of things that are principals and the subset of these that are interactive operators driving transactions in a non-deterministic fashion, "user" is the right word.

Subject/Object inherits from the same terms as used in grammar. In a sentence the subject is the actor and the object is the thing acted on. In this sense the use has been around since before computers were invented. In a security context, a subject is anything that can make a request. As noted above, this need not be limited to IT security and so is a very broad classification. The interesting thing is that subject implies object. Without an object, there is no subject.

Principals are what subjects resolve to. When you present your credit card you are the subject and the account number is the principal. In other contexts your user ID or state-issued identification is your principal. But principals can be associated with many types of subject that are not people. When applications make requests for system-level functions the principal may the signer of a signed executable code module but even in that case the user driving the request is still the subject.

User is more specific than subject or principal in that it usually refers to an interactive operator. That is why we have a graphical User Interface and not a Graphical Principal Interface. A user is an instance of subject that resolves to a principal. A single user may resolve to any number of principals but any principal is expected to resolve to a single user (assuming people observe the requirement not to share IDs). In the example above, the signer of an executable code module is definitely not the user, but it is a valid principal. The interactive operator trying to get the module loaded is the user.

As noted in the comments, even the authoritative sources do not agree on these terms. I searched NIST, SANS, IEEE, MITRE and several "quasi-authoritative" sources such as security exam guides while preparing this response. No single source that I found which was at least quasi-authoritative covered all three terms and all differed significantly in their usage. This is my take on how the terms should be used but from a practical standpoint, when you are poring over a manual in the middle of the night, the definitions tend to be whatever the vendor or writer say they are. Hopefully though responses here will provide enough insight to navigate the waters and parse any security document using these terms.


What is the benefit of breaking things down to Subject, Principal, User, its extra complexity what benefit do we get from this extra complexity?
The ability to choose the right level of specificity. It is the same benefit we gain from being able to make a distinction between a destination versus a queue or topic. The ability to choose between different levels of specificity in a taxonomy allows for a precision of expression that better communicates a writer's intent to a reader. When programming we have the luxury/curse that the CPU will interpret our instructions in only one way and we are forced to use it's level of precision. But in human language we need nuance and precision to convey meaning efficiently.
T.Rob, awesome, but could you clarify "User - subset of principal"? If John is the subject and "account #123" is his principal, the user is who? Are there two John's? Since Genus > Species > Individual is increasingly specific, John (user) should be more specific than John (subject). Or am I missing something?
Consider two principals where #123 is John and #124 refers to a service account. We probably want to treat these different regarding things like password policy, login capability, etc. Principals of type 'user' are subject to password complexity and expiry policies whereas principals of type 'service account' may not even have a password. When we start categorizing types of principal we create subsets. Does that help? Or did I just stir up more mud?
Yes, that helps. So, concretely, any corrections to the following? You might want to copy and paste it to an editor like Notepad++ and put a linebreak before each John (SO disallows linebreaks in comments): John (human) SUBJECT > username_1 PRINCIPAL > password_1 USER John (human) SUBJECT > username_1 PRINCIPAL > password_2 USER John (human) SUBJECT > username_1 PRINCIPAL > smartcard_1 USER John (human) SUBJECT > username_1 PRINCIPAL > cellphone_1 USER
b
bluish

Have a look at my Authentication concept map:

https://i.stack.imgur.com/5bT0L.jpg


Very cool diagram. But I do not see neither subject, nor principal, nor user. That means, that at least some comments to the diagram are necessary.
For those who seek Subject, Principal, and User nodes, all of them are near the bottom part of the diagram.
C
Community

I think the terminology is taken from JAAS.

When an application uses JAAS authentication to authenticate the user (or other entity such as a service), a Subject is created as a result. The purpose of the Subject is to represent the authenticated user. A Subject is comprised of a set of Principals, where each Principal represents an identity for that user. For example, a Subject could have a name Principal ("Susan Smith") and a Social Security Number Principal ("987-65-4321"), thereby distinguishing this Subject from other Subjects.


I have seen this definition before, its too dense, can you elaborate on it, especially how a user is different than a principal, why the term subject is used and not just user. If these terms have meaning beyond JAAS I very much want to become familiar with that meaning, if these terms are inventions of JAAS then I guess the Sun Engineers that created it picked poor names for whatever these concepts means. I have asked quite a few programmers this questions and have not been able to get clear answers, every one seems to have a different understanding of these terms.
Seems like a Principal is just one way to identify a Subject. Put another way, any Principal could theoretically serve as a primary key on your user database.
The lexicon predates JAAS by a long shot. JAAS just reuses some of it and at times in non-standard ways. Part of the problem that prompted this question is that the concepts are learned from the contexts in which the terminology is used and then reused in slightly different ways. When authoritative sources are hard to find or simply ignored, the meanings drift over time. When it comes to security where precision is an absolute requirement this drift toward ambiguity degrades our ability to build and implement secure designs.
@T.Rob do you any paper titles, or authoritative references that you can share.
Unfortunately, even the authoritative sources disagree. SANS doesn't define principal or subject at all bit.ly/hl4rUP and NIST bit.ly/fE7NJs defines subject specifically as a person. Other "authoritative" sources are similarly vague which, considering the importance of clarity in this field, is rather disappointing. The IEE has a glossary but you can only read it with membership or subscription so it has limited use in a discussion with a wide audience. I was basing my response in part on Shon Harris' CISSP Exam Guide.
r
rahulmohan

Subject is the entity that requests a service. It can be a user or a process. Probably that is why the name Subject was chosen instead of user.

When a subject tries to access a service, the subject has to be authenticated first. Successful authentication ends with loading the Security Principals for that Subject. For example, in a Role Based Access Control system, an authenticated (logged-in) user will usually have two principals - userId and roleId. In such systems, the privileges(i.e who can access what) are specified for both roles and for users. During authorization(i.e checking whether the requested service should be permitted), the security system will check for accessibility against both the principals.

Therefore, from the perspective of authorization, principals are the actual entities for which access is allowed or disallowed. Subject is just a user/thread/process that holds some principals.


What is benefit of having multiple principles per subject?
I can think of two benefits: (1) Consider user Alice with principals UserId("Alice"), Role("Manager"), Department("Sales") accessing a service (the Object). The service access control can then be specified as "Allow for Role(Manager)" or "Disallow for Department(Sales)" etc. instead of specifying whether Alice can access it or not. Such kind of access control systems are easier to manage since the security administrator need not specify access privileges for ALL users for ALL services.
(2) In an enterprise system, users usually have to be authenticated with multiple systems before some composite service can be executed. It could happen that each of those systems have its own access control mechanisms requiring different details - one system uses SSN, and another uses userId. Thus the same subject should possess both the principals for it to access both
I get the feeling that 99% of confusion with this terminology could be resolved with one sentence along the lines of, "a principal is basically a group".
?! ... why you say a Principal is a Group?
R
Rafael

As T.Rob explained, Subject is any entity that requests access to an object. Starting from that point I've found a comment on javax.security.auth.Subject code that i've found VERY useful and easy to understand:

"Subjects may potentially have multiple identities. Each identity is represented as a Principal within the Subject. Principals simply bind names to a Subject. For example, a Subject that happens to be a person, Alice, might have two Principals: one which binds "Alice Bar", the name on her driver license, to the Subject, and another which binds, "999-99-9999", the number on her student identification card, to the Subject. Both Principals refer to the same Subject even though each has a different name."

Hope it helps.


f
fgul

This is the link for below explation from Oracle JAVA SE Documentation.

Subjects, Principals, Authentication, and Credentials To authorize access to resources, applications first need to authenticate the source of the request. The JAAS framework defines the term subject to represent the source of a request. A subject may be any entity, such as a person or service. A subject is represented by the javax.security.auth.Subject class. Authentication represents the process by which the identity of a subject is verified, and must be performed in a secure fashion; otherwise a perpetrator may impersonate others to gain access to a system. Authentication typically involves the subject demonstrating some form of evidence to prove its identity. Such evidence may be information only the subject would likely know or have (such as a password or fingerprint), or it may be information only the subject could produce (such as signed data using a private key). Once authenticated, a Subject is populated with associated identities, or Principals (of type java.security.Principal). A Subject may have many Principals. For example, a person may have a name Principal ("John Doe") and an SSN Principal ("123-45-6789"), which distinguish it from other Subjects. In addition to associated Principals, a Subject may own security-related attributes, which are referred to as credentials. A credential may contain information used to authenticate the subject to new services. Such credentials include passwords, Kerberos tickets, and public key certificates. Credentials might also contain data that enables the subject to perform certain activities. Cryptographic keys, for example, represent credentials that enable the subject to sign or encrypt data. Public and private credential classes are not part of the core J2SE API. Any class, therefore, can represent a credential.


Although I agree with T.Rob's answer, this one from Aram--which says "a subject may be any entity"--hints at ERM: the Entity-Relationship Model underpinning most databases. In that model, "entity" corresponds to "subject" in the context of security, but depending on what you're modeling, it could be the principal (bank account, SSN #) or user (John Smith), as suggested in Marinus' answer. Wikipedia: en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
C
ChinaJavaDeveloper

according to rahulmohan,i think , before Authentication is subjet , after Authentication is pricipal, in difference sence, a subjet may have many pricipal