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: 
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](http://dl.acm.org/citation.cfm?id=2535822) 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.
I agree with both answers given thus far by [Thomas Pornin](https://security.stackexchange.com/users/655/thomas-pornin) and [Steve DL](https://security.stackexchange.com/users/49936/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.