Quick overview of the AM policy framework:

AM decides what is / is not permitted but it's down to the policy agent / REST client to enforce these decisions. In this regard, AM is sometimes described as the Policy Decision Point (PDP) and the agent/client is described as the Policy Enforcement Point (PEP).

AM comes to these decisions by evaluating a set of policies (identified by the agent/client). These policies are defined by AM administrators.

Resources to be protected are modelled by URI and actions - Out of the box, AM comes with a web URL resource type with HTTP verbs (GET, POST, etc) as possible actions; it's easy to map other types of resources to URIs.

Each policy defines:

Certain policy conditions, such as requiring authentication to a specified authentication module, may not currently be met by a given subject but there are steps the subject can take in order to fulfil this requirement. When this happens, AM returns "advice" to the agent/client so that the user can be redirected back to AM's authentication framework to fulfil the requirement.

Session Upgrade

In versions of AM earlier than 5.5, upon completing the requirements of the policy advice, the user's session would be upgraded and thereafter the policy condition would always be met. This is not always the desired behaviour. Sometimes, we'd prefer to protect each invocation of a given action by an additional authentication/authorization step. For example, when making a bank transfer, I'd like to use 2nd factor authentication to protect each transfer.

Transactional Authorization

In AM 5.5.0, we've introduced a new "Transaction" policy condition which allows policies to require some re-authentication step every time they wish to perform the action protected by the policy. This new condition type can be used with complex policy conditions - For example, you may wish to require push authorization for bank transfers but only if the transferred amount is over $10.

Push Authorization

Adding "Push Authorization" is as simple as configuring a policy with a transaction condition which requires the user to complete an authentication chain, module or tree which includes push authentication. No changes are required to the mobile app.