51–60 of 91 posts
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?
ident and perms
Earlier quoted context omitted.
You seem to understand it just fine. Your accessor, dirB, should not contain the “upload files” verb, while your dirA accessor (noun) should. My favorite example is the home directory and the file picker. Why should a program have access to all your files by default then politely ask you which file it should read/write to? It would make more sense if the file picker was something the operating system ran when a progr…
First of all, this necessitates a certain data model, where instead of a "UploadFile(file, destPath)" operation, I have to have a "destPath.UploadFile(file)" operation. This would be ok for this case, but not all operations can be expressed in this simple parent -> child relationship. Furthermore, even here, this doesn't cover another case: what if I am allowed to add files to destPath, but I'm not allowed to modify…
So, “utter” there means make a valid request with a key. On both the client side and the server side the keys and validations were invisible to the business logic, they just carried objects as usual.
You created capabilities by registering a handler for the operation, and got back a token object you could hand out and even send over the api to those who were meant to use them. And the clients got these objects which they could just manipulate and keep around for making API requests.
The cool part was that you could never forget to do an authorisation check. The keys were automatically checked when the request came in. An API request handler would have no privilege itself, it would only call the key-validated handlers created when the capability was minted.
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!
Earlier quoted context omitted.
What you're describing is essentially what the authorization system would need to do in order to answer the question "can this subject perform this action on this object?". If you're suggesting that the program should receive a list a priori, then there are potential scale issues since that list would need to be exhaustive of both nouns and verbs, which can be a large set.
The point is to flip the burden of proof. Instead of an authorisation system trying to find a reason to give you permission, you have to carry the proof in the form of a “verb”. Which you use when you perform the action.
Do you mean that the directory should not be responsible for making this decision and there should be a central authorization authority?
Earlier quoted context omitted.
First of all, this necessitates a certain data model, where instead of a "UploadFile(file, destPath)" operation, I have to have a "destPath.UploadFile(file)" operation. This would be ok for this case, but not all operations can be expressed in this simple parent -> child relationship. Furthermore, even here, this doesn't cover another case: what if I am allowed to add files to destPath, but I'm not allowed to modify…
I have designed capability based HTTP APIs before, it took some work but the end result was ergonomic. Of course over the web the capabilities must be secured in some way. I opted for keys to prove that you can perform a given action. So, “utter” there means make a valid request with a key. On both the client side and the server side the keys and validations were invisible to the business logic, they just carried obj…
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 then checking a separate place to see if the user is authorized to perform the action (perhaps with an extra step of finding a role, etc), or it can be checking a "pre-approval" signature obtained at some earlier point as you're describing here, but it's ultimately the same concept, and isn't "implicitly handled" in one case anymore than the other.
Earlier quoted context omitted.
The point is to flip the burden of proof. Instead of an authorisation system trying to find a reason to give you permission, you have to carry the proof in the form of a “verb”. Which you use when you perform the action.
Right, but where do you get the proof to begin with? Using your OS example, it seems like the OS would need to precompute all of the possible accesses for the file picker? In this case, the OS is an authorization system. Do you mean that the directory should not be responsible for making this decision and there should be a central authorization authority?
A central authority is not a requirement. What is required is some way making sure capabilities are unforgeable.
This can be a central authority, which then has a completely mechanical task of registering capabilities and their ownership. But it can also be ensured “cryptographically” with a key.
The OS already has a capability system called “file descriptors”. Which works quite well, within its limited scope. This could be expanded out to more areas.
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!
Earlier quoted context omitted.
Right, but where do you get the proof to begin with? Using your OS example, it seems like the OS would need to precompute all of the possible accesses for the file picker? In this case, the OS is an authorization system. Do you mean that the directory should not be responsible for making this decision and there should be a central authorization authority?
There a sort of “might makes right” principle here. If you can do it, you can mint a capability for it, which means you will perform the action when someone with that capability requests it. A central authority is not a requirement. What is required is some way making sure capabilities are unforgeable. This can be a central authority, which then has a completely mechanical task of registering capabilities and their o…
Do you get a huge list of capability keys when you log into the system, one for each path? Do you ask a service for a capability when you want to perform the action?
Earlier quoted context omitted.
I have designed capability based HTTP APIs before, it took some work but the end result was ergonomic. Of course over the web the capabilities must be secured in some way. I opted for keys to prove that you can perform a given action. So, “utter” there means make a valid request with a key. On both the client side and the server side the keys and validations were invisible to the business logic, they just carried obj…
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…
The keys were there to stop an attacker, the type-checker helps the good guys stay in line.