Order of authentication and authorization

Question

This is my first question here in Information Security SE. Is there a recommendation to help telling the scenarios where authentication should precede authorization from the ones where authorization comes first?

I experienced both situations at different workplaces (the situation was very similar, switching to a system user with a certain set of privileges in Unix command line). When does authorization need to come first to spare the authentication? When should it authenticate first so as to not to tell a potential intruder that the user impersonated would not be entitled for the current operation?

Are there situation specific generic guidelines or rules for this?

--

OK, let me come up with a specific situation. Logged in with own employee user ID, SUing to another user. I mistyped the system user I was about to switch to, but the other is also an existing user in our environment. Before asking for password, I got rejected saying I wasn't authorized to perform this operation.

Given that I just finished an anti-social engineering course today, I wondered whether it was a good idea to tell me I wasn't authorized (even this may be a useful piece of information for someone trying to impersonate me in the corporate network).

Answer 1

Authentication is about identifying who is issuing the command, and making sure that the caller is really that person/system. Authorization occurs necessarily after, since it is about deciding whether the duly authenticated requester should be allowed to proceed or not.

In your case with a su command, there are two authentication/authorization. Suppose that you are user "bob" and you want to do a su joe. It goes thus:

1. The su command authenticates the caller. The caller is bob. That authentication is transparent; as a human user, you do not see it: the su command asks the operating system who the caller is.

2. Now that the su command knows that the caller is bob, it wants to decide whether bob should be allowed to do a su into identity joe. This is authorization, and it occurs after authentication, as it should. Take note that the identity which is to be authorized is bob, not joe. At that point, there has been no authentication for joe, and the question is not about what joe can do, but what bob can do.

3. If the su command is happy with bob asking to become joe, it then proceeds. You do not reach that step in your case: the previous authorization decided that bob cannot do a su joe. However, if it had allowed it, then it would trigger the second authentication procedure, in which joe's password must be entered.

4. If the second authentication works, then you obtain a shell running under joe's UID. When you enter commands, authorization will be applied based on that authenticated identity: if, within the obtained shell, you want to read a file, read access rights for joe will be used.

To think sanely about authentication and authorization, always remember that authorization is for a specific identity. In the case of su, the authorization step is about whether bob can issue the command, not joe; therefore, since it uses "bob" as input, it feeds on a previous authentication step for bob with bob's password, not on the expected authentication which will use joe's password.

Answer 2

How can you know who you authorise if you haven't authenticated? Authentication always comes first, except when everyone is authorised or noone is authorised.

Edit: seems like you have two questions now :)

1) You were refused most likely because there is an access control policy that prevents your own original UID from performing an operation on the UID of the user you mistyped. It's your own UID that authenticated you (called an ambient authority) because the system that performs authentication checks trusts your system to provide an accurate UID. Your UID was not authorised so you were refused access.

As a side note, some auth server protocols like NIS failed to account for the fact that a user can locally escalate privilege and their local UID cannot be used as an authentication token. I honestly don't remember how a NIS+, LDAP or Kerberos server would check your identity before checking if you're allowed to use one of their resources (such as connecting to another account).

2) Some people believe that it's a good idea to obfuscate whether an authentication attempt worked by serving a honeypot session to the poor user that misspelt an ID or password. These people are wrong. If the system hadn't told you you were not authorised, you would not have noticed that you're not logged in onto the account you expected and you would not have been able to explain why the data you expected to find isn't here, or why the data you added during that session was not actually saved to that user's home directory. These interaction breakdowns are all but straightforward to recover from, and the security benefit of obfuscation is very debatable.

Answer 3

I agree with both answers given thus far by Thomas Pornin and Steve DL.

Authorization always comes after authentication since authorization is the act of looking at a given user's claims and determining whether the user can do what they are trying to do based on those claims and based on the authorization policies in place.

I would like to broaden the definition though and state that authentication is not necessarily about your identity directly (who you are) but rather about proving a the authenticity of a claim you make. A good example of that is when I go buy alcohol. The clerk couldn't care less who I am but they do care about my age (>21 in the US, >20 in Sweden, >18 in most places). So, when I show my driver's license / id card / passport, I'm proving my date of birth. The stamps, holograms, and other mechanisms on the card prove the authenticity of the claim (my date of birth). But the clerk isn't interested in my identity in itself.