`Administrator` doesn't have access to everything by default anymore #17108

hieucd04 · 2024-12-02T22:07:08Z

Describe the bug

I create a site from scratch (blank DB) via a setup recipes
I use OpenId module of OrchardCore
The newly created site only has 1 user and that users has Administrator role
I tried to authenticate via Bearer token using that user
I got 403

info: OpenIddict.Validation.OpenIddictValidationDispatcher[0]
      The response was successfully returned as a challenge response: {
        "error": "insufficient_access",
        "error_description": "The user represented by the token is not allowed to perform the requested action.",
        "error_uri": "https://documentation.openiddict.com/errors/ID2095"
      }.

info: Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[2]
      Authorization failed. These requirements were not met:
      ClaimsAuthorizationRequirement:Claim.Type=Permission and Claim.Value is one of the following values: (API.Fusion.Policy.UnrestrictedAccess)

I did read this: Fix SiteOwner claim for OpenId #17087
But it doesn't answer my question, which is: How do I make the default user with Administrator role have access to everything again?

Orchard Core version

2.1.2

Expected behavior

Administrator should have access to everything by default without me having to do anything.

The text was updated successfully, but these errors were encountered:

MikeAlhayek · 2024-12-02T22:24:11Z

@hieucd04 by default user that belong to "Administrator" role will automatically have full permission without doing anything. What you are reporting was an issue in < 2.1.1. But was fixed in 2.1.2 as per the PR you referenced. Are you sure you are using 2.1.2?

ghost · 2024-12-04T19:04:57Z

Good Afternoon Mike,

We just upgraded yesterday from OrchardCore 1.8.3 to 2.1.2. The upgrade included updating the OrchardCore Nuget packages to the latest version and making some code changes to update json from newtownsoft to system.text. I completed the upgrade in a local separate branch which is not deployed to the dev server. However, we are now unable to access the admin functionality on the dev server as well as other local branches which are still on 1.8.3. All users however can access the admin functionality from the 2.1.2 branch I did the upgrade in. Seems the issue is branch specific as opposed to user specific. Please see my screen shots. My question is, would upgrading from OrchardCore 1.8.3 to 2.1.2 on a local branch cause any automatic update to the database/orchardcore system that would affect the admin permissions for all branches/users?

Regards,

Anthony Giordano

1.8.3 No Admin Access

2.1.2 Admin Access

MikeAlhayek · 2024-12-04T19:31:19Z

@anthnyg12b Ion the screenshot, what permission check are you checking for to show the "Administation" link?

The screenshots you shared seems to be from two separate users A and M.

Also, if you are using Liquid to check for permission, be sure to use has_permission not has_claim as explained here.

ghost · 2024-12-05T17:53:32Z

Good Afternoon Mike,

When further debugging we noticed that the admin panel on 2.1.2 version has the 'system' text next to it

and limited upons upon edit
)

However the earlier version(1.8.3) doesn't have the 'system ' text next to it

and also offers more options upon edit.

We suspect this is the cause of our issues. Do you know of a way in 2.1.2 to get the Admin options we see in 1.8.3(No system text and permissions options)

MikeAlhayek · 2024-12-05T20:24:12Z

@anthnyg12b this is not an issue but a new feature added in 2.1. It's importants to read all release notes before upgrading to a new version just so you aware of the new changes. Please read this https://docs.orchardcore.net/en/latest/releases/2.1.0/#site-owner-permission-deprecated-administrator-role-retained-as-a-system-role

The Administrator role is now is reserved for system. Meaning you can't modify it. By design it grants any user with that role access to everything.

ghost · 2024-12-05T21:10:30Z

Hi Mike,

Thanks for your reply, our issue is specifically related to the users who have admin privilege no longer being able to access to admin page in our older version (1.8.3) which resides in a separate branch from our upgrade to 2.1.2.

