Add claims to Client model

[brockallen]

To allow clients to have roles, for example.

Perhaps only allow this for client credentials and/or custom flow clients.

[ciaranj]

excellent was just trying to decide how to achieve this effect (felt a bit too 'open' just relying on scopes for client credentials flow.)

[ciaranj]

Hmm, so since this is now up for discussion, how should one achieve the goal of securing an operation (or operations) against particular clients where a human may not be involved, I'm loathe to assert on client_ids as that seems particularly fragile ?

[ciaranj]

@leastprivilege Sorry to bump, but how would you suggest one could achieve this without adding claims to clients, it seems reasonable to me that I might wish to grant certain trusted clients an 'admin role' for example, so my ACL only needs to assert on the role claim :) Or is the expectation that all IDsrv consumers will always do custom claimstransformation for that purpose?

[leastprivilege]

client and user authorization are two very different things. I wouldn't mix them.

But doing claims transformation in any case is the recommended practice.

[ciaranj]

I think I may have some worrying misconceptions in place in that case :( If I have an API endpoint that allows (for example) the creation of pre 'verified' users I only want actual end-user administrators to be able to do this normally (so that's a clear role-claim requirement on the user.) But I also want certain trusted applications to be able to do this in the background where there will be no human interaction, for example I might need to batch create users based on a CSV input overnight.

I can achieve this through a combination of having the client request a particular scope and changing my API's logic to assert either we've got a subject claim and relevant role claim OR we haven't got a subject claim but we have the relevant scope claim.

But that logic seems harder to understand the 'what principals can access this resource?' type of question than if both client-only tokens and client+subject tokens shared the same role claims.

When you say avoid mixing client and user authorization do you have any suggestions as to how I should tackle this problem (rather than my 'solution-eering' of what I think I want!)

I've googled and SO'd this but I couldn't find any clear patterns or practices on it (which I guess is a red-flag!)

[ciaranj]

Ok. So more thought leads to alternative strategies such as:

i) For each client like this I create a secondary user that has the roles I want and use ResourceOwner Flow to get the access token.
or
ii) Via some mechanism I provide a setup step that allows a specific user to request a long-lived access token (or refresh token) (code auth flow) that I persist (worrying) and have the requests use, rather than the client-credentials flow fetched tokens.

I'm surprised I'm the only person that wants to do something like this, but the 'discussion' so far seems like I am :(

@brockallen since you originally raised this issue do you have any thoughts ?

[brockallen]

Well, I opened the issue because we had the scenario where it was client-credentials flow and the API being invoked didn't want to code permissions based upon client id.

[leastprivilege]

So the plan is to add the ability to add claims to a client

couple of thoughts:

• should client claims only be sent when the client credentials flow is used - or always (or make it configurable)
• client claims must not conflict with user claims - so I was thinking of prefixing every client claim with "client_" - thoughts?

[ciaranj]

Well FWIW, I did my own implementation (for now) and I also restricted it to only being added during the client credentials flow. As to the client claims must not conflict with user claims, for my scenario where I want a specific 'role' to be associated with the client I guess I'm happy that my AuthZ logic checks for whether a token has a specific 'role' or 'client_role' I do have to admit though that I'm still unsure why this restriction (not conflicting) is so important (sorry) :( [I understand why there is a conflict when using non client-credentials flow as that could be misleading, but with client-credentials flow I'm unsure :/ ]

[leastprivilege]

added in dev - I made everything configurable.

[pashute]

@ciaranj could you show us some code and tell us what you did? You say you did your own implementation... So what is your idsrv3 code that gives the claims in client credentials flow, and what is the calling app's startup code to get those claims returned from idserv3? and how do you call the API with them?

You are not the only one who wants claims in client-flow returned along with the authentication of the client (according to the secret) in client-flow. You are also not the only one who would like no restriction on the claims, and no "special claims" for the claims-flow vs. the other flows (implicit, code and hybrid)

Please see #2319

[ciaranj]

@pashute that code has now been removed from my codebase as it is no longer needed as IDSrv3 supports the feature natively, sorry!