Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Authorization terminology is a mess: Let's fix it

idpro.org

Post reply on HN
Print view View original

61–70 of 91 posts

Re: Authorization terminology is a mess: Let's fix it

#61

Post by antonvs »

lozf wrote: post #32
Quarrelsome wrote: post #5

Nice! I'd like to fix the prior abstract. Auth and auth upsets me greatly cos we have: Authentication & Authorization and we call both/either auth. Hence please help me make this a thing: AuthENTIcation & AuthORIzation : ENTI & ORI ENTI- can you enter, ORI (or ORIZ) what can you do?

> ENTI- can you enter, ORI (or ORIZ) what can you do? I don't mean to quarrel about it, but I understood Authentication to be closer to identification. To provide "adequate proof that you are actually who you claim to be". Even the "can you enter" question falls under authorization; "does the user have appropriate permissions?" Entering is just one of perhaps many subsequent levels of permissions.

You're correct.

Re: Authorization terminology is a mess: Let's fix it

#62

Post by williamdclt »

black_knight wrote: post #25
williamdclt wrote: post #14

Earlier quoted context omitted.

I have more experience with authorization than most engineers, even engineers who have some experience with authn/authz, and I have no idea what that "subject can utter the action" or "transfer of nouns and verbs to perform the utterances" could mean

I chose those words here because they are not programming language specific. For the OOPers, I guess you can imagine I said “objects” and “methods”.

Not particularly an OOPer, but regardless tou're only making it less clear I'm afraid! "objects" and "methods" instead of what?

I'll make an educated guess that you mean "objects and methods" instead of "subject and action" or "noun and verb" respectively. But it's really the "utter" and "transfer" terminology that I have no idea what it might mean

Re: Authorization terminology is a mess: Let's fix it

#63

Post by jcdreads »

simonw wrote: post #39
andai wrote: post #10

Earlier quoted context omitted.

I'm maintaining a document called Tricksy words with multiple meanings that cause endless confusion and strife Just in the past year I have wasted several months pulling my hair out due to incorrectly named projects. It really does turn out naming is important!

I've worked at places where it turned out different parts of the organization had a different idea of what a "user" of the core product was. The team using Salesforce, the data warehouse team, the application development teams, all with different mental models of what "we added 5,000 users today" actually meant in concrete terms.

Oh man. This gets really exciting when in addition the Finance team has to tell the SEC how many active users there are, but they're using different definitions every quarter because they get their numbers in some non-reproducible way from whichever of those other teams has time to help them this month.

Source: my own years on data warehouse and application development teams.

Re: Authorization terminology is a mess: Let's fix it

#64

Post by antonvs »

sbuttgereit wrote: post #35
lozf wrote: post #32

Earlier quoted context omitted.

> ENTI- can you enter, ORI (or ORIZ) what can you do? I don't mean to quarrel about it, but I understood Authentication to be closer to identification. To provide "adequate proof that you are actually who you claim to be". Even the "can you enter" question falls under authorization; "does the user have appropriate permissions?" Entering is just one of perhaps many subsequent levels of permissions.

I think you've got the right idea, though in practice the initial "authentication" question (you are who you say you are) is very closely linked to the initial "authorization" evaluation (can you enter).... because in most systems the only "can you enter" authorization required for access is in fact that you are who you say you are. But not all systems work this way. There are some systems where you can log in succes…

One problem is that treating authentication as a "can you enter" authorization is predicated on the idea of a session-based system with two states, logged in or logged out. But there are many scenarios where e.g. taking some particular action requires authn and authz, regardless of login status. A simple example is performing some destructive action.

The distinction between authentication and authorization allows modeling of many different kind of systems, including the degenerate case where identification is treated as a proxy for authorization.

Btw, the kind of thinking behind that degenerate case is what leads to IDOR security bugs - "this person is logged in, so they can access whatever the URL says... even if it's another customer's data!" It turns out that thinking clearly about security helps be more secure, and unfortunately, vice versa.

Re: Authorization terminology is a mess: Let's fix it

#65

Post by zobzu »

da_chicken wrote: post #30
throwaway1058 wrote: post #22

Earlier quoted context omitted.

I feel "ought" is stronger and is something that is expected of you, but English is not my native language. "You should drink more water" "You ought to help your sick mother"

I'm a native speaker and I agree. "Ought" can connote an obligation or responsibility of some sort. "Should" is used more often when the outcome is out of any control. It might only be the speaker's belief. But there is significant overlap.