For background we are using IGlobalMethodProvider for custom script methods and the "Permission.AccessAdminPanel" is failing for already admin users when we call "AuthorizationService.AuthorizeAsync( user, AdminPermissions.AccessAdminPanel ), b => allow = b );" causing allow to be false.

We started seeing this issue shortly after our upgrade to from 1.8.3 to 2.1.2 and were wondering if Orchard overrides/Changes any roles in the DB for users after an upgrade? because on the older version users are not getting Admin Access and while it's working as expected on the new version.

MikeAlhayek · 2024-12-05T21:46:33Z

@anthnyg12b I am not sure what your custom script does. Are you able to share you full IGlobalMethodProvider implementation?

If the implementation use IAuthorizationService and passes the user as your screenshot seems to imply, it should work. if user is Admin then it will always return true. If you are able, check the claims for the given user to make sure it has a role claim with "Administrator" as the value. like highlighted here in orange:

ghost · 2024-12-05T22:30:11Z

Hi Mike,

The user does have the Administrator Claim, but it's worth noting there is no 'SiteOwner: true' claim. Below are the claims I see when debugging both the upgrade and original version of orchardcore.

Please find the IGlobalMethodProvider implementation method

MikeAlhayek · 2024-12-05T23:49:09Z

The SiteOwner no have any effect and is obsolete. the fact that the user has Administrator role should be all you need to grant access to all. Can you please check your role to make sure that the "Administrator" role is set as "System" role? just to make sure it was not migrated to something else.

I don't see any issue with your script except that the CryptoMangement is not static.

Instead of doing

using( var wait = RatAsyncHelper.Wait )
{
    wait.Run( authorizationService.AuthorizeAsync( user, Permissions.AccessAdminPanel ), b => allow = b );
}

can you do

return authorizationService.AuthorizeAsync(user, Permissions.AccessAdminPanel).GetAwaiter().GetResult();

Hopefully that helps.

gvkries · 2024-12-06T08:27:14Z

Thanks for your reply, our issue is specifically related to the users who have admin privilege no longer being able to access to admin page in our older version (1.8.3) which resides in a separate branch from our upgrade to 2.1.2.

In addition to what @MikeAlhayek said, if you migrate to newer versions the database will get updated. In general you can't go back to earlier version, because the schema might have changed.

ghost · 2024-12-06T17:00:38Z

Thanks for your response, we noticed this issue upon installing the 2.1.2 nuget packages. Our goal was to have the upgrade changes in their own separate branch for testing but as you said it has updated the common database as well. Are there any tweaks we can make to the code in 1.8.3 or the updated database to allow admin users to access the admin panel in our original 1.8.3 version.

gvkries · 2024-12-06T17:09:27Z

Thanks for your response, we noticed this issue upon installing the 2.1.2 nuget packages. Our goal was to have the upgrade changes in their own separate branch for testing but as you said it has updated the common database as well. Are there any tweaks we can make to the code in 1.8.3 or the updated database to allow admin users to access the admin panel in our original 1.8.3 version.

Maybe the simplest solution is to add the users to another role which only has the required permissions. This should then work in both versions.

MikeAlhayek · 2024-12-06T17:25:45Z

@gvkries I am not aware of any migration changes that will impact permissions. There is a migration that would create SiteOwner role is a rare case. But, I don't think migrations here will impact permissions. But the Newtonsoft changes could have impacted how the documents in the database are serialized.

@anthnyg12b did you try what I suggested here #17108 (comment) ?

It is not recommended to use the same database for production and preview environment. You should maintain separate database since we use code-first-approach which will allow the code to change the database. You could backup your production database into a new database and connect your upgraded code to the new database. this way you are testing with a copy of your production data without impacting your production data.

ghost · 2024-12-06T19:33:05Z

Yes, I did try the code change suggested in '#17108 (comment)', I still get the same issue. Thankfully this issue is on our non-prod database (which is shared by both the 1.8.3 and 2.1.2 branches).

hieucd04 · 2024-12-06T22:27:38Z

