3 ms·

There is no centralized auditing of derivative macaroons, but there could be of verification of those macaroons - you still require a centralized service which

by dwaite 3y ago

There is no centralized auditing of derivative macaroons, but there could be of verification of those macaroons - you still require a centralized service which knows the core HMAC secret to give a thumbs up or thumbs down. To that end you can define auditing information even when there aren't really caveats - user A appending that they are giving a version of the macaroon to user B with no restrictions on use. Since there isn't a domain language, you have to define all this. JSON can be useful to have an extensible notation for describing this, although you need to up-front declare the difference between information which can be ignored and caveats which much result in failure if not understood.

tptacek 3y ago
Note also that in our scheme, if Alice attenuates a token and gives it to Bob, Bob will still have to hit our login service to "activate" the token (that's the word I should have used in the post and I'm kicking myself for not thinking to express it that way) by clearing the third-party auth caveat we put on every token. So it's not as if we have no auditing of token delegation. Still: if only for revocation purposes, I'd probably just mint a new token for e.g. a contractor (and certainly for every user). The nice thing about the system is that you can edit the tokens after we give them to you so you're not stuck with our role definitions, which I think is a significant win, but doing all of IAM without talking to our servers more than once, while a cute technical stunt, is probably not all that valuable to users.
- dwaite 3y ago
  > Bob will still have to hit our login service to "activate" the token. I think thats what I was saying - on first verify your centralized system will know the contents of the token and can do appropriate auditing. In practice I find that keeping processing simple is a challenge. It doesn't naturally say as simple as one would like, with orthagonal caveats that can be processed independently and independent of centralized knowledge. For example, you might expect the user to indicate the system they are calling in a caveat, an audience value. However, if you either make this true a restriction on further use it will prevent any sort of delegation, which may include delegation to internal systems that the user didn't know about. You don't want to outright ignore it either. So you have some sort of policy interpretation of that restriction, such as 'this audience means this set of services can use this macaroon' or 'we will audit internal use based on this audience but take no action', or even crazier you color caveats before and after this point as being ones set by the user vs ones set by the service. This sounds a bit contrived, but it does loop back into one of the core usages I've seen for macaroons - gaining proof of possession or other sender verification rather than using bearer-style tokens.

by dwaite 3y ago

tptacek 3y ago

Note also that in our scheme, if Alice attenuates a token and gives it to Bob, Bob will still have to hit our login service to "activate" the token (that's the word I should have used in the post and I'm kicking myself for not thinking to express it that way) by clearing the third-party auth caveat we put on every token. So it's not as if we have no auditing of token delegation. Still: if only for revocation purposes, I'd probably just mint a new token for e.g. a contractor (and certainly for every user). The nice thing about the system is that you can edit the tokens after we give them to you so you're not stuck with our role definitions, which I think is a significant win, but doing all of IAM without talking to our servers more than once, while a cute technical stunt, is probably not all that valuable to users.

dwaite 3y ago
> Bob will still have to hit our login service to "activate" the token. I think thats what I was saying - on first verify your centralized system will know the contents of the token and can do appropriate auditing. In practice I find that keeping processing simple is a challenge. It doesn't naturally say as simple as one would like, with orthagonal caveats that can be processed independently and independent of centralized knowledge. For example, you might expect the user to indicate the system they are calling in a caveat, an audience value. However, if you either make this true a restriction on further use it will prevent any sort of delegation, which may include delegation to internal systems that the user didn't know about. You don't want to outright ignore it either. So you have some sort of policy interpretation of that restriction, such as 'this audience means this set of services can use this macaroon' or 'we will audit internal use based on this audience but take no action', or even crazier you color caveats before and after this point as being ones set by the user vs ones set by the service. This sounds a bit contrived, but it does loop back into one of the core usages I've seen for macaroons - gaining proof of possession or other sender verification rather than using bearer-style tokens.