A requirement is set upon me to implement impersonation for developers, of course only for development environment. I was wondering if it is possible to request a token for any AAD user without knowing the password. The flow I would want is:
Developer goes to web application to select a user he wants to impersonate.
The web application checks if the developer is in the AAD.
The web application checks if the developer has the necessary rights to impersonate.
The web application returns a token valid for the user the developer selected.
The developer can use this token to authenticate against the API, and for all intents and purposes is the impersonated user.
Any good alternatives to this approach are also welcome.
No, you cannot impersonate a user like this.
You can acquire an access token if you know their password and they don't have MFA etc. with the Resource Owner Password Credentials grant flow.
But if you want to do it in a better way, you could have the users who you wish to impersonate login to your app.
Acquire an access token + refresh token for them.
Then store the refresh token securely.
Now you can use the refresh token at any time along with your app's client credentials to acquire a token for that user.
Refresh tokens can and do expire though, for example if the user's password is changed.
But this could allow you to implement what you want.
Related
While SSO is enabled for an organization, can an API account still use Legacy Authentication (username/password still being used for this account) on behalf of a user that has SSO enabled?
Our company wants to transition to using SSO for all user accounts (except possibly the API account). Currently, we use DocuSign's Legacy Authentication header (X-DocuSign-Authentication) to send envelopes on behalf of users and create sender views for them. Both of these actions involve using our API account's username and password for authentication on behalf of a user.
I've read this post that says:
If you're using Legacy Header authentication, your application won't
be able to authenticate as users who have SSO Login enforced. Until
you're able to implement one of the OAuth workflows, users who need to
use your API integration will need to have their Login Policy set to
allow them to login with a password.
Does this mean that any user account that will be sent on behalf of them will need to have SSO disabled while the Legacy Authentication header (and API account using username/password) is being used?
In addition, we are trying to avoid having every user separately authorize the application to act on their behalf. This post seems to mention there is a way to avoid that. Both the Authorization Code Grant and JWT Grant state that you must get your user's consent. We want to avoid this since we have 100's of members and staff additional staff added frequently.
Optimally, we would like to keep the API things as they are. If we can't or shouldn't, what changes do we have to make?
If SSO is enabled, a user can still authenticate via their DocuSign password, and thus Legacy Header auth will still work. If SSO Authentication is made mandatory via Login Policy settings, the user cannot authenticate with their DocuSign password, and Legacy Header auth will break.
If your authenticating "system sender" user has SSO optional, the SendOnBehalfOf header can be used to impersonate anyone on the account, regardless of the other user's Login Policy settings.
If you have a Claimed Domain, you can grant Admin consent so that all users with email addresses under that claimed domain (current and future) will not be required to grant individual consent for JWT impersonation. More information on that is available here: https://www.docusign.com/blog/developers/oauth-jwt-granting-consent
I'm developing a .NET application that can send emails on behalf of the user using the Graph API.
Users are prompted to authorize the application; The acquired access token is then used to call the Graph API. The refresh token is used to issue a new access token when the old one expires, as described here: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow
Couple of questions / observations:
Assume user John authorizes the app to send emails on his behalf. If an administrator removes the app from the azure portal, the access/refresh tokens issued when John authorized the app will still work.
if the access token is still active, it can be used to call the graph api;
if the access token is expired, the refresh token can still be used to request a new access token
Is this behavior intended?
After reading https://learn.microsoft.com/en-us/azure/active-directory/users-groups-roles/users-revoke-access and https://learn.microsoft.com/en-us/powershell/module/azuread/revoke-azureaduserallrefreshtoken?view=azureadps-2.0 it seems that simply removing the app from the user doesn't revoke the tokens.
Assume user John authorizes the app to send emails on his behalf. If John goes to https://myapplications.microsoft.com and removes the app he won't be able to use the refresh token to get a new access token, which is expected.
However, I've noticed that if John reauthorizes the application to perform actions on his behalf, the application won't show up on https://myapplications.microsoft.com anymore. This behavior seems a bit inconsistent. What's the proper way for a user to revoke access to an application?
If the user has granted access to the application, Azure AD will issue an access token and a refresh token for the resource.
The lifetime of the access token is usually about 1 hour. During its lifetime, even if the application is deleted, it is still available, but you will not be able to use the refresh token to obtain the access token again.
If you need to revoke authorization during the lifetime of the access token, please see: here and here.
I am trying to build an application that will be authenticating documents using DocuSign.
The person who is signing the document is going to be initiating the process and will not have any login credentials for DocuSign.
However, when I test using the JWT authentication method it always brings me to a page asking for a Username/Password. My end user is not going to have this information.
All of the Example applications do not address Authentication, they just have you copy and past the Access_Token out of their tool on the website.
How can I have an Embedded Signing application that does not require the End User to login with DocuSign?
JWT Authentication requires the user grant consent once. Once that consent is granted, the application can freely generate access tokens for that user at any time (unless consent is later revoked).
For an example of C# / .net core that uses JWT authentication, please see GitHub: https://github.com/docusign/eg-01-csharp-jwt-core
JWT allows you to specify a userId.
If you are an admin of the DocuSign account and you enabled the integration and logged in yourself at least once, then you can later make APIs call impersonating other users, if you provide their userId in the request so they don't need to login themselves.
Hope this helps
We currently have an Identity server 4 application. Using entity framework core and asp .net identity.
We have a group of supporters who need to be able to access our users accounts in order to help them with issues over the phone. Our users are not able to figure out how to use team viewer. As most of them are mobile and will only have a cellphone at the time.
I know all the security ramifications of allowing other people to sign into your account however there is really no way around this. Our customers have accepted that our supporters can connect to their account when they request it. We trust that our supporters only do this when its requested.
Current solution and its issues
The current hack creates an api endpoint which only our supporters can use as it has been locked down so that only those with supporter permission can use it. They send the users email and we hack create them an access token which is then used by the application (Web version) to act like its the user who is having issues.
This solution was created by my predecessor basically by taking the supporters access token and replacing all of the claims with this supporters id to the users id and returning it to the application. I hate this solution on a number of levels and its very unstable every time i look at this method it breaks. currently its not working because audience clams are incorrect for some reason.
What i want to do
I would really like to do this in a less hack way. So is there a way to sign in a user to the application without it actually being them thats doing the signing in and return an access token?
I have tried doing
await _signInManager.SignInAsync(user, false, null);
But i cant seam to figure out how to get that to return an access token.
What i would really like to do is have the ability for supporters to login to any ones account but do it securely somehow.
The problem with the user account is that it's not bound to one application. So by allowing others to login using the account, you give them also access to other applications. As a workaround you could use 'public' accounts, like engineer_01, engineer_02, etc.
But, this may not be necessary at all. What you really want IMO is to impersonate the user, instead of 'hacking' the account.
One way to do this, is to extend IdentityServer with a custom grant type using extension grants.
How this could work:
A signed-in user, who is allowed to impersonate users for the particular client/resource, requests an access token at the new impersonation endpoint.
The user sends the sub from the user to impersonate to the endpoint, where the user and (combination of ) sub are verified.
When access is granted a new (short-lived) access token is returned which can be used to impersonate the user, without having to know the credentials of the user.
The access token should contain information of the endpoint so it can be determined whether the user is impersonated.
We implemented an impersonation feature that is integrated into the browser-based sign in flow. If a user with permission chooses to sign in as another user then we add additional claims to their IDS4 authentication cookie which then supports issuing extra claims in the resulting token that reflect that it's an impersonation session and who the original actor is.
Navigate to client application
Sign in using whatever credentials
Check if any impersonation permissions exist (how these are defined is entirely up to you)
Prompt for impersonation account selection (or just continue as self)
Sign in as the selected account (with record of original actor)
Redirect to authorize endpoint
Issue tokens and redirect back to client application
I want my web server code (invoked from ASP.NET MVC3 site's controller) to be able to save files to Dropbox account.
I have examined two out of three .Net/Dropbox libraries and all of them require a user to "authenticate" via web-redirect to Dropbox to get a token.
Examined libs are Spring.Social.Dropbox and DropNet.
Can this authentication and upload be done via purely .net code without messing with the user's browser? Can the acquired token be saved for later use? This is theoretical question, not about particular implementation.
This is a bit of a complicated subject. As far as I know Dropbox uses OAuth, which is an authentication and authorization protocol.
General process is this:
You create authorization request token
User gets redirected, authenticates and grants permissions to your app.
You trade the request token for an access token
You must save the access token because it is used to perform actions on the users behalf
Access tokens don't usually expire and only stop working if a user revokes your application permissions.
This means the user will have to authenticate and authorize your application at least once so you can get the access token and access token secret.
After that, you are pretty much free to perform actions on the users' behalf based on the permissions granted. You must specify the access token attained by the above-mentioned process in order to perform actions.
In short, get an access token, save it, use it for requests.
Does this clarify it a bit for you?