Java Reference
In-Depth Information
custom condition, but the scenario is trickier. In particular, permission checks tend to
be fine-grained, and in this case executing the condition is costly (and potentially
annoying to the user). Luckily, the Conditional Permission Admin Service specifica-
tion defines mechanisms to deal with such situations.
POSTPONED CONDITIONS
Certain conditions can be costly to evaluate, such as asking the user for permission. In
such situations, you should evaluate the conditions as
postponed conditions
. Doing so
causes the framework to delay their verification until the end of the permission check.
A condition informs the framework that it's postponed by returning
true
from the
Condition.isPostponed()
method. A condition must always return the same value
for the
isPostponed()
method, so that the Conditional Permission Admin Service
can cache the value. If the method returns
false
, the no-argument version of the
isSatisfied()
method checks the permission, which is intended to be used for quick
evaluations. On the other hand, if the method returns
true
, the version of
isSatis-
fied()
that takes arguments is used; it's intended for more costly evaluations.
For example, a condition can verify whether a mobile phone is roaming. This
information is readily available in memory, and therefore this condition need not be
postponed. Alternatively, a condition obtaining authorization over the network
should be postponed to avoid the delay caused by network latency if not necessary.
Looking more closely at the parameters of the
isSatisfied()
method used to
evaluate postponed conditions, you see that it takes an array of
Condition
objects and
a
Dictionary
. The array always contains a single element: a reference to the receiving
condition. This behavior was introduced in the R4.2 specification, because prior spec-
ification versions could verify multiple conditions at the same time. As a result, this
change makes the array relatively worthless. The method was reused to avoid creating
a breaking change for existing custom conditions. The
Dictionary
parameter is a
context object for the condition implementation, which it can use to maintain state
between invocations. The same
Dictionary
object is passed into all postponed condi-
tions of the same type during a single permission check.
Impact on creating security policies
From the point of view of the security-policy creator, it doesn't matter whether a con-
dition is postponed. The impact is in how the framework processes the conditions
and/or how the condition implementation optimizes evaluation. The important result
is that the framework evaluates postponed conditions only when no immediate con-
dition entry implies the required permission, which allows the framework to avoid
costly condition evaluation if possible. When you're creating a security policy, you can
ignore this aspect of conditions.
You now understand the theory behind postponed conditions. Let's implement an
example that asks the user to authorize permissions.
