I deploy a Keycloak-Instance. A requirement is for the Helpdesk to be able to impersonate users.
There is a impersonation-button in the Admin-GUI, great. But the Impersonation-Button gets me access_token for the account-console. I need token for other Clients. Is there a way of "Log into App X as User Y with Using my Admin-Permissions"?
The Impersonation-Endpoint seems not to provide a feature to specify the app to impersonate (https://www.keycloak.org/docs-api/15.0/rest-api/index.html#_impersonate).
EDIT: I'm sorry, it was caused by a bug on my side! Make sure that you aren't logged in in any other app in the realm and that you also don't trigger the logout-function of any app after pressing Impersonate! (or otherwise you have to redo everything)
Thanks in advance!
Impersonation in keycloak is realm level. The access_token that you got from impersonate button is not limited to account-console, it can be used by other clients(or applications) from same realm. Try accessing any other application/client from same realm. You should be able to directly access that application.
If you want to limit impersonation to specific client then you have to extend the Authenticator and implement logic yourself.
Related
I'm building an application where I want to be able to create and authenticate users using Discord and OAuth2. The reasons are:
The application can be considered a "companion" app to a Discord community I am running, and
I don't want the users or myself to have to deal with usernames and passwords
The application consists of a client desktop application and backend services. I have a fairly basic understanding on how I authorize the user with Discord:
Client application goes to backend endpoint /oauth/login and the user is redirected to the Discord app approval page
The user confirms and is redirected to the backend callback /oauth/callback with a code that can be used to fetch a pair of access and refresh tokens.
Frankly, from this point I am kind of stumped on how the rest of the authentication should work. I assume at least the following:
I need to create a user entry in my database with at least an UID (for simplicity the same as the one for the user in Discord), the access and refresh token pair. If user is already created, update the database with the new tokens.
Whenever the application needs user information from Discord it should use the access token. If it has expired, exchange the refresh token with Discord to get a new token pair.
But now what? This only authenticates the user against Discord. I want to leverage the fact that the user is authenticated with Discord to be authenticated to my application. Here are some general questions I have:
Do I make a new token for the user to use for subsequent requests to my backend endpoints? Or do I return the Discord access token to the desktop client?
What do I do when the token expires? Do I also need a "exchange" endpoint for the desktop client to refresh the token (possibly that just forwards to Discord to get a new token, depending on the answer to my previous question).
This all feels like it should be very basic, but I am out of my comfort zone here and need some help to be unblocked.
Thanks for reading!
Your own application should effectively have its own session system.
The easiest is likely to just use HttpOnly cookie-based sessions, which something like a Redis store (or Memory store if this is a toy project).
The session data on the server should contain information on which user is currently logged in. You should probably store the discord access and refresh token in a database.
The simplest way to deal with refreshing, is to simply call their refresh token endpoint as soon as you get a 401 response. If discord provides information on how long access tokens are valid, you could also preemptively refresh instead of only doing this when you get the 401. Your server does the refreshing, you don't need an endpoint for this.
Generally I can recommend that your server handles all interactions with the discord API, and never your client. (aside from the initial authorization step).
I have read the issues about impersonation, and from what i could find so far it can be achieved. I'm not sure tho if the following could be done using it.
A user doesn't have permission to do a certain operation, but it can be done if a supervisor grant him access.
The grant would be only for that operation/request.
is this something that can be done using impersonation, or there is a better approach for this?
Thanks in advance.
Quick brain dump of what you could do: You would have to implement this yourself in the user service in IdentityServer. One approach is to pass a custom param in the acr_values from the client with the ID of the user you want to impersonate (you will also have to pass prompt=login to force the request to go to the login workflow and thus the user service). In your user service implementation in PreAuthenticate you can check if the user is already authenticated, the custom acr_values is present, and the user is allowed to impersonate the user being requested. You'd then assign the AuthenticateResult on the context with the identity of the new user. This short circuits the login process and will return back to the authorization endpoint, and then back to your client app.
Use-case: Emails to be sent from a web-application upon an event, as someuser#somedomain.com via MS Exchange or Outlook.com, using the RESTful APIs exposed by Outlook.com. Only HTTP access allowed (=> no SMTP/IMAP).
All documentation seems to mention that the app has to forward users to MSOnline, sign-in and then use the authorization code sent back by MS online.
But, this won't work for a background task (=> no sign-in possible!) where a pre-built token(with some predefined scope) is necessary so that Outlook.com can be accessed via APIs to send mail as someuser#somedomain.com.
Any hints/pointers to how it could be done? Basically, automated authentication without explicitly signing in as 'someuser#somedomain.com' on the MS Online login page.
I did not find M$ documentation regarding Outlook REST APIs to be of any great help and found it to be pretty difficult to navigate/understand. :(
Thanks!
At some point you will have to have the user sign in to grant access to your app. So you would need to have some sort of user-facing web front end where they can do this. Once they have signed in and you've obtained an access token/refresh token, your background app should be able to use those tokens silently, without user interaction, at least until the user either revokes access or the refresh token expires.
Currently Azure (which provides the login/token functionality) does expire the refresh tokens after some time (90 days), at which point the user must sign in again to grant your app continued access.
I have an intranet application which I want to simply authenticate the users by their network ids. The users are considered trusted and I want to login the users without their interactions. In this case, which flow should I use?
I made it work with resource owner flow but I think this approach is not good enough. If I use Implicit Flow or Authorization Code Flow, can I achieve the goal that the users do not need involved in the login process? Which means the users do not need to consent to the authentication requests?
Thank you!
Consent is just a client setting (RequireConsent). But it sounds like you also want something like Windows integrated authentication.
This makes me wonder if you need an extra token service at all - since you already have one (called Windows domain controller).
Since LinkedIn discontinued their network updates RSS feeds, I haven't been able to find any "simple" mechanism to gain access to update feeds w/o going through the oauth process requiring the user to authenticate first. The few examples I've seen posted here all assume you've obtained the auth token first. Is that even possible?
In case anyone else inquires: https://developer.linkedin.com/support/faq
If your application requires you to make API calls in an automated way
- without user interaction, you need to bootstrap the first access token request by manually signing in, and then ensure that your
application refreshes the token automatically prior to expiry to avoid
the need for additional human authentication.