On richer custom claim values

[dvv]

Hi!

I'm exploring the ability to generate tokens with richer custom claims.
Say, I would like for app to define sub's access to a mercure hub:

{
  "sub": "MY-SUB-HERE",
  ...
  "mercure": {
    "publish": [ "kanidm" ],
    "subscribe": [ "kanidm" ]
  }
}

Today it's not possible to collect object-like claims. And if I go with kanidm system oauth2 update-claim-map app claim group '{"x":"y"}' the value is rejected due to OAUTHSCOPE_RE regex applied to the claim value.

First, I wonder if it's worth for rules on claim values to be relaxed?
Second, will it be possible to introduce kinda basic template expansion for claim values so that the following worked:

{
  "sub": "MY-SUB-HERE",
  ...
  "mercure": {
    "publish": [ "kanidm" ],
    "subscribe": [ "kanidm/MY-SUB-HERE" ] # NB: target sub is interpolated here
  }
}

TIA

[dvv]

I temporarily tweaked claim value regexp check and the resulting token reads:

"mercure": "{\"publish\":[\"kanidm\"],\"subscribe\":[\"kanidm\"]}",

which is indeed not what expected.

May be we could have "json" join type which collects custom claims to object-like token claim?
However, this can be treated as a corner case, so I doubt it's worth it.

Still, I leave the issue for at least discussion purpose.

[Firstyear]

Okay, after reviewing the oauth2 rfc, oauth2 token introspection rfc and openid connect specification, none of them apply restrictions to the claim values. This means we are free to expand this. However, I do want to continue to be conservative for the moment in what we allow in claim values, as I could forsee low-quality client applications being vulnerable to issues if we were to allow full character sets in the values.

For now I think we expand this a little, and allow future changes potentially. Small steps.

[Firstyear]

@dvv What changes to the claim value regex are you considering?

[dvv]

I would like to test the following cases:

1. Some basic interpolation. Here we could define a set of safe values that can be stuffed in the resulting string. I would start with ${sub} (safe as it's always a non-empty uuid); ${group} (the group which defines the claim, safe as it's regexp-checked); ${app}.

kanidm system oauth2 update-claim-map a1 can g1 'update:${group}' # { "can": ["update:g1"] }
kanidm system oauth2 update-claim-map mercure subscribe all '${app}/${sub}' # { "subscribe": ["mercure/111-222-333"] }

2. Object join strategy. This is to be able to collect object claims as in this issue' opening message.

UPD: so I think the procedure is: i) interpolate the value; ii) check if resulting value parses as a JSON object? yes -> stuff it in the claims as object; no -> stuff it as string.

TIA

[yaleman]

I'd support adding a "JSON" claim type, and only accept it if it's valid JSON object on the way in. That should constrain issues, at least.

[dvv]

When I say "interpolation" I mean lazy one.
So that

kanidm system oauth2 update-claim-map a1 can g1 'update:${group}' # { "can": ["update:g1"] }
# rename g1 to g2, effective claim given to the user to become `{ "can": ["update:g2"] }`

[yaleman]

Runtime interpolation/templating of claims gets into a huge space for security and other bugs, that's something likely to be FAR in the future unless someone provides a very well thought out design and implementation.

[dvv]

I'd limit templating to definitely safe sub, group (actual name), app (actual name) only.

[Firstyear]

I'm not adding templating, so don't get ahead of yourself. For now I'll allow the current rules around string OR valid json up to a maximum size. But I need time to implement it, which I am eternally short on.