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.
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.