On Thu, Jul 1, 2010 at 10:37 AM, Kiran Ayyagari <email@example.com>
> I see your point.disabling PP is done based on the configuration, so it is not
> Here, we have two options :
> - merge the PP interceptor into the Athn interceptor (this is what you
> - have the PP interceptor being processed after the authn, which is
> The question is more or less about the PP being a part of the authent
> process, or if we want to have a separate module just to have a distinct
> processing for the PP (this could make sense if we want to disable the PP).
> The reason why the PP interceptor is separate atm is that it was not present
> at the origin, and was added after. The Intecreptor chain allows us to have
> such a separation, and it was easy to add featuers this way.
> Now, I'm not sure it makes sense to make a distinction between the PP and
> auth interceptrs at this point, if we consider that PP is a part of the
> server (ie, it can't be disabled).
intrusive. If the PP configuration
is not provided then the AuthenticationInterceptor skips all checks
related to PP.
I'm not sure we want to disable the PP anyway :) As I said, it was made an interceptor for historical reasons, and I do think it must be part of the server anyway - even if no policy is set :)