Good talk that finally went into the *actual implementation* that a developer would have to physically create instead of just a talk that says "use OAuth 2 with AAD!". What wasn't clear to me was why I didn't hear the phrase "managed identity" until the very end. Overall, this is trying to work using the same philosophy as windows auth for on prem domains using specific domain accounts to run things like IIS apps and windows services, and security groups to grant permissions to users, but for some reason it's all far more obscure in azure. It's also rather amusing that the claim of the technology is "you just define roles and then set everything up via config", and then we go and paste 200 lines of C#, lol.
He should have mentioned easy auth feature for the app service and what the APIM can do. If your closed to internal clients only and have azure ad, I’d recommend this route to start with and keep you app simple with no auth code. Passing jwt claims to the app via headers is much simpler and makes local dev simpler.
I don't think currently app roles assigned to service principals through an aad group propagates correctly. And the UI doesnt exist in portal to manage the assignment. Its a bit clunky. Also for local development you can use azure default credentials to retrieve logged in user token through az cli or vs or vscode
good talk but a lot of pulumi. most projects don't use pulumi so if the talk was about "click click on AZ portal" it wold be more generic and useful to all who get stuck with that Azure AD
thnx Jimmy, u well deserved my star on ur github ;)
Good talk that finally went into the *actual implementation* that a developer would have to physically create instead of just a talk that says "use OAuth 2 with AAD!".
What wasn't clear to me was why I didn't hear the phrase "managed identity" until the very end. Overall, this is trying to work using the same philosophy as windows auth for on prem domains using specific domain accounts to run things like IIS apps and windows services, and security groups to grant permissions to users, but for some reason it's all far more obscure in azure.
It's also rather amusing that the claim of the technology is "you just define roles and then set everything up via config", and then we go and paste 200 lines of C#, lol.
He should have mentioned easy auth feature for the app service and what the APIM can do. If your closed to internal clients only and have azure ad, I’d recommend this route to start with and keep you app simple with no auth code. Passing jwt claims to the app via headers is much simpler and makes local dev simpler.
41:15 really wish i could use scope for the app / client credentials. Azure wants them uniquely named. Graph api does it right.
The main question- to protect against what threats? How to assess reliability of particular method?
And only then - how to do it?
I SWEAR I went similar headache not too long with Microsoft AD
I don't think currently app roles assigned to service principals through an aad group propagates correctly. And the UI doesnt exist in portal to manage the assignment. Its a bit clunky. Also for local development you can use azure default credentials to retrieve logged in user token through az cli or vs or vscode
good talk but a lot of pulumi. most projects don't use pulumi so if the talk was about "click click on AZ portal" it wold be more generic and useful to all who get stuck with that Azure AD