Security standards bodies, such as the Orange book or Common Criteria, require authentication, authorization and auditing. Authorization means you have to login. More formally, it means that you have to provide proof of your identity, and are issued a computer readable credential the reprentst that identity. Authorization refers to the rights and privileges granted to an authenticated entity. Finally, auditing is the trace in log files of actions of the authorized (or un-authorized!) activities.
Authorization is classified into manditory controls and discretionary controls. To me, the difference is not altogether clear. My best understanding is that discretionary controls allow a measure of freedom to the owner of the object, whereas manditory controls are fixed by the system as a whole, and the object owner cannot modify the control. For instance, the owner of a diary can make the contents of the diary available to other entities according to his or her own volition. However, the owner of a government classified document must yield to the policies regarding the document's classification. These two regimes tend to have different technological solutions, and are therefore distinguished.
In unix, it seems that a manditory control is that non-root users are constrained by the permissions of files, whereas root users are not constrainted. However, file permissions are more often associated with discretionary access controls, there the file's owner sets a series of nine bits to indicate the read, write and executablity of a file by user, group or world. It is a simple system that works not too bad. A more modern system is the Access Control List, which gives explicitly access rights for an object on a per entity basis. The Windows NT implementation is called the DACLS, Discretionary Access Control Lists.
The nature of an entity can be expanded to make the authorization mechanism more useful and efficient. Individually authenticated entities can be collected into a group, and permissions can be granted based on group membership. An entity can also be refered to in a contextualy way, as in the current owner of a certain object.
Permissions can also be attached to the entity, rather than the object, in the form of a capability. A capability is a right to use or modify an object, which can be shared or exchanged, according to the volition of the capability holder, and according the instructions contained in the capability. Somewhat related to the notion of a capability is a privilege, the rights of a user to preform actions which are not easily referenced to specific objects. They are like manditory capabilities.
Windows NT has several security mechanisms. For discretionary and auditing control, Security Descriptors attach to objects, such as files, and are matched to Tokens which are attached to threads and represent the authenticated entities which own the thread. The Tokens are created at login and attached to the process or thread, and inherited by all subsequently created thread or process, or loaned to other processes or threads by a process of Impersonation. The token contains the users SID, Security Idenfication, and the SID's of all groups the user belongs to. This is resolved at login, so changes in group member for a user is not propagated until the next login. The token also contains a vector of privileges.
The Security Descriptors contain DACLS, the discretionary access control lists, and SACLS, called System access control lists. The both DACLS and SACLS are an ordered list of ACE's, Access Control Entires. Each ACE contains a SID and a bit mask of 32 permissions. An ACE in a DACL can be of a sort that permits access, or of a sort that deny's access. In a SACL, an ACE enables auditing of the action matched by the permission mask. Permissions are classified as Standard, Specific or Generic. The standard permissions are in every ACE and refer to common actions for all objects. The specific permissions reference the particular secured object. The four generic permissions are bundles of standard and specific permissions according to generic actions understood across all objects.
Tokens contains the user SID as well as group SID's. A SID is a rather long number identifying a user, a group of users, or some other trustable entity. The SID is made up of a version number, a six byte top level authority, a variable number of 32-bit subauthorities, terminated by a 32-bit RID, a relative identity number. There are many well-known SID's, such as SYSTEM (the identifier for the kernel itself) and Local User, or Network User. A typical SID for a domain user looks like S-1-5-21-12340981-23421253-9872343-1010. Here 5 is the NT authority, 21 seems to mean the subauthority for created user or group names (?), the next three subauthorities together identify the operating system installation (that is, the computer, but really it is generated by the operating system at install time so it is the installation image) and then the UID 1010. All users and groups in the same NT domain will share the SID except for the RID.
NT groups are either local or global. Local groups reference a particular machine, whereas global groups reference an authentication domain, such as Windows Domains. Local groups can contain any user or global groups. Global groups can only contain global users (not groups) from the same domain as the group.
References
Traditional Unix authorized a user by using the information in the etc/passwd file. This file uses one-way hash functions to provide secure proof-of-knowledge, yet let the password file remain world readable. Upon authentication, the process gained the users's UID and GID (user and primary group ID), and these ID's would be inherited by fork to all following process which act on the user's behalf.
These identifiers were matched against the file systems permissions. Each item in the file system, including files, named pipes, devices, and do on, could specify read, write and execute permissions for (1) the file's owner, (2) any process with a given matching GID and (3) any other entity. Permission was granted to the owner according to the owner's permissions (even if greater permission was given to the group or other), and so forth. The permissions could be changed only by the owner (or root); the owner can be changed only by root; and the owner can change the group only to a group of which she is a member.
Users can belong to several groups, as specified in the etc/groups file. Only by access to this file can groups be created or modified. I am no longer sure whether Unix groups are dynamic. I believed they were, but some reading leads me to believe they are not: at login a scan is made of etc/groups and the the results are written into a kernel structure attached to the PID. However most Unices seem to have dynamic behavior, in that changes to the etc/groups will be reflected immediately in what is returned by, say, the id command. (Reader can experiment.)
The role of impersonation, or any sort of rights amplification, were accomplished with the SUID, SGID bits. When a program is executed (including shell scripts) and the program as the SUID bit set, the UID of the executing program takes on the UID of the owner for the duration of the run. It is a bit more complicated than that, as there was a need to return the execution level to the unprivileged state. So there was a real and effective ID. The SUID overwrote the effective id, but it was possible to "drop privilege" by copying the real UID into the effective UID. Various Unices differed in the details.