[cas-dev] AuthorizedDecider --> PrincipalDiscriminator ?

[Andrew Petro]

Should the AuthorizedDecider API be so specific?

boolean isAuthorizedToUseApplication( ...

It seems like an "isAuthorized(" would be better, leaving it implicit *what*
the decider is authorized to do, and thereby making AuthorizedDecider usable
for something other than authorization to use the application.  Conceivably,
one might, given that the Assertion and within that the Principal can be
bound into ThreadLocal, apply an authorization aspect configured with one of
these deciders at a finer granularity than at the point of using the
application at all.

It doesn't seem that enough is gained by the specificity here.  What
authorization is being decided can be made clear by the objects dependent
upon an AuthorizedDecider at the point where they are supplied.  E.g., it is
clear from the context of AuthorizationFilter that what is being decided is
authorization to pass through the filter.


I wonder if the API should be about authorization at all.  What we have here
is a discriminator among Principals.  It examines a Principal, and
determines whether that Principal is of some subset of all possible
Principals.  So how about

/**
 * Discriminates among Principals, indicating whether a given Principal
 * is a member of some subset of all possible Principals.
 */
public interface PrincipalDiscriminator {

  /**
   * Returns true if the given Principal is a member of 
   * the subset of all possible Principals that fulfills the 
   * requirements of this Discriminator.  Returns false otherwise.
   */
  public boolean principalIsMemberOfSubset(Principal p);

}  


While a compelling use for a PrincipalDiscrimator is as the rule behind an
authorization gate (Filter, Aspect, etc.), there are other uses for
discriminating among Principals.  I could have a Controller that returns one
or another View depending upon whether the Principal is selected by an
injected Discriminator.  I could write a PrincipalDiscriminator that checks
a Principal against an accessibility preferences store and is suitable for
determining whether an application should go into text-only highly
accessible responses.  There are any number of things one could do with an
API for discriminating among Principals.

I wouldn't suggest designing or building a bunch of stuff I don't yet
actually have a need for; that sounds like a way to wander far afield.  But
it seems prudent to factor the solution to this immediate problem (providing
an API for configuring who is allowed through an authorization filter) to be
more re-usable since it looks to be exactly the same API with more general
words.