P22. A service shall have an "authentication, authorisation, endpoint strategy"

Skip to end of metadata
Go to start of metadata



Exceptions/special cases


SOA security and IAM


Doc status H2A A2A ACS CS Last PAB discussion

PAB discussions

Design-Time Governance - SOA Design Rules FAQ

  • [Question still to be asked..]
policy_cs policy_cs Delete
policy_acs policy_acs Delete
policy_a2a policy_a2a Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. May 12, 2010

    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.

    1. May 12, 2010

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

  2. May 12, 2010

    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.