After PIM activation into group membership, Storage Explorer needs Reset > Authentication to pickup new rights

[austindonnelly]

Preflight Checklist

• [X] I have installed the latest version of Storage Explorer.
• [X] I have checked existing resources, including the troubleshooting guide and the release notes.
• [X] I have searched for similar issues.

Storage Explorer Version

1.34.0 (99)

Regression From

No response

Architecture

x64

Storage Explorer Build Number

20240523.2

Platform

Windows

OS Version

Windows 11 24H2

Bug Description

Our RBAC config for a storage account grants Storage Queue Data Reader role permanently to a group, called QueueReaders - this is for normal monitoring use. If we need to edit the queue, we require users to PIM-activate into membership of a group called QueueWriters. The QueueWriters group is permanently granted Storage Queue Data Contributor access to the storage account, but normally has zero members until someone PIM activates their membership.

This works, but there's a long delay between activating group membership, and being able to operate on the queue in Storage Explorer. This can be sped up by going Help > Reset and resetting the authentication. This then forces a reconnect via the normal Account Management flow, and has the side-effect to getting a new user token.

The user JWT token lists the group memberships as part of the token, so I imagine that the token gets cached, and the effect of elevation isn't seen until the token is refreshed.

Would it be possible to have a "Refresh token" option in the menu somewhere, so we can get a new token faster?

Repro steps:

Steps to Reproduce

1. Setup RBAC groups as described in the report: a. create a QueueReader group, grant Storage Queue Data Reader to storage account. Add the test user to this group. b. create a QueueWriter group, grant Storage Queue Data Contributor to storage account c. configure QueueWriter group to be a PIM-enabled group, and configure the test user as eligible to activate into a member of the group. d. enqueue a test message into the queue.
2. Start Storage Explorer. Navigate to the queue. Check you can read the test message.
3. Attempt to delete the message: permission denied (expected) because you only have QueueReader membership.
4. PIM activate membership of QueueWriter group.
5. Attempt to delete the message: permission denied - unexpected, because user is now elevated. BUG.
6. Help > Reset chose authentication only
7. Re-add the user account
8. Attempt to delete the message: delete succeeds

Actual Experience

Delete queue message fails with a permission denied type error

Expected Experience

Delete queue message should succeed.

Additional Context

No response

[craxal]

@austindonnelly Yes, I'm guessing the token contains permission information. The PIM-activate changes the permissions granted to identities in the group, which effectively makes the permission information in the token out-of-date. I can see a manual token refresh being useful.

I don't think a full auth reset should be necessary, though. Can you just sign out and sign back in?

[austindonnelly]

Yes, that works (Remove account, Re-add account). But that's quite heavyweight compared to what I really would like, which is a "Refresh token" menu option.

[cveld]

We are heavily relying on PIM for providing temporary access to various file shares. It is currently a big hassle for our users to continuously having to remove account / re-add account. Would be very sweet to get this refresh access token feature implemented preferably sooner than later.

[MRayermannMSFT]

Hey @cveld and @austindonnelly, it sounds like we're probably all on the same page, but just in case, I'm still going to lay out our understanding of how Entra access tokens/needing to wait for RBAC assignment works.

Generally speaking, when you receive a new RBAC assignment, apps you are using might need to acquire a new access token from Entra before they can successfully make an API call which requires that role.

New access tokens are not acquired until they expire, and usually access tokens have a lifetime of one hour. This means it may take up to an hour for an app to start successfully making those API calls. However, singing out and back into an app is a way to immediately get a new access token.

We'd love to offer a "refresh access token" button to help make this problem go away, but unfortunately the Entra authentication libraries (e.g. MSAL) don't offer such a functionality to us. I definitely understand the frustration with this, as there are plenty of times I want to test something which requires a specific RBAC setup, and I have to sign out and then sign back in or wait an hour and then come back.

Let us know if you have any follow-up questions.

[austindonnelly]

Thanks for the clear explanation.

What about the following two options:

1. Make an ask to the MSAL team, requesting a "refresh" API to be added. Once that's in place, you can then start using it. This is a long-term strategy, but feels like the correct technical solution. It may also help other teams using MSAL who face a similar problem.
2. In Storage Explorer, implement "refresh" as signout followed by signin, but with simpler UI.

Austin

[craxal]

Option 2 is certainly doable, but it would require credential entry, because you're signing out and signing back in.

[cveld]

I believe I found the relevant ticket on the msal .NET client side: https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/4854