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

Question

In the context of security frameworks, a few terms commonly occur subject, user and principal, of which I have not been ab

Answer 1

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.

Answer 2

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

Answer 3

Have a look at my Authentication concept map:

Answer 4

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.

Answer 5

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.

Answer 6

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.