@MikeAlhayek I extracted & decoded JWT of both 2.0.2 and 2.1.2 versions below. (They are just dummy access tokens, not production access tokens).

Looks like the entire Permission property has been removed
I want to emphasize the API.Fusion.Policy.UnrestrictedAccess element. It is a custom permission I create. Is there any chance that the 2.1.2 version ... forgot to check custom permissions?

2.1.2 JWT

{
  "iss": "http://192.168.1.2/",
  "exp": 1733526384,
  "iat": 1733522784,
  "aud": "oct:Default",
  "scope": "openid profile offline_access",
  "jti": "55497c2c-1337-48f5-8997-624095e17508",
  "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier": "46jq65b68st5pss1gc5wpk9jn2",
  "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name": "admin",
  "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress": "[email protected]",
  "email": "[email protected]",
  "email_verified": true,
  "http://schemas.microsoft.com/ws/2008/06/identity/claims/role": "Administrator",
  "oc:entyp": "user",
  "sub": "46jq65b68st5pss1gc5wpk9jn2",
  "name": "admin",
  "role": "Administrator",
  "oi_prst": "oidc-interactive",
  "oi_au_id": "73195a486ea44c27a842ec543630dfcf",
  "client_id": "oidc-interactive",
  "oi_tkn_id": "836bd6d4797d46bda78240ef01ca9bd9"
}

2.0.2 JWT

{
  "iss": "http://192.168.1.2/",
  "exp": 1733527050,
  "iat": 1733523450,
  "aud": "oct:Default",
  "scope": "openid profile offline_access",
  "jti": "56391db1-0e36-474d-ab84-a7996a12f3a7",
  "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier": "4qzwbb88b023wrtx51q8hvn4m6",
  "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name": "admin",
  "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress": "[email protected]",
  "http://schemas.microsoft.com/ws/2008/06/identity/claims/role": "Administrator",
  "Permission": [
    "Administrator",
    "ManageSecurityHeadersSettings",
    "ManageShortcodeTemplates",
    "API.Fusion.Policy.UnrestrictedAccess",
    "ManageSettings",
    "PublishContent",
    "EditContent",
    "DeleteContent",
    "PreviewContent",
    "CloneContent",
    "AccessContentApi",
    "ListContent",
    "EditContentOwner",
    "ViewContentTypes",
    "EditContentTypes",
    "ViewProtectedPages",
    "AccessAdminPanel",
    "ManageAdminSettings",
    "ManageTemplates",
    "ManageAdminTemplates",
    "SetHomepage",
    "ManageUsers",
    "View Users",
    "ManageOwnUserInformation",
    "ListUsers",
    "EditUsers",
    "DeleteUsers",
    "AssignRoleToUsers",
    "Import",
    "Export",
    "ManageDeploymentPlan",
    "ManageRemoteInstances",
    "ManageRemoteClients",
    "ExportRemoteInstances",
    "ManageFeatures",
    "ManageLayers",
    "ManageMediaFolder",
    "ManageMediaProfiles",
    "ViewMediaOptions",
    "ManageMenu",
    "ManageApplications",
    "ManageScopes",
    "ManageClientSettings",
    "ManageServerSettings",
    "ManageValidationSettings",
    "ManageQueries",
    "ManageRoles",
    "SiteOwner",
    "ManageTenants",
    "ManageTenantFeatureProfiles",
    "ApplyTheme"
  ],
  "email": "[email protected]",
  "email_verified": true,
  "oc:entyp": "user",
  "sub": "4qzwbb88b023wrtx51q8hvn4m6",
  "name": "admin",
  "oi_prst": "oidc-interactive",
  "oi_au_id": "8ef17bece0304e229b5077f073e43e0f",
  "client_id": "oidc-interactive",
  "oi_tkn_id": "05aa57db21b5486bbdfd86778c2dcae7"
}

MikeAlhayek · 2024-12-07T02:13:06Z

@hieucd04 that is expected. We no longer add permissions claims for Administrator users.