im not a native speaker and these always made perfect sense to me :(

Re: Authorization terminology is a mess: Let's fix it

#66

Post by simiones »

black_knight wrote: post #60
simiones wrote: post #55

Earlier quoted context omitted.

Oh, I'm sure it can be done, and what you're describing sounds quite nice. All I take issue with is the claim that this is a way to make the unauthorized actions "impossible to utter". The reality is that, at least at some level, you always have to evaluate a request and, based on some cryptography related to user identity, decide if you'll honor it or refuse it. That may be checking a cookie to look up the user and…

I would hate to argue over semantics. But in addition to the keys being checked automatically at run time, the type system ensured that, unless the capability had been revoked, illegal requests would not type-check at compile time. Which I think is pretty close to unutterable. The keys were there to stop an attacker, the type-checker helps the good guys stay in line.

> the type system ensured that, unless the capability had been revoked, illegal requests would not type-check at compile time

I don't think I can imagine what you mean here. How would my compilation success depend on whether an Admin has given me the right to read or write to a certain path?

Re: Authorization terminology is a mess: Let's fix it

#67

Post by zobzu »

hobofan wrote: post #9
Quarrelsome wrote: post #5

Nice! I'd like to fix the prior abstract. Auth and auth upsets me greatly cos we have: Authentication & Authorization and we call both/either auth. Hence please help me make this a thing: AuthENTIcation & AuthORIzation : ENTI & ORI ENTI- can you enter, ORI (or ORIZ) what can you do?

This has already been solved well-enough with AuthN and AuthZ as distinct names.

people still dont understand the difference. "you do iam but what about controllong access" comes in all the time.

words dont really matter all that much. people use them because it makes them sound like they know what it is, and if its important and complex, usually have no clue.

ive seen enough "abac" where the attribute is "your login name"

Re: Authorization terminology is a mess: Let's fix it

#68

Post by deathanatos »

rzzzt wrote: post #46
throwaway1058 wrote: post #22

Earlier quoted context omitted.

I feel "ought" is stronger and is something that is expected of you, but English is not my native language. "You should drink more water" "You ought to help your sick mother"

That's when you turn to the RFC2119 all-caps requirement levels!

> SHOULD — This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

You'll also need RFC 6919[1] for "OUGHT TO":

> The phrase "OUGHT TO" conveys an optimistic assertion of an implementation behavior that is clearly morally right, and thus does not require substantiation.

And the up-threads gut feel that "ought to" is slightly stronger comes across there, I think: ought to conveys that moral stance, where as "should" is more "there's a decision here, possibly".

[1]: https://www.rfc-editor.org/rfc/rfc6919.html; n.b., this is an April 1st RFC. I like it, though, and it isn't uncommon to see a stray "ought to" lacking a citation in a non-April-1st RFC.

Re: Authorization terminology is a mess: Let's fix it

#69

Post by black_knight »

simiones wrote: post #66
black_knight wrote: post #60

Earlier quoted context omitted.

I would hate to argue over semantics. But in addition to the keys being checked automatically at run time, the type system ensured that, unless the capability had been revoked, illegal requests would not type-check at compile time. Which I think is pretty close to unutterable. The keys were there to stop an attacker, the type-checker helps the good guys stay in line.

> the type system ensured that, unless the capability had been revoked, illegal requests would not type-check at compile time I don't think I can imagine what you mean here. How would my compilation success depend on whether an Admin has given me the right to read or write to a certain path?

First, I am talking about the capability based HTTP APIs I have worked on here. Not some imagined operating system. I can see if I get around to your question in the other sub thread.

But the point is, you would not grant access to a “path” or some such. You gain access to a collection of actions, described by types. It can be simple “get/set property” or more complicated actions, maybe involving capabilities to several things at once.

To mint such an access token the “admin” will have say how the actions are performed, and then pass the token to you. The client code then will have a typed set of actions it can perform using the token.

This does not mean that we compile in the specific rights of each user or anything, it only means that we must ensure a valid flow of rights in order for the whole program to compile. You can get a capability in two ways: you mint a capability for something you already can do (you are the admin and own the data base, say), or you receive it (via an API call, say).

There is definitely a knack to design the system with this kind of flow. But once in place it feels very natural, you get the right to do something just in time for your need to do it. Very much principle of least privilege taken to an extreme.

Re: Authorization terminology is a mess: Let's fix it

#70

Post by wky »

rzzzt wrote: post #46
throwaway1058 wrote: post #22

Earlier quoted context omitted.

I feel "ought" is stronger and is something that is expected of you, but English is not my native language. "You should drink more water" "You ought to help your sick mother"

That's when you turn to the RFC2119 all-caps requirement levels!

What I find strange about RFC2119 is technically RFC8174 amends it, yet the amended text never seems to be used.
Post reply on HN