Developer forum

Hi Adrian,

Good question — and you’re right that this behaves differently compared to Dynamicweb 9.

In Dynamicweb 10 there is no longer a concept of “use impersonator for permissions” in the same way. When you impersonate a user, the security context switches to that user, and permissions are evaluated solely based on the impersonated identity. You can’t mix credentials or evaluate permissions from both the impersonator and the target user at the same time.

That said, this is usually a sign that the problem is being approached from the mechanism rather than the goal.
Before jumping to a replacement feature, it would really help to understand what you are trying to achieve from a business or UX point of view.

For example, a common scenario we’ve seen is something like:

“A support user needs to see and work with a specific customer’s orders, but still keep access to the support user’s own pages, tools, or backend functionality.”

In that case, impersonation may not be the right tool at all. Instead of switching identity, you could:

• Keep the support user logged in as themselves

• Filter order lists (or other data) by customer, company, or relation

• Control access via roles or permissions on what they can see or act on, rather than who they are logged in as

Impersonation is best used when you genuinely need to experience the system exactly as the target user would — same permissions, same restrictions, same visibility. If the goal is more about accessing or managing data on behalf of a customer, there are usually cleaner and safer patterns than impersonation.

If you can share a bit more about the concrete use case — what the impersonator should be able to see/do, and what the target customer represents — we can help point you toward the most appropriate solution in DW10.

One additional angle that may be useful here is the API context, which works a bit differently than the classic page-based login model.

When working with the /dwapi endpoints, “being logged in” is essentially just a matter of holding a JWT. There is no session in the traditional sense. The application calling the API decides which JWT it presents on each request, and that JWT fully defines the user identity and permissions for that call.

This means you can:

• Start an impersonation via the API

• Obtain a JWT for the impersonated user

• Continue to stay authenticated as the impersonator in your own application

• Use the impersonated user’s JWT only when calling /dwapi endpoints that should act in the context of that user

From an architectural point of view, the app can technically hold multiple JWTs at the same time. In other words, it can be “logged in” as multiple users concurrently, simply by storing and choosing which token to send with each request.

Two common patterns here are:

• Store JWTs for different users and switch between them per request

• Or generate a JWT on demand for a given user before querying data on their behalf

In this model, permissions are still always evaluated per user — but the application controls which user context is used, instead of relying on a single global login state. This often removes the need to combine impersonator and target-user permissions in one security context.

So again, the key question becomes:
Is the goal to experience the system exactly as the customer, or to access customer data while remaining a support/admin user?
In API-driven scenarios, the latter is usually better handled with filtered queries and scoped JWT usage rather than classic impersonation.

Hi Nicolai,
Thank you for the context.
I will elaborate on my scenario.

We have an external authentication set to EntraID.
All users (customer users and support users) are using this authentication.
Customer users have a property for CustomerNumber. Based on that property, at the time of login, we set that user to impersonate a Customer user.
However, for support users (with CustomerNumber empty, I would like to allow them to select a Customer for impersonation. I have already created 2 separate user groups for the login users, but they will all end up impersonating users from the same group (Customers).
The permissions should be set on the impersonation row and also on the Customer center page (My Customers).

Even if I were able to handle the impersonation bar issue with code, the permissions on the Page would require more complex coding.
Does it make sense?

Thank you,
Adrian

No, it does not makes sense :-).

Could you help me understand what you are trying to achieve - from a use case perspective? Why do you even need to impersonate here? I do not get that - it looks like you need to think about this differently.

It really sounds like you should not be impersonating at all. Impersonating means - I take over all of another user.

Either way - a user impersonating another user will have the permissions of the user being impersonated.

Hi Nicolai,

I have thought about this before deciding on using Impersonation. In my use case, the support users need to experience the same behavior as the Customer. Assortments, custom prices, addresses, orders, favorites. And the Impersonation offers this out of the box.
The only difference between a customer user and a support user is the ability of support users to choose the customer they want to impersonate.

I admit that I have used the impersonator permissions only twice before (this would have been the third attempt). So far, in DW10, I have not found a replacement for it other than custom coding, which is a pity. I understand that you surely had solid arguments for removing it. I have to live with it and find a workaround.

Thank you,

Adrian