Customers are asking whether it is possible to prevent all AM configuration except for when OpenAM is first deployed (immutable devOps style of deployment).
Customers are asking whether it is possible to prevent configuration of AM on consumer facing AM instances to mitigate the risk of an attacker obtaining an admin token (through spear phishing, sniffing etc). Some of these customers choose to have separate AM instances for administration that are not consumer facing and only want configuration to be possible on these instances (financial services, banking customers).
My suggestion for catering for these is to support a JVM option for AM that prevents configuration from occurring on that instance. As the definition of configuration varies from customer to customer, I would suggest we define configuration as items that rarely need to change:
- Any global AM configuration
- Add/remove realms (although multi tenancy customers may not agree with this)
- Realm settings
- Realm AuthN settings
- Realm dataStores
- Realm Privileges
- Realm services
- All agents but NOT OAuth2 agents
- Policy resource types but NOT policy sets and policies themselves
- Realm STS instances
- Realm scripts
My experience is that a JVM option that makes the above items read only, even for amadmin, would satisfy the requirements that customers have mentioned in PS engagements.