Admin options don't appear after Shibboleth authentication

[mspalti]

Describe the bug I can't find this described in another issue. I notice that when I login as an administrator using Shibboleth only basic options are rendered. All options become visible when I reload the page.

To Reproduce Steps to reproduce the behavior:

1. Login as an administrator using Shibboleth
2. Limited options are rendered
3. Reload the page
4. All options appear

Before and after images

[tdonohue]

@mspalti : Could this somehow be related to your other Shibboleth ticket (and its fix)? https://github.com/DSpace/DSpace/issues/8161 and https://github.com/DSpace/DSpace/pull/8160 I might be wrong, but this behavior sounds like it could potentially be related to Special groups (if Admin permissions are being inherited via a special group)...like they aren't loading initially, but then load properly on a refresh.

That's a bit of a guess, but just wanted to not it in case it helps us figure out what might be happening here.

[mspalti]

@tdonohue , I thought of that and checked. What I see doesn't appear to be related to changes in #8160 -- I'll verify again today just to be sure that's true.

In this case, my admin privileges are not inherited from a special group (I'm logging in with my administrator account). I can see the Administrator group when I check my "Profile"

[mspalti]

I see the same issue with and without the fix in #8160

[mspalti]

Of possible interest:

GEThttps://digitalcollections.willamette.edu/Shibboleth.sso/Login?target=https://digitalcollections.willamette.edu/server/api/authn/shibboleth?redirectUrl=https://digitalcollections.willamette.edu/home [HTTP/2 302 Found 25ms]

GEThttps://login.willamette.edu/idp/profile/SAML2/Redirect/SSO?SAMLRequest=jZJBU8IwEIX/Sid3mhIpQoYyg3CQGRSGVg9enDRdaGbSpGZT0X9voajowfGct++9/TYTFJWu+azxpdnCSwPog7dKG+Snh4Q0znArUCE3ogLkXvJ0drfiLIx47ay30moSzBDBeWXN3BpsKnApuFcl4WG7SkjpfY2c0kLtlRe6HdAgj2IMD0rr1tZ7CKFoaFqqPLcafBkiWnoMYnSzTjMSLNpmyojj2LejtntlfpuooqZts53ScHbYQqFcG0nTdE2C5SIhz/GwGMWDQSSHcTRiVxDt4iLfgSiGUrLdOG5liA0sDXphfEJYxFgvYr1+P2MRj645Gz+RYHMGcKNMocz+b1p5J0J+m2WbXrfVIzg8bdQKyHRyZM5Pwe7iCn/bik/0ZPp/0PgFekIvQrsGNb9vpcvFxmol34OZ1vYwdyA8JKRP6LQb+flpph8=&RelayState=ss:mem:ab68ded88bde2bf3d159ca157bd3476ea9912adcbd08ab36421bd41caf693a83 [HTTP/1.1 200 OK 737ms]

POSThttps://digitalcollections.willamette.edu/Shibboleth.sso/SAML2/POST [HTTP/2 302 Found 46ms]

GEThttps://digitalcollections.willamette.edu/server/api/authn/shibboleth?redirectUrl=https://digitalcollections.willamette.edu/home [HTTP/2 302 Found 92ms]

GEThttps://digitalcollections.willamette.edu/home [HTTP/2 200 OK 416ms]

Environment extended with app config config.util.ts:18:10 Some cookies are misusing the “SameSite“ attribute, so it won’t work as expected

[POST to https://digitalcollections.willamette.edu/server/api/authn/login] Cookie “Authorization-cookie” has been rejected because it is already expired. login Cookie “DSPACE-XSRF-COOKIE” has been rejected because it is already expired. login

[mspalti]

@tdonohue : when you get a chance to glance at this issue again, I just shared some console logging that shows cookies are rejected when connecting to the authn/login endpoint, because they have expired.

I'm not very familiar with how authorization works, but IF this looks like the probable cause for this issue, then the next question is whether it's the result of a DSpace bug or a misconfiguration in my server environment. Hoping for a misconfiguration.

[tdonohue]

@mspalti : I found time to test this today in my Docker setup. I cannot reproduce this issue when I test using https://samltest.id/ and the setup documented at https://github.com/DSpace/DSpace/tree/main/dspace/src/main/docker-compose#run-dspace-7-rest-and-shibboleth-sp-in-apache-from-your-branch

• First, I got that setup working in Docker, & verified that I could do a basic Shibboleth login via https://samltest.id/
• Then, I installed your PR (https://github.com/DSpace/DSpace/pull/8160) to get Special Groups working
• Then, on my DSpace backend, I setup this configuration to map the "manager" role (provided by samltest.id) to the "Administrator" group in DSpace

  authentication-shibboleth.role.manager = Administrator
  

• Finally, I logged in as a test user at samltest.id who has the "manager" role. After login in the UI, I see the full Administrators menu (no reload required).

Based on what you've reported above & the fact that I cannot reproduce it, it does sound like this is a configuration error. I'm not exactly sure where the issue lies, but you might want to double check your backend's settings, especially "dspace.ui.url" and maybe "rest.cors.allowed-origins" (it's possible you might need to add your Shibboleth URL to this one). You also should verify the frontend's "ui" and "rest" settings look correct.

If none of that helps, look more closely at the logs in general.

Those final lines in your last comment are definitely concerning.. I'm not sure how the "Authorization-cookie" or "DSPACE-XSRF-COOKIE" would be rejected...and the note about the "SameSite" attribute above that can possibly cause a cookie to be dropped/lost if the browser doesn't trust it. It sounds like the cause of your issues might be Cookie related, but they could stem from a configuration or setup issue.

[mspalti]

Thanks for testing this, @tdonohue I still haven't resolved the problem.

Your test case was different than mine. The administrator in my case is not a special group. So what I'm seeing (I think) is normal dspace group membership and feature authorizations are not resolved by the client's admin-sidebar.component when the page initially loads. When I reload as an already authenticated user then the sidebar component is initialized correctly.

The typedoc for the oneAuthorizationMatchesFeature (in authorization-utils.ts) provides a possible clue but I haven't had time to see if this is actually the cause:

Note: This expects the {@link Authorization}s to contain a resolved link to their {@link Feature}. If they don't, this observable will always emit false.

If false is returned then the admin sidebar option corresponding to the feature are not added to the menu.

[mspalti]

The logging that I shared for the "Authorization-cookie" and "DSPACE-XSRF-COOKIE" appears only in Firefox. It seems to be a harmless warning. I see the authorization header and JTW token after the request to login and the "Authorization-cookie" is removed as expected (Firefox is probably just being proactive about the expired cookie warning).

Since cookies and headers seem to be working as expected, I'm now inclined to think a bug in Angular is the more likely cause.

[mspalti]

After Shibboleth login the admin-sidebar menu for the user is initialized correctly when usedCachedVersionIfAvailable is false in the observable that's returned by authorization-data.service.ts isAuthorized() When set to true (the current setting) then the payload page array is always empty and a manual page reload is required to see admin options.

@artlowel or @atarix83 , I wonder what you would recommend here. I think I tracked down what's causing the issue with the admin-sidebar but not at all certain this is the correct "fix"

[mspalti]

@tdonohue : I realize you haven't verified this bug yet, but I'm pretty certain that it's real and that the PR above solves the problem. It's a small change but needs review by someone who is familiar with caching and authorization in angular. I'm still finding my way around.

[mspalti]

This issue seems to have reappeared with recent 7.3 updates.

[tdonohue]

@mspalti : Are you planning to work on this again? Otherwise, if you don't have time, we should move this into a new ticket so I can reassign it elsewhere (as this prior ticket was "fixed" by you, and the history/tracking will get confusing if we now reassign this to someone else)

[mspalti]

@tdonohue , a new ticket makes sense. I should have time to work on it later ,but not right now, and I wouldn't mind if there are other volunteers. I've discovered a related issue #1665 and suspect that Shibboleth authentication in the Angular UI needs a bit of attention.

[tdonohue]

I've been unable to find a volunteer to look at this. At this time it's uncertain if this will be fixable in 7.3. If anyone is interested, please get in touch.

[tdonohue]

Moving this to 7.4 as it wasn't able to be addressed in 7.3. Likely can be addressed alongside #1665

[mspalti]

This has started to work again for me - intermittently.