We see that during evaluation of the MenuProvider, the ProfilesMenuProvider within EPiServer.Insight.UI verifies: 1. if (PrincipalInfo.HasAdminAccess()), it adds the Menu
2. if above is not true, it goes to ProfilesRolesRepository.GetRolesForUser to verify the users access.
Within ProfilesRolesRepository.GetRolesForUser, you have a reference to Roles.GetRolesForUser(userName), which is the old ASP.NET Role Provider. It is _not_ active if we are using ASP.NET Identity (like Quicksilver) or any type of SSO integration. It means that if a user is not "HasAdminAccess", the Episerver Shell breaks as long as we do not have ASP.NET Role Providers activated.
Observed in EPiServer.Insight.UI.1.6.0
We do not see this tracked as a defect anywhere. It would not be expected due to the support of federated identity.
Hi there.
We see that during evaluation of the MenuProvider, the ProfilesMenuProvider within EPiServer.Insight.UI verifies:
1. if (PrincipalInfo.HasAdminAccess()), it adds the Menu
2. if above is not true, it goes to ProfilesRolesRepository.GetRolesForUser to verify the users access.
Within ProfilesRolesRepository.GetRolesForUser, you have a reference to Roles.GetRolesForUser(userName), which is the old ASP.NET Role Provider. It is _not_ active if we are using ASP.NET Identity (like Quicksilver) or any type of SSO integration. It means that if a user is not "HasAdminAccess", the Episerver Shell breaks as long as we do not have ASP.NET Role Providers activated.
Observed in EPiServer.Insight.UI.1.6.0
We do not see this tracked as a defect anywhere. It would not be expected due to the support of federated identity.
Casper