The code below, will grant authorization if the user has the Administrator role. So checking individual permission will always return true.

OrchardCore/src/OrchardCore.Modules/OrchardCore.Settings/Services/SuperUserHandler.cs

Line 33 in f433991

if (user.IsInRole(await _systemRoleNameProvider.GetAdminRoleAsync()))

if you can provide a repo, I can test it for you further. I am expecting this to be a problem in your project.

github-actions · 2024-12-24T20:40:32Z

It seems that this issue didn't really move for quite a while despite us asking the author for further feedback. Is this something you'd like to revisit any time soon or should we close? Please reply.

github-actions · 2025-01-01T00:57:52Z

Closing this issue because it didn't receive further feedback from the author for very long. If you think this is still relevant, feel free to reopen it with the requested details.

hieucd04 added the bug 🐛 label Dec 2, 2024

MikeAlhayek added the needs author feedback label Dec 2, 2024

github-actions bot added the stale label Dec 24, 2024

github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jan 1, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

`Administrator` doesn't have access to everything by default anymore #17108

`Administrator` doesn't have access to everything by default anymore #17108

hieucd04 commented Dec 2, 2024 •

edited

Loading

MikeAlhayek commented Dec 2, 2024

ghost commented Dec 4, 2024 •

edited by ghost

Loading

MikeAlhayek commented Dec 4, 2024

ghost commented Dec 5, 2024 •

edited by ghost

Loading

MikeAlhayek commented Dec 5, 2024

ghost commented Dec 5, 2024 •

edited by ghost

Loading

MikeAlhayek commented Dec 5, 2024

ghost commented Dec 5, 2024 •

edited by ghost

Loading

MikeAlhayek commented Dec 5, 2024 •

edited

Loading

gvkries commented Dec 6, 2024

ghost commented Dec 6, 2024

gvkries commented Dec 6, 2024

MikeAlhayek commented Dec 6, 2024

ghost commented Dec 6, 2024

hieucd04 commented Dec 6, 2024

MikeAlhayek commented Dec 7, 2024 •

edited

Loading

github-actions bot commented Dec 24, 2024

github-actions bot commented Jan 1, 2025

Administrator doesn't have access to everything by default anymore #17108

Administrator doesn't have access to everything by default anymore #17108

Comments

hieucd04 commented Dec 2, 2024 • edited Loading

Describe the bug

Orchard Core version

Expected behavior

MikeAlhayek commented Dec 2, 2024

ghost commented Dec 4, 2024 • edited by ghost Loading

MikeAlhayek commented Dec 4, 2024

ghost commented Dec 5, 2024 • edited by ghost Loading

MikeAlhayek commented Dec 5, 2024

ghost commented Dec 5, 2024 • edited by ghost Loading

MikeAlhayek commented Dec 5, 2024

ghost commented Dec 5, 2024 • edited by ghost Loading

MikeAlhayek commented Dec 5, 2024 • edited Loading

gvkries commented Dec 6, 2024

ghost commented Dec 6, 2024

gvkries commented Dec 6, 2024

MikeAlhayek commented Dec 6, 2024

ghost commented Dec 6, 2024

hieucd04 commented Dec 6, 2024

MikeAlhayek commented Dec 7, 2024 • edited Loading

github-actions bot commented Dec 24, 2024

github-actions bot commented Jan 1, 2025

`Administrator` doesn't have access to everything by default anymore #17108

`Administrator` doesn't have access to everything by default anymore #17108

hieucd04 commented Dec 2, 2024 •

edited

Loading

ghost commented Dec 4, 2024 •

edited by ghost

Loading

ghost commented Dec 5, 2024 •

edited by ghost

Loading

ghost commented Dec 5, 2024 •

edited by ghost

Loading

ghost commented Dec 5, 2024 •

edited by ghost

Loading

MikeAlhayek commented Dec 5, 2024 •

edited

Loading

MikeAlhayek commented Dec 7, 2024 •

edited

Loading