Return to Answer

The warning message is quite explicit, isn't it? :-)

Account '[email protected]' is impersonated by name. This may be an Access Management account and group mappings will not be taken into account. Avoid impersonating such accounts by name.

In general, if a user authenticates through Access Management, additional user claims are provided to CM. At least, user Roles as specified in Access Management and possibly also forwarded claims from the IDP. These additional claims can/will be used in CM to determine CM Group Memberships. For example, if a user is assigned the CM Administrator Role in Access Management, the user will implicitly become a member of the CM System Administrators Group (through a predefined Group Mapping on the role claim provided by Access Management).

However, if you create your own CM Session (in TOM.NET or Core Service WCF) and impersonate using an API which only specifies user name, these additional claims are not provided to CM. As a result, the CM Group Mappings are not applied. This, in turn, can result in the impersonated user having fewer Privileges/Rights/Permissions that what the user has when signing in through Access Management.

The mentioned warning occurs if such impersonation API is being used (the Stack Trace reveals it's the Core Service Impersonate method) and the impersonated user is neither a Windows nor LDAP user. The warning message explains what the consequences are.

Unfortunately, the Stack Trace is "server-side", so you don't see the context of the Core Service client which called this method; you will have to figure this out yourself.

So, in general, use of impersonation APIs which only take a user name should be avoided if the impersonated user can be an Access Management user (or a user for the earlier SAML 2.0 integration, for that matter). The Core Service also provides an ImpersonateWithClaims method, which does allow you to pass additional claims.

If the Core Service client is in a Web Application which supports Access Management authentication (for now, that means in the CME Web App), the additional claims can be obtained using .NET's ClaimsPrincipal. For example: HttpContext.Current.User as ClaimsPrincipal

The warning message is quite explicit, isn't it? :-)

Account '[email protected]' is impersonated by name. This may be an Access Management account and group mappings will not be taken into account. Avoid impersonating such accounts by name.

In general, if a user authenticates through Access Management, additional user claims are provided to CM. At least, user Roles as specified in Access Management and possibly also forwarded claims from the IDP. These additional claims can/will be used in CM to determine CM Group Memberships. For example, if a user is assigned the CM Administrator Role in Access Management, the user will implicitly become a member of the CM System Administrators Group (through a predefined Group Mapping on the role claim provided by Access Management).

However, if you create your own CM Session (in TOM.NET or Core Service WCF) and impersonate using an API which only specifies user name, these additional claims are not provided to CM. As a result, the CM Group Mappings are not applied. This, in turn, can result in the impersonated user having fewer Privileges/Rights/Permissions that what the user has when signing in through Access Management.

The mentioned warning occurs if such impersonation API is being used (the Stack Trace reveals it's the Core Service Impersonate method) and the impersonated user is neither a Windows nor LDAP user. The warning message explains what the consequences are.

Unfortunately, the Stack Trace is "server-side", so you don't see the context of the Core Service client which called this method; you will have to figure this out yourself.

So, in general, use of impersonation APIs which only take a user name should be avoided if the impersonated user can be an Access Management user (or a user for the earlier SAML 2.0 integration, for that matter). The Core Service also provides an ImpersonateWithClaims method, which does allow you to pass additional claims.

If the Core Service client is in a Web Application which supports Access Management authentication (for now, that means in the CME Web App), the additional claims can be obtained using .NET's ClaimsPrincipal. For example: HttpContext.Current.User as ClaimsPrincipal

The warning message is quite explicit, isn't it? :-)

Account '[email protected]' is impersonated by name. This may be an Access Management account and group mappings will not be taken into account. Avoid impersonating such accounts by name.

In general, if a user authenticates through Access Management, additional user claims are provided to CM. At least, user Roles as specified in Access Management and possibly also forwarded claims from the IDP. These additional claims can/will be used in CM to determine CM Group Memberships. For example, if a user is assigned the CM Administrator Role in Access Management, the user will implicitly become a member of the CM System Administrators Group (through a predefined Group Mapping on the role claim provided by Access Management).

However, if you create your own CM Session (in TOM.NET or Core Service WCF) and impersonate using an API which only specifies user name, these additional claims are not provided to CM. As a result, the CM Group Mappings are not applied. This, in turn, can result in the impersonated user having fewer Privileges/Rights/Permissions that what the user has when signing in through Access Management.

The mentioned warning occurs if such impersonation API is being used (the Stack Trace reveals it's the Core Service Impersonate method) and the impersonated user is neither a Windows nor LDAP user. The warning message explains what the consequences are.

Unfortunately, the Stack Trace is "server-side", so you don't see the context of the Core Service client which called this method; you will have to figure this out yourself.

So, in general, use of impersonation APIs which only take a user name should be avoided if the impersonated user can be an Access Management user (or a user for the earlier SAML 2.0 integration, for that matter). The Core Service also provides an ImpersonateWithClaims method, which does allow you to pass additional claims. If the Core Service client is in a Web Application which supports Access Management authentication (for now, that means in the CME Web App), the additional claims can be obtained using .NET's IClaimsIdentity. For example: HttpContext.User.Identity as IClaimsIdentity

The warning message is quite explicit, isn't it? :-)

Account '[email protected]' is impersonated by name. This may be an Access Management account and group mappings will not be taken into account. Avoid impersonating such accounts by name.

In general, if a user authenticates through Access Management, additional user claims are provided to CM. At least, user Roles as specified in Access Management and possibly also forwarded claims from the IDP. These additional claims can/will be used in CM to determine CM Group Memberships. For example, if a user is assigned the CM Administrator Role in Access Management, the user will implicitly become a member of the CM System Administrators Group (through a predefined Group Mapping on the role claim provided by Access Management).

However, if you create your own CM Session (in TOM.NET or Core Service WCF) and impersonate using an API which only specifies user name, these additional claims are not provided to CM. As a result, the CM Group Mappings are not applied. This, in turn, can result in the impersonated user having fewer Privileges/Rights/Permissions that what the user has when signing in through Access Management.

The mentioned warning occurs if such impersonation API is being used (the Stack Trace reveals it's the Core Service Impersonate method) and the impersonated user is neither a Windows nor LDAP user. The warning message explains what the consequences are.

Unfortunately, the Stack Trace is "server-side", so you don't see the context of the Core Service client which called this method; you will have to figure this out yourself.

So, in general, use of impersonation APIs which only take a user name should be avoided if the impersonated user can be an Access Management user (or a user for the earlier SAML 2.0 integration, for that matter). The Core Service also provides an ImpersonateWithClaims method, which does allow you to pass additional claims.

If the Core Service client is in a Web Application which supports Access Management authentication (for now, that means in the CME Web App), the additional claims can be obtained using .NET's ClaimsPrincipal. For example: HttpContext.Current.User as ClaimsPrincipal

The warning message is quite explicit, isn't it? :-)

Account '[email protected]' is impersonated by name. This may be an Access Management account and group mappings will not be taken into account. Avoid impersonating such accounts by name.

In general, if a user authenticates through Access Management, additional user claims are provided to CM. At least, user Roles as specified in Access Management and possibly also forwarded claims from the IDP. These additional claims can/will be used in CM to determine CM Group Memberships. For example, if a user is assigned the CM Administrator Role in Access Management, the user will implicitly become a member of the CM System Administrators Group (through a predefined Group Mapping on the role claim provided by Access Management).

However, if you create your own CM Session (in TOM.NET or Core Service WCF) and impersonate using an API which only specifies user name, these additional claims are not provided to CM. As a result, the CM Group Mappings are not applied. This, in turn, can result in the impersonated user having fewer Privileges/Rights/Permissions that what the user has when signing in through Access Management.

The mentioned warning occurs if such impersonation API is being used (the Stack Trace reveals it's the Core Service Impersonate method) and the impersonated user is neither a Windows nor LDAP user. The warning message explains what the consequences are.

Unfortunately, the Stack Trace is "server-side", so you don't see the context of the Core Service client which called this method; you will have to figure this out yourself.

So, in general, use of impersonation APIs which only take a user name should be avoided if the impersonated user can be an Access Management user (or a user for the earlier SAML 2.0 integration, for that matter). The Core Service also provides an ImpersonateWithClaims method, which does allow you to pass additional claims. These additional claims, in turn, can be obtained using .NET's IClaimsIdentity. For example: HttpContext.User.Identity as IClaimsIdentity

The warning message is quite explicit, isn't it? :-)

Account '[email protected]' is impersonated by name. This may be an Access Management account and group mappings will not be taken into account. Avoid impersonating such accounts by name.

In general, if a user authenticates through Access Management, additional user claims are provided to CM. At least, user Roles as specified in Access Management and possibly also forwarded claims from the IDP. These additional claims can/will be used in CM to determine CM Group Memberships. For example, if a user is assigned the CM Administrator Role in Access Management, the user will implicitly become a member of the CM System Administrators Group (through a predefined Group Mapping on the role claim provided by Access Management).

However, if you create your own CM Session (in TOM.NET or Core Service WCF) and impersonate using an API which only specifies user name, these additional claims are not provided to CM. As a result, the CM Group Mappings are not applied. This, in turn, can result in the impersonated user having fewer Privileges/Rights/Permissions that what the user has when signing in through Access Management.

The mentioned warning occurs if such impersonation API is being used (the Stack Trace reveals it's the Core Service Impersonate method) and the impersonated user is neither a Windows nor LDAP user. The warning message explains what the consequences are.

Unfortunately, the Stack Trace is "server-side", so you don't see the context of the Core Service client which called this method; you will have to figure this out yourself.

So, in general, use of impersonation APIs which only take a user name should be avoided if the impersonated user can be an Access Management user (or a user for the earlier SAML 2.0 integration, for that matter). The Core Service also provides an ImpersonateWithClaims method, which does allow you to pass additional claims. If the Core Service client is in a Web Application which supports Access Management authentication (for now, that means in the CME Web App), the additional claims can be obtained using .NET's IClaimsIdentity. For example: HttpContext.User.Identity as IClaimsIdentity