I totally agree with you that it should be easy and safe to create test Azure AD environment, which we want more customers to realize :). I also like your approach to use policy base service like OPA to take care of policy base authorization or any other components to handle it would be more maintainable way, which we also consider.
Think about business model is the key to design the service as it affects entire architecture for sure <3
By the way, are you using OPA or any other service for policy check?
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
Thanks for reading my brain dump, and mentioning the possible issues in the article ;)
I believe the platform team (who owned the customer authorization flows) were considering the use of OPA (Open Policy Agent for those following along!) when I retired... it seemed like overkill at the time, so an anti-corruption API as I described was defined to permit changes to the authorization sidecar after services had been deployed.
I should note that we supported both federated access from our customer's OpenID Connect identity providers^, and managed accounts in an identity provider we operated (as an additional paid service) should they not have a corporate system in place or wanted to isolate accounts from their corporate system.
^ as a business-to-business company, this covered the majority of customers who typically had Azure AD, AWS Cognito, Google auth, Auth0 or similar in place. The major benefit to them was local control of accounts/service access, and to us - no more helpdesk calls to reset credentials! Federation FTW 😁
That's exactly I think every day!! Not many customers use only one service provider. Especially B2C service should consider supporting multiple Ids from first place so that we don't have to change architecture later.
I will consider writing another blog later about OPA and Web API as well.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I totally agree with you that it should be easy and safe to create test Azure AD environment, which we want more customers to realize :). I also like your approach to use policy base service like OPA to take care of policy base authorization or any other components to handle it would be more maintainable way, which we also consider.
Think about business model is the key to design the service as it affects entire architecture for sure <3
By the way, are you using OPA or any other service for policy check?
@phlash909 As your comment is important, I included the consideration in the article. Thanks.
Thanks for reading my brain dump, and mentioning the possible issues in the article ;)
I believe the platform team (who owned the customer authorization flows) were considering the use of OPA (Open Policy Agent for those following along!) when I retired... it seemed like overkill at the time, so an anti-corruption API as I described was defined to permit changes to the authorization sidecar after services had been deployed.
I should note that we supported both federated access from our customer's OpenID Connect identity providers^, and managed accounts in an identity provider we operated (as an additional paid service) should they not have a corporate system in place or wanted to isolate accounts from their corporate system.
^ as a business-to-business company, this covered the majority of customers who typically had Azure AD, AWS Cognito, Google auth, Auth0 or similar in place. The major benefit to them was local control of accounts/service access, and to us - no more helpdesk calls to reset credentials! Federation FTW 😁
That's exactly I think every day!! Not many customers use only one service provider. Especially B2C service should consider supporting multiple Ids from first place so that we don't have to change architecture later.
I will consider writing another blog later about OPA and Web API as well.