Skip to content
This repository has been archived by the owner on Sep 18, 2021. It is now read-only.

Impersonation in client credentials or resource owner context #2813

Closed
ChrisSimmons opened this issue Apr 26, 2016 · 2 comments
Closed

Impersonation in client credentials or resource owner context #2813

ChrisSimmons opened this issue Apr 26, 2016 · 2 comments
Labels

Comments

@ChrisSimmons
Copy link
Contributor

We have a situation where we "own" all facets of the authentication stack: the resources (APIs), the client store, and identity server. We maintain a custom WPF client where we would like to point to these APIs and impersonate the operating user. We look to the WPF ambient context to provide the current user's name and are making a conscious decision to trust that username. We are also consciously considering the WPF app to be a confidential client. The basic requirements here are that the API has reasonable certainty of the identity of both the acting user and the client. I see two methods to do this:

  • Use the Resource Owner Password Credentials flow and:
    • Pass a dummy password for the user
    • Check on the IdentityServer side (I assume in AuthenticateLocalAsync or PreAuthenticateAsync) that the specific client is permitted to impersonate the given user
    • Add a custom claim to identify the client (which I don't think is normally a part of the access token here, correct?)
  • Use the Client Credentials flow and:
    • Use additionalValues in OAuth2Client.RequestClientCredentialsAsync() to include an "impersonate:username" key/value pair.
    • Use a custom IClaimsProvider
    • Examine the ValidatedRequest.Raw values and, if the "impersonate" pair is there, validate that the client is permitted to impersonate the given user and add the claim to the outgoing claims.

Is one approach better than the other? Or are we approaching this completely wrong?

@leastprivilege
Copy link
Member

OK - well option #1 sounds more reasonable for your situation. The client_id is automatically included in the access token.

@ChrisSimmons
Copy link
Contributor Author

Thanks, Dominick!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants