The key thing there is that the two steps are largely separable. One of the biggest flaws in most security systems is tying them together because authorisation is context dependent. Software acting as me is authorised to perform specific actions for specific purposes, not in general. It is hard to implement the principle of least privilege and almost impossible to implement the principle of intentionality if you tightly couple them.
Interesting example of buying alcohol (never thought about it).
My primary example tends to be an employee badge that is verified at the front door by a security personnel (AuthN). Once you are allowed entry into the office, AuthZ determines which areas are you allowed to access (doors to certain labs, HR and Finance filing offices, etc. may not unlock with the same badge). Of course, most of the time the discussion about AuthN and AuthZ is with engineers, so this example is pretty close to home.
Also, the buying alcohol example is uniquely Western, and may not apply to all audiences worldwide.
What’s weird to me is that OpenId Connect does authentication, but, that’s a protocol on top of OAuth which does authorization. AuthZ should come first, but isn’t that backwards? I don’t really get it, not yet anyway.
Well, openID is about identification, which is what authentication is also about.
It doesn’t really make sense to do authorization and then authentication. That would be like the shopkeeper checking whether your ID says you’re old enough, then selling you the alcohol and then only afterwards checking if the ID is yours: by then it doesn’t matter because you’ve already got the alcohol.
This depends a lot on the situation. To give a real-world example, my front door checks that I am authorised to open it by checking whether I have a key. It doesn’t perform authentication at all and that is a feature: the key works if I lend it to someone.
In a lot of situations, you don’t care which party is performing an action (except, perhaps, for audit logging), you just care that they are authorised to perform that action. If I have a private repository, for example, I might care a lot about who pushes to it so that I know who introduced bugs, but not care who downloads it as long as they are people that I have authorised to do so.
I was trying to say that I think it makes sense to do authorization only, or to do authentication and then authorization, but that it does not make sense to do authorization and then authentication.
That said, your example made me think of some examples where authentication is optional, and then you might want to authorize and then (optionally) authenticate (e.g. pushing a mix of signed and unsigned commits to github).
I think the use cases where you’d want to do authorization and then authentication are ones where you’re doing authentication solely for auditing. This is especially common if you have a low-privilege step that you don’t need attribution in your audit logs and a high-privilege step where you do. I suppose this can be thought of as authorise-only then authenticate-then-authorise, because then you’d want to ensure that you had the information for your audit log before you permitted the operation that required authentication.
I can be more broad. Following this introduction, I might say, more strongly, that it is a mistake to attempt to establish the identity of an agent. The underlying problem is that the agent is not required to actually correspond with any identities!
Audit logs should directly record information which reconstitutes the invoked capability; this is called the “sturdy capability” or “sturdycap” pattern. Data breaches are automatically attenuated by capabilities; less investigation is required overall.
Regulatory compliance is an umbrella term. Do you have something more specific in mind? KYC regulations aren’t actually about agent identity at the API barrier, but about prerequisites to entering certain contractual agreements. In general, capability designs or other need-to-know designs are orthogonal to such regulations.
KYC asserts a domain that defines a verb (know) and a noun (customer) which require precise definitions. Customer is absolutely an [agent] identity, that must be unique at the boundary of its domain, and must be invariant to any given contractual agreement within that domain. If user A creates independent contractual obligations C1 and C2, then it’s not like you can say that the producer of C1 is different than the producer of C2. In some contexts, maybe, sure. But in terms of KYC, no way.
Data breaches are automatically attenuated by capabilities; less investigation is required overall.
It sounds like you’re assuming the use of capability-based security when the post that is the context of this comment thread never mentions it. I’m sure I’m too ignorant to discuss capabilities, so maybe I missed some reference to them.
Do you have something more specific in mind? KYC regulations […]
I was thinking not of customers but of employees — tracking which employees access which data, e.g., for the USA’s HIPAA:
OCR’s investigation into the complaints revealed that from 2005-2008, unauthorized employees repeatedly looked at the electronic protected health information of numerous other UCLAHS patients. —HHS.gov
Organizations must develop […] procedures to hold members of the workforce accountable for their actions when accessing ePHI through the electronic health record (EHR). —AHIMA.org
Maybe you would say that that would be less important with enough use of capability-based security.
The underlying problem is that the agent is not required to actually correspond with any identities!
After reading zie’s comment, I suspect I may have been mistaken in reading “It is not important to establish the identity of an agent” as “It is not important to establish whose credentials are being used”.
The problem is, you can’t really do ANY of those things with any technical certainty. Certainly it’s really nice to know Tootie changed this record. But you don’t actually know that. At some point you authenticated Tootie and then authorized Tootie to change the record. But after that fact, you don’t know what Tootie did with that authority. Did Tootie sell the access to an enemy? Did she take care to keep her authentication token(s) secure? Did an evil person steal them and pretend to be Tootie?
You can’t know any of those things from your audit logs. You can only know that Tootie’s capability was used to change record A. Further knowledge on if Tootie actually did it requires more investigation(like maybe talking to Tootie for instance).
That’s one of the points of going down the capability model, it forces those complexities to be dealt with out in the real human world where it has to be dealt with and not in the system, where it can’t be known and can only be guessed at.
Sadly we really screwed up here and didn’t make cap systems easier for humans to deal with and ran down the easier to initially think about model that screwed up so much of our system security, such that many(most?) security problems are from this lazy method we decided to use instead.
Yes, but without the specific AuthN of “Tootie” in some audit/access log somewhere (rather than just the generic AuthZ of “Can change record A”), we’re missing key forensic info we’d need to investigate the incident. How would you even know to “talk to Tootie” if the AuthN isn’t recorded? How would you know that it’s Tootie’s account that might have been breached rather than Bob’s?
Who said you couldn’t log that information? It’s just a record entry though, it’s not special to the system, like in more traditional AuthN/AuthZ architecture.
Did Tootie sell the access to an enemy? Did she take care to keep her authentication token(s) secure? Did an evil person steal them and pretend to be Tootie? […] Further knowledge on if Tootie actually did it requires more investigation(like maybe talking to Tootie for instance).
Indeed, these are questions that I had had in mind, and I had imagined as a next step questioning the person whose credentials were used.
Maybe my crucial mistake was interpreting “It is not important to establish the identity of an agent” as advising not knowing whose credentials were used — if that information is tracked, then my uninformed qualms do not apply.
Once the agent has the capabilities it needs, then sure, but at some point prior to that someone would typically need to be authenticated before they receive their first capabilities.
Edit: and if you want to be able to revoke capabilities then the ownership/ancestorship of capabilities needs to be stored somewhere, making them effectively tokens that authenticate and authorize.
There are three sources of capabilities. Yes, capabilities can be granted at the time that an actor is created; but they can also be granted during interaction with the actor, and the actor can create their own capabilities from scratch.
Revocable capabilities can be built from cryptographic primitives, so that there is no notion of ownership, merely a notion of holding a cryptographic token. For example, Tahoe-LAFS has mutable files, and a read capability for a mutable file is like a revocable capability. Once this nuance is understood, then your objection becomes a boon: The capability is the token which authorizes access.
The key thing there is that the two steps are largely separable. One of the biggest flaws in most security systems is tying them together because authorisation is context dependent. Software acting as me is authorised to perform specific actions for specific purposes, not in general. It is hard to implement the principle of least privilege and almost impossible to implement the principle of intentionality if you tightly couple them.
Well said. The idea of separating them isn’t all that intuitive to a ‘layperson’ though.
Interesting example of buying alcohol (never thought about it).
My primary example tends to be an employee badge that is verified at the front door by a security personnel (AuthN). Once you are allowed entry into the office, AuthZ determines which areas are you allowed to access (doors to certain labs, HR and Finance filing offices, etc. may not unlock with the same badge). Of course, most of the time the discussion about AuthN and AuthZ is with engineers, so this example is pretty close to home.
Also, the buying alcohol example is uniquely Western, and may not apply to all audiences worldwide.
And of course, AuthZ comes AFTER AuthN. :)
What’s weird to me is that OpenId Connect does authentication, but, that’s a protocol on top of OAuth which does authorization. AuthZ should come first, but isn’t that backwards? I don’t really get it, not yet anyway.
Well, openID is about identification, which is what authentication is also about.
It doesn’t really make sense to do authorization and then authentication. That would be like the shopkeeper checking whether your ID says you’re old enough, then selling you the alcohol and then only afterwards checking if the ID is yours: by then it doesn’t matter because you’ve already got the alcohol.
This depends a lot on the situation. To give a real-world example, my front door checks that I am authorised to open it by checking whether I have a key. It doesn’t perform authentication at all and that is a feature: the key works if I lend it to someone.
In a lot of situations, you don’t care which party is performing an action (except, perhaps, for audit logging), you just care that they are authorised to perform that action. If I have a private repository, for example, I might care a lot about who pushes to it so that I know who introduced bugs, but not care who downloads it as long as they are people that I have authorised to do so.
I was trying to say that I think it makes sense to do authorization only, or to do authentication and then authorization, but that it does not make sense to do authorization and then authentication.
That said, your example made me think of some examples where authentication is optional, and then you might want to authorize and then (optionally) authenticate (e.g. pushing a mix of signed and unsigned commits to github).
I think the use cases where you’d want to do authorization and then authentication are ones where you’re doing authentication solely for auditing. This is especially common if you have a low-privilege step that you don’t need attribution in your audit logs and a high-privilege step where you do. I suppose this can be thought of as authorise-only then authenticate-then-authorise, because then you’d want to ensure that you had the information for your audit log before you permitted the operation that required authentication.
It is not important to establish the identity of an agent. It is only important to establish the capabilities of an agent.
That’s rather a broad statement. What about audit logs? What about regulatory compliance? What about investigating security breaches?
I can be more broad. Following this introduction, I might say, more strongly, that it is a mistake to attempt to establish the identity of an agent. The underlying problem is that the agent is not required to actually correspond with any identities!
Audit logs should directly record information which reconstitutes the invoked capability; this is called the “sturdy capability” or “sturdycap” pattern. Data breaches are automatically attenuated by capabilities; less investigation is required overall.
Regulatory compliance is an umbrella term. Do you have something more specific in mind? KYC regulations aren’t actually about agent identity at the API barrier, but about prerequisites to entering certain contractual agreements. In general, capability designs or other need-to-know designs are orthogonal to such regulations.
KYC asserts a domain that defines a verb (know) and a noun (customer) which require precise definitions. Customer is absolutely an [agent] identity, that must be unique at the boundary of its domain, and must be invariant to any given contractual agreement within that domain. If user A creates independent contractual obligations C1 and C2, then it’s not like you can say that the producer of C1 is different than the producer of C2. In some contexts, maybe, sure. But in terms of KYC, no way.
It sounds like you’re assuming the use of capability-based security when the post that is the context of this comment thread never mentions it. I’m sure I’m too ignorant to discuss capabilities, so maybe I missed some reference to them.
I was thinking not of customers but of employees — tracking which employees access which data, e.g., for the USA’s HIPAA:
Maybe you would say that that would be less important with enough use of capability-based security.
After reading
zie’s comment, I suspect I may have been mistaken in reading “It is not important to establish the identity of an agent” as “It is not important to establish whose credentials are being used”.The problem is, you can’t really do ANY of those things with any technical certainty. Certainly it’s really nice to know Tootie changed this record. But you don’t actually know that. At some point you authenticated Tootie and then authorized Tootie to change the record. But after that fact, you don’t know what Tootie did with that authority. Did Tootie sell the access to an enemy? Did she take care to keep her authentication token(s) secure? Did an evil person steal them and pretend to be Tootie?
You can’t know any of those things from your audit logs. You can only know that Tootie’s capability was used to change record A. Further knowledge on if Tootie actually did it requires more investigation(like maybe talking to Tootie for instance).
That’s one of the points of going down the capability model, it forces those complexities to be dealt with out in the real human world where it has to be dealt with and not in the system, where it can’t be known and can only be guessed at.
Sadly we really screwed up here and didn’t make cap systems easier for humans to deal with and ran down the easier to initially think about model that screwed up so much of our system security, such that many(most?) security problems are from this lazy method we decided to use instead.
Yes, but without the specific AuthN of “Tootie” in some audit/access log somewhere (rather than just the generic AuthZ of “Can change record A”), we’re missing key forensic info we’d need to investigate the incident. How would you even know to “talk to Tootie” if the AuthN isn’t recorded? How would you know that it’s Tootie’s account that might have been breached rather than Bob’s?
Who said you couldn’t log that information? It’s just a record entry though, it’s not special to the system, like in more traditional AuthN/AuthZ architecture.
Indeed, these are questions that I had had in mind, and I had imagined as a next step questioning the person whose credentials were used.
Maybe my crucial mistake was interpreting “It is not important to establish the identity of an agent” as advising not knowing whose credentials were used — if that information is tracked, then my uninformed qualms do not apply.
Once the agent has the capabilities it needs, then sure, but at some point prior to that someone would typically need to be authenticated before they receive their first capabilities.
Edit: and if you want to be able to revoke capabilities then the ownership/ancestorship of capabilities needs to be stored somewhere, making them effectively tokens that authenticate and authorize.
Your points sound like the Equivalence and Irrevocability Myths from “Capability Myths Demolished”.
There are three sources of capabilities. Yes, capabilities can be granted at the time that an actor is created; but they can also be granted during interaction with the actor, and the actor can create their own capabilities from scratch.
Revocable capabilities can be built from cryptographic primitives, so that there is no notion of ownership, merely a notion of holding a cryptographic token. For example, Tahoe-LAFS has mutable files, and a read capability for a mutable file is like a revocable capability. Once this nuance is understood, then your objection becomes a boon: The capability is the token which authorizes access.
[Comment removed by author]