When using the MSALGuard and RoleGuard on a route, the Role guard will allow access even if the user does not have the correct role about ms-identity-javascript-angular-tutorial

[derisen]

@Depechie thank you so much for catching this. Let me try to reproduce it and get back to you.

[Depechie]

Hey @derisen I will try to create a sample app and put it up on GitHub and list steps I did.

Maybe I did something wrong and that way you can spot it.

I will get back later this week!

Thx for the info by the way!

[derisen]

@Depechie apologies for the late response, we've been unusually busy these days. I can reproduce this with the repo you shared. It seems this is simply not a scenario we've considered i.e. enabling RoleGuard for the main route where the user signs into.

My understanding is that, in the sample from this repo, when a user hits a component route that has MsalGuard and RoleGuard enabled (like http://localhost:4200/dashboard), she will prompted for sign-in via MsalGuard, and then after sign-in will be redirected to the main route first http://localhost:4200/ (which doesn't have RoleGuard), and then will be redirected back to http://localhost:4200/dashboard, which at that point account info will be available to RoleGuard.

I don't have a solution right now but I will put this to backlog and pick it up first when we start updating the samples in this repo. I'm also not entirely sure if this is a legitimate use case, or rather, the best approach to handle this use case. If the user is simply needed to be in a particular role to sign-in to the application, perhaps requiring user assignment would be a better way to handle it?

Nevertheless, if you come up with a solution please feel free to make a PR.

[derisen]

That's fair enough. What I'm thinking is that it might be better to use a single custom guard that combines MsalGuard and RoleGuard, though I can also see the merit of getting multiple guards to work in tandem. There's an understanding that MsalGuard will not only be able to cover all use cases, so this repo should have at least one example of a custom guard to replace it. Let me look into these. I'll keep this issue open until then -and thank you for all the feedback!

[derisen]

@Depechie of course, my bad. Right now the updated sample is using a custom guard based on MsalGuard (pretty much copy/paste), and then extending it in a role guard. Ideally the MsalGuard itself should be extensible, and I'm separately working on a PR to msal-angular for doing just that. That could take a while so for the moment, I think this is the way forward, but I'm open to suggestions.

[Depechie]

Thanks! Will take a look as soon as I find some time!

[Depechie]

@derisen just wanted to circle back that this works great!
But true, now having that baseGuard directly in our code would be nice to get rid off once the base lib has a guard that is extendable.

[derisen]

Sounds great! Still working on making this extensible by default, hopefully will get this in to msal-angular

[github-actions]

This issue has not seen activity in 14 days. If your issue has not been resolved please leave a comment to keep this open. It will be closed in 7 days if it remains stale.

[Depechie]

Comment for getting out off the stale bot

[derisen]

@Depechie thanks for your patience! However I don't seem to be able to reproduce this. What I did is that I added MsalGuard to the root route as you mentioned, then attempted to call (in private mode):

• http://localhost:4200/#/dashboard - app throws an error (Cannot read properties of undefined (reading 'idTokenClaims')), this should be handled better but in any case it's a separate issue.
• http://localhost:4200/dashboard - app attempts to sign-in the user, then redirects to root route. After that, roleGuard seems to be working (trying this with a user in TaskUser role).

Are there any steps I'm missing?

p.s. sorry, I should have mentioned -I'm using Angular 11 (same as the sample), I wonder something if Angular version is the culprit here. Will upgrade Angular soon and try again (we will start updating all the samples in the repo soon).

[Depechie]

Hey @derisen so I uploaded a basic sample here: https://github.com/SanITy-BV/BirdAtlas-frontend/tree/guard
I also recorded the logging with an animated gif, you can follow along here: https://raw.githubusercontent.com/SanITy-BV/BirdAtlas-frontend/guard/Animation.gif

So when the app is first started, the MSAL guard will kick in and do a redirect to the login flow, this works perfectly. But when that flow is done, you will see the begin screen of the web app.
This is due to the fact that the 2 gaurds are already passed at the same time during initial startup. You will notice in the console logging that the Role guard thinks no account is available ( this is true we are not yet logged in at that time due to the MSAL guard still needs to kick in ) and that no check can be done..

If you then just refresh the page, the same 2 guards are processed and now the Role guard has enough info to actually do the processing and will show that there is an account and the guard check has been done.

I hope this explains my issue.

[derisen]

thanks @Depechie looking at this now -will get back

[Depechie]

Thanks @derisen for the detailed response! No worries about the actual timing of any samples. At least I'm getting info and am very glad it was not something I did wrong in the setup ( could always have missed something ).

As off the use case, well... we just want to be sure that IF a user get's hold of a url all guards are validated. In our case this also means checking that you are at least in a certain app role. There are several roles and depending on which the main page will look different. Or if you do not have any role assigned you should not be able to see anything.

But I understand this could maybe be solved in another flow/way too.
At least I would like to check the roles 'after' the login and maybe we could redirect to a certain 'not allowed' page?

[Depechie]

Combining in a single one would be a perfect solution for use!
Not done that though for MSAL, is there an example for that scenario maybe?

[derisen]

I'm afraid not at the moment. There was also a feature request for extending MsalGuard, but nothing has been delivered on this so far. I suppose you can copy paste the MsalGuard code into a new guard and add the role check there, but I'll for sure add an example here eventually.

[github-actions]

This issue has not seen activity in 14 days. If your issue has not been resolved please leave a comment to keep this open. It will be closed in 7 days if it remains stale.

[derisen]

keep open

[github-actions]

This issue has been closed due to inactivity. If this has not been resolved please open a new issue. Thanks!

[github-actions]

This issue has been closed due to inactivity. If this has not been resolved please open a new issue. Thanks!

[derisen]

@Depechie this should now be fixed (using a custom guard based on MsalGuard). Thanks again for catching this!

[Depechie]

Hey @derisen could you elaborate a bit more?
Has something changed since your original response ( #180 (comment) ), in other words is there now more guidance on creating those custom guards maybe?

Not keeping track of all the MSAL updates, so could be I'm missing obvious of course :)