-
Notifications
You must be signed in to change notification settings - Fork 40
Auth
A quick word on language. I believe that the main reason people do not understand Authentication and Authorization is that they both have the same prefix - auth. Although these two concepts are related in the context of user management, they are entirely different things and should be treated as such.
You should never EVER say the word "auth". This word has no meaning and it leads to confusion. It is but a prefix and does not give anyone enough information to understand what you are talking about. If you want to talk about user management as a whole, say user management, or users. Otherwise, be specific. If you are talking about the process of determining the identity of a particular remote user, this process is "authentication" and may be shortened to "authn" if you are pressed for time. If you are talking about the process of determining the level of access that a particular user has to a particular resource, the word for that is "authorization" and may be shortened to "authz" if need be.
Authentication is the process of determining the identity of a remote user. If you are in a hurry, the ONLY acceptable short form of the word "authentication" is "authn." If you only say "auth," you are not providing enough information to determine what you are talking about.
If the words "permission" or "access" are anywhere in your head right now, GET RID OF THEM, for they have nothing at all to do with authentication. A user may authenticate in any number of ways; either using local information ("local login"), using SSO like Shibboleth or Cosign, more cloud-based SSO like Facebook, Google, OpenID, OAuth, Mozilla Persona, etc.
From authentication, you should be able to receive an object with information pertaining to a particular authenticated user. This object will contain the user's Preferences. Some of these preferences, such as "username" or "email" or "given name" may not be user-changeable depending on how the authentication system works; for example, your university's Shibboleth system probably provides given name, username, and student ID, but it does not provide a mechanism for users to change this information from an arbitrary service provider. However, the SSO system could be intelligent enough to provide a link on the user object to a central place where they CAN change these preferences. If this is the case, that link should be available from the user within your service providing software.
Any distinct user should be able to authenticate through one or more means. I specifically mention this, because if I have already established a login on your site through your local login mechanism but later decide that I also want to be able to use my Google account to authenticate, this should be easy for me to do, and no data should be lost. Information that comes from whatever remote SSO system is used should be CACHED LOCALLY, in case the user authenticates through a different mechanism.
The user object is something that should be built from various sources. I recommend doing a listener pattern event thing here, where the authenticator can announce, "jtickle has authenticated, who wants to give him some data," and then modules within the system can build on that user object. Off the bat, you will need to combine whatever comes in from SSO with locally stored preferences; and other installed software may wish to provide additional data, such as what clubs that user is a member of.
At this point, we know who the user is, we know that they are who they say they are, and we have some more information about them on the user object. If you are in a hurry, the ONLY acceptable short form of the word "authorization" is "authz." If you only say "auth," you are not providing enough information to determine what you are talking about. "Auth" is not a word that should EVER be used - be specific and either say "authn" or "authz."
Authorization happens whenever the user attempts to access any resource. The question is, "Can this user do this action to this resource?" The answer is either "yes" or "no" -- literally, a PHP boolean value. If the answer is "maybe," then your permissions are not fine-grained enough.
PLEASE NOTE: It is surprisingly common that a user may successfully authenticate but not have access to anything. In our implementation, there is no distinction whatsoever (at the authz layer) between an unauthenticated user and an authenticated user with no permissions. The distinction happens in the "authentication" layer, not the "authorization" layhttp://jasny.github.io/bootstrap/index.htmler. Even the unauthenticated user can and should have a User object within the system! They have been authenticated as "unauthenticated", or "guest". Just like a user who has been authenticated but has no access within the system - they are the same as a guest. In fact, everyone's initial user object should be cloned from the guest object and then worked with.
First, users are authenticated. There is ALWAYS a user object available. Of course, if the user has not gone through the authentication process, then they are only authenticated as a guest user for now. You can change from being a guest to being a user with permissions by logging in somehow.
Because authn and authz are kept separate, you can do some pretty cool things. You have a legitimate object for a guest user, to which permissions can be assigned just like any other user. In the default content management system pattern of thinking, the guest user has read access to any web pages, but does not have write access to anything, and does not have read access to administrative features. These things should be explicitly set within the authz system, although we can set some reasonable defaults before we ship.
Also, consider that you are part of a university and have a big single sign-on system. You can now say to the user, "We see that you are who you say you are, but still, no one has granted you access to this object. Please contact administrator@example.com to discuss your access." You can write log entries about this user's movement throughout your site and associate those movements with an actual identity, but they don't have access to anything. In the older way of thinking, authentication was tied to a small level of authorization, and effectively meant that authenticated but unauthorized users were given no indication that their authentication had been successful but they had no access.
There is also the case wherein you actually want authentication to imply a level of authorization. For example, let's say you have a few pages that you don't want just anyone to be able to see, should be accessible to people within your organization. In this case, when the user authenticates, there will be some kind of "implied authorization" module (see that bit about events in the authentication section) wherein you can specify what permissions should be granted to an authenticated user that does not necessarily need an individual account on the local site. This will keep your database cleaner (since you don't have to store a local user object with its own permissions for EVERYONE in your organization) and it makes it so you have to explicitly say that someone gets permissions after authenticating, which gives you more control over your content.
"Strong" authentication is defined as "layered authentication approach relying on two or more authenticators to establish the identity of an originator or receiver of information" by the US Government's National Information Assurance Glossary. We should be able to support this! "You have authenticated with Shibboleth but you are required to authenticate against a second system as well." Like one of those smartphone authenticator apps, or RSA SecurID token, or some such.
Also, I just read about an interesting concept that I haven't had time to think about but it sounds like something we should support: