I'm not sure that I do. Two if the propositions seem a bit iffy to me, at least in some circumstances.
'Policy as code' seems reasonable, except I have seen a lot of situations (most of them related to complex CMS deployments) where all of the concerns and constraints were the same as described here, but the solution was to treat policy (and more significantly, policy overrides) as content.
Similarly, I am not at all certain that moving authorization to an external service would even be possible, much less maintainable, in many intranet and extranet deployments. And if the individual applications adhered sufficiently to a standard interface to make it possible, then doesn't the motivation for using a service mostly go away?
2 comments
[ 2.8 ms ] story [ 12.2 ms ] thread'Policy as code' seems reasonable, except I have seen a lot of situations (most of them related to complex CMS deployments) where all of the concerns and constraints were the same as described here, but the solution was to treat policy (and more significantly, policy overrides) as content.
Similarly, I am not at all certain that moving authorization to an external service would even be possible, much less maintainable, in many intranet and extranet deployments. And if the individual applications adhered sufficiently to a standard interface to make it possible, then doesn't the motivation for using a service mostly go away?