The bounty expires in 4 days. Answers to this question are eligible for a +200 reputation bounty.
Pete is looking for an answer from a reputable source.
I am aware the user impersonation question has already been asked several times.
Unfortunately, none of the questions I read so far provided a reproducible guideline or overall concept how to do this in a secure way. Since every action needs to be logged, I can't use a hack to do this.
For that reason, I would like to kindly ask the community once again for advice and sanity check of my own ideas. Also, new approach suggestions are warmly welcome.
The questions I read so far include:
IdentityServer4 - How to Implement Impersonation
Allow supporter to sign in as another user
Impersonate with IdentityServer, with having an actor claim for the impersonated user
Identityserver3 - User Impersonation
Introduction
Basically, I have an ASP.NET Core Razor Pages app and an ASP.NET Core Web API, both protected by Duende IdentityServer.
Support Engineers need to be able to impersonate customers for service reasons ONLY after the customer consented to impersonation.
Basic work flow:
in the Razor Pages app, the customer activates "Grant Impersonation Permission" under his/her personal settings
impersonation permissions are valid for a maximum of 7 days
customers can revoke impersonation permissions at any time
Support Engineers are then able to log in as any customer that granted impersonation permission at the back office (without the customer being present, no remote-desktop style)
Approach 1:
When the customer grants permission, use the Token Exchange mechanism to exchange for a new access token with a life time of 7 days.
Store this token in a database in IdentityServer and allow only Support Engineers to get a customer's access token via a Controller using the customer's ID, name etc.
While this would work, I'm not comfortable with the idea of storing long-lived access tokens.
Approach 2:
When a Support Engineer logs in, based on his identity, show a custom consent screen where customers can be selected for impersonation and then log in as the selected customer.
The Support Engineer would then get the access token as well as the ID token.
The biggest problem is:
Are there any extension points/mechanisms in IdentityServer to be hooked-in to control the sign-in process to kind of turn the sign-in process to log in the customer instead of the Support Engineer?
Is even possible to do this in IdentityServer?
Approach 3:
In Allow supporter to sign in as another user, user mackie pointed out a high-level view of a impersonation feature.
Here are the steps:
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
How are steps 4. to 6. done in practice? Any suggestions on that?
I have a question about the problem in your Approach 2. The essence of user impersonation is actually to use "pseudo-token" to impersonate a user to verify some operations or permissions. Or maybe you just want to log all actions performed by the impersonated user?
I think maybe you can intercept on login like in this link. But I think it may be better to add some specific identification to it when the interception is successful, instead of directly using the user's information to log in. I think logging in the customer instead of the Support Engineer might not be a user impersonation anymore (just a personal opinion).
In addition, acr_values is mentioned in the link you provided. From your description, acr_values seems to have some fit:
acr_values allows passing in additional authentication related
information - identityserver special cases the following proprietary
acr_values:
idp:name_of_idp bypasses the login/home realm screen and forwards the
user directly to the selected identity provider (if allowed per client
configuration)
tenant:name_of_tenant can be used to pass a tenant name to the login
UI
For the usage of acr_values, you can refer to this link.
Other link:Impersonation workflow.
This is just my understanding and a suggestion, if I have any understanding wrong, please correct it.
Related
I am developing an app in Aurelia which has a .net core backend. I have already implemented user Authentication with Auth0 in the frontend.
The problem comes as I am not sure if its good practice to implement a way so that users from auth0 database are linked with my user model in .net core and in my database. When a user registers/logs in I can get the corresponding user model from my database.
Basically I would be using the auth0 database jsut for logging in and my database for the user details.
If it is good practice how should I go around and doing it? Is a 'post user registration' action good? Any help appreciated :)
It is a common approach to let the Authentication Service keep only the minimum amount of data it needs to authenticate a user, and then have additional, business-related data in a separate service. These should be linked upon user registration.
Note, that if that data in the separate service would be used to perform authorization decisions, then the Authorization Server (Auth0 in your case) should be able to read that data when issuing tokens, and relevant information about the user should end up in the signed token in form of claims. This gives you the assurance that this data is not tampered with.
Have a look at this article that my colleague wrote: https://curity.io/resources/learn/integrate-identity-business-data/ as it describes in more detail what you need.
I've done a fair amount of research on the many different ways to authenticate and authorize users who use my frontend application to access my REST API. I've built a system that uses OAuth2 and JWT and need a sanity check since I'm working on this alone.
For a bit of background, my frontend is built using Vue.js and my API is built using Django with Django Rest Framework. My team is already planning on concurrently developing the mobile and desktop versions of this app which both would require authentication and authorization as well.
To keep things brief, I'll omit the alternative solutions I have and just talk about the most controversial one.
Right now, OAuth2 (my authorization server) grants users a JWT token using ROPC when they provide their email and password to my frontend client. I should note that my API (my resource server) and authorization server live on the same machine.
My application allows users to essentially signup using different plans (for example a free plan and a paid plan). When a user signs up for a free plan, I need the frontend application to not only disable certain features and elements in the UI, but also I need the authorization server and or resource server to limit what that user is allowed to query based on their plan.
The idea is when a user signs up or logs in, my authorization server will get the associated user record from the database and create a valid JWT with a claim attached that states the user's plan and maybe some other non-personal information. Then once signed it sends it off to the user where the frontend can enable/disable parts of the UI... etc. Hence, if a user logs in on mobile, we can customize the UI based on the same claim sent by the JWT.
My issue is that I don't know if this is a good way to go about it. It seems that everyone I've asked in my circle is split on using JWT or not. Those apposed mostly raise security issues, but, when from what I understand, many of the JWT security pitfalls are well documented and can be avoided just using some commonsense as with any other session/token-based authentication. I'm starting to get analysis paralysis. Please help.
CLASSIFICATION
I would say this is really an API Authorization question, as opposed to an OAuth question:
The role of the Authorization Server and tokens is really just to prove the user's identity
Product specific logic comes after the user logs in and is generally best handled in your app
MY PREFERENCES
Here is how I would handle it:
Save the plan type to your product data when the user signs up
After login, look up the user from the access token
Then look up the user's plan type from your product data
Produce a Claims / Principal object in your API containing both
Enforce business rules based on the plan type claim
I would aim for a Claims object something like this:
class ApiClaims {
// The user id in the access token
userId: string;
// The email
email: string;
// The plan type
planType: string;
// Other claims from the token
// Other claims from product data, eg user roles
}
RESOURCES
If interested in this approach, these blog posts of mine may be of interest:
User Data Management
API Authorization
JWT?
You need some kind of API credential that is sent in HTTPS messages and is web and mobile friendly, so I would use JWTs. You could follow the same pattern with any API credential though.
It depends on what you are trying to protect of course, but JWT bearer tokens are an industry standard. Since you control both the client and the authorization server, you can implement it however you like.
I would look into changing Resource Owner Password Credentials flow to authorization code flow. It will enable you to use social authentication providers like Google or Facebook to sign in users (while still maintaining plan info in your own service). Chances are that people trust those companies more to keep their credentials safe than your company, and it allows you to benefit from any authentication features (MFA) those companies implement.
Also, if you want the clients to read the contents of the token, you should use OpenID Connect id_tokens, as those are guarenteed to be in JWT format.
I am quite confused about one requirement that i've received and how to correctly fullfill it...i hope that someone can help me figure out something.
I have to add Authentication/Authorization to an existing MVC 5 intranet application that will be used only by the customer's intranet users. This web app hosts an AngularJs application that uses a set of WebApi (hosted inside the same intranet and used only for intranet purposes).
The application will be used by different kind of users that can have different grants (e.g: can create things, can modify things, can delete things) and those grants must be declined for different Countries (consider the Country as, conceptually, a subsite). So a User can be the "administrator" (considering the administrator as a User with all grants) for the France, but be a simple user for Germany and not authorized at all for the other countries.
The requirement is to use AD for Authentication, but not for Authorization purposes.
I am not an expert of security and i did some research to try to understand the possible solutions. The most important thing i have understood is to separate the Authentication from the Authorization.
From a simple Authentication point of view, it's easy to use AD (or Windows Auth).
What i am missing is how to perform the Authorization part.
I have seen a lot of tutorials for ASP.Net Identity with Individual Accounts, all it's clear and easy, as it's using the UserManager to perform lookups on the db for the users to verify the authentication, and from there take the roles data(saving those info in a cookie).
I need to understand what should be the correct way to handle my scenario.
The user should log in using it's domain credentials, then i should receive a response from AD, if ok i should get the corresponding user from my db and retrieve its role data...correct?
If so, how could i perform those tasks.
Is it a wrong way of solving the problem?
And if so, how can i do that?
What is the best way to "pass" the auth/entication/orization token to the WebApi in order to secure them as well?
One last question...could it be possible to fulfill the requirements by using only AD (not relying on the db for grants)?
Sorry for the (most probably) dull questions but i'm feeling like i am missing some VERY key points.
Suppose I have a working REST API for my product.
I want to give access only to developers who sign up to this product. Also, there will be several plans available so certain parts of the API are not accessible on the free plan.
From the grant types I've seen only the client-credentials one seems to be the closest solution. However that won't authenticate the developer account stored in my product db, it will only get an access token for that client. The user won't actually be 'logged in' per se. Add to that the fact that a single client can be reused by everyone, according to implementations I've seen.
The only way I see is creating a custom grant type, by adding an extra api_key to the client credentials type, which pertains to the developer account.
Is there a way to do this with the existing grant types? Introducing custom types will not work with many oAuth2 libraries out there out of the box and I don't want to give the developers the hassle of modifying them.
I don't think you have to invent a custom grant type.
A single client can be reused by everyone only if everyone knows the client secret.
So, it seems that what you have to do is (1) to authenticate a developer when you issue a pair of client ID and client secret to the developer and (2) to motivate the developer not to reveal the client secret to others.
OK, so I'm quite new to the whole world of claims aware applications. I was able to get up and running very quickly using Azure ACS but it's been a bit of a different story when trying to use ADFS 2.0 as the identity provider (I want to actually use it as a federated provider, but for the time being I'm just trying to get a sample running using it as an identity provider).
I've been looking at the guides here and have tried to follow the AD FS 2.0 Federation with a WIF Application Step-by-Step Guide guide listed there. It takes you through setting up ADFS 2.0 along with a little claims aware sample application that you can use just to view the claims that are getting sent through.
So I can get that up and running, passing through the claims defined in the guide (just the windows account name). The problem is when I try to add any more. I can go to the relying party application in the ADFS GUI and add an Issuance Transform Rule, using the Pass Through or Filter Incoming Claim rule template. However, when I run my application, unless the added claim type is Name, it won't pass the claim through to my application.
One of the ones that I wanted passed through was the email address for the user who logged in to the application. So I added a rule to pass through the email address, then updated the web.config of the sample application to uncomment this line under the claimTypeRequired section:
<claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" optional="false" />
Note that I'm setting it as non-optional. I also updated the federation metadata of the application to add in the following:
<auth:ClaimType Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" Optional="false" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" />
I then went into the ADFS GUI, went to the Relying Party Trusts and selected Update from Federation Metadata on my sample application. So it now lists the email as one of the accepted claims.
I then went into the Claims Provider Trusts and added the email claim rule into the Acceptance Transform Rules for the Active Directory provider trust (the only one listed).
When I run the app however, it's not passing through the email claim (or any others that I try). Can somebody tell me what I'm missing here?
I should also note, I ran a test to change my application to only accept the email claim rule, and not only did it not pass through the email, but it's still passing through the Windows Account Name and the Name claims, despite the fact that I don't even list them as accepted claims for my application.
If anybody could point out where I'm going drastically wrong here, it would be seriously appreciated.
After enabling logging as per the blog post before, here are the relevant entries from the log:
Event ID 1000, "Input claims of calling principal included in details":
So you can see, the information that I'm requesting is quite clearly missing. I have the logging output set to verbose but there's really nothing of any other interest. You'll see trace records for the NETWORK SERVICE user (with the same set of claims), but nothing striking. All the log entries are informational, there aren't any errors.
If you using ADFS as Identity Provider and want it to issue an email claim, then you have to use Send LDAP Attributes as Claims or a Custom Claim Rule which access AD as the attribute store and issues an email claim. Pass through is used on the incoming claims, assuming the user is already authenticated somewhere. In case of Windows Authentication Windows account name is issued from the Kerberos token and that's why you have to pass it through, but others you have to issue.
Does Active Directory issue E-Mail Address claims? I'm not sure how to check this, but if it doesn't, it's irrelevant that you're passing them through. In this case, you'll want to try a "Send LDAP Attributes as Claims" rule; based on what I see in my ADFS instance, try mapping the "E-Mail-Addresses" attribute to an "E-Mail Address" claim.
I had to do something similar to get UPN claims to come over, in circumstances similar to yours. I'm not sure whether it will matter that the LDAP attribute is potentially plural.