I think the heading of this principle is a little vague, also it does not really adhere to a good IAM strategy. A service should actually not have it's own AAA strategy, it should however be able to consume any AAA-policies from an IDP. I think AAA-strategy is not necessarily a part of the service, but a part of the service inventory the service belongs to.
Based upon the current state of software development, we usually need to take one step at a time, and from no AAA-strategy to at least decide to have one is a huge step for many. In more mature organizations it does make completely good sense to enhance the rule to say : shall adhere to a distinct IAM and AAA-strategy (and possibly also contain the key parameters..)
I agree. If there is low maturity in an organization, it is better to say, AAA or no-AAA when the service is designed. Although, modern security platforms such as Open-SSO lets you take AAA responsibility out of the actual service.
3 Comments
comments.show.hideMay 12, 2010
Mario Aparicio
I think the heading of this principle is a little vague, also it does not really adhere to a good IAM strategy. A service should actually not have it's own AAA strategy, it should however be able to consume any AAA-policies from an IDP. I think AAA-strategy is not necessarily a part of the service, but a part of the service inventory the service belongs to.
May 12, 2010
Thor Henning Hetland
Based upon the current state of software development, we usually need to take one step at a time, and from no AAA-strategy to at least decide to have one is a huge step for many. In more mature organizations it does make completely good sense to enhance the rule to say : shall adhere to a distinct IAM and AAA-strategy (and possibly also contain the key parameters..)
May 12, 2010
Mario Aparicio
I agree. If there is low maturity in an organization, it is better to say, AAA or no-AAA when the service is designed. Although, modern security platforms such as Open-SSO lets you take AAA responsibility out of the actual service.