IMHO, one thing I would suggest is go to the Azure App Registration and target specific user(s)/group(s) you will allow access to PSU, then in the App Registration’s token configuration select to only include groups assigned to the application. This cuts down on token bloat, and is probably best from an OpSec perspective to not unnecessarily expose users’ group memberships.
That’s true, except that it kills your ability to use nested groups. In my case I have to use ‘Only groups assigned to application’ because we’re a fairly large organization with loads of groups. I’ll be working on transitioning to a 1:1 no-nesting format unless I figure out a different way to do it.
Yeah, you’re absolutely right. We do our best to avoid nesting groups (“one group, one purpose” mantra). Definitely recognize my suggestion doesn’t work in your setup.
I wish I had found this thread before as it would have saved me several weeks of aggravation. As of today, this is what I found about setting up OIDC in PowerShell Universal as a web app in azure:
The recommended method, I.E. going to authentication and setting up OIDC from “Add authentication method” DOES NOT SAVE THE CLIENT SECRET. I finally solved the 500 error by going to Configurations/Authentication.ps1 and inserting the client secret there. Thanks to rp53 for that.
Now for the real kicker: Once you’re ready with OIDC and are prepared to remove Form Authenticationto secure your site, DO NOT remove by disabling it from the Authentication section. If you do that, it will overwrite the OIDC section and remove the Client Secret again.
Apologies for all the aggravation. We’ve identified the issue that was causing the secret to not save. It was actually clearing the secret in memory even though it persisted in the authentication.ps1 file. The really bummer with this bug is that all it took to remove the secret was to visit the authentication page. This is resolved in our next 2.x and 3.x versions.