Bill,
This one:
* encapsulate known behaviors in a
DefaultTicketGrantingTicketExpirationPolicy, with an eye towards
shipping with sensible defaults such that folks will just use it
I imagine it would be a surprise to most CAS adopters who have simply
accepted the default ticket expiration policies that in fact an
Adversary, having hijacked a CAS single-sign on session in an e.g.
abandoned terminal, can with a wee bit of care continue to renew that
session forever so long as the CAS server stays available.
I therefore strongly feel the default TGT expiration policy should
include a hard timeout. CAS adopters should have to customize if they
want to opt out of a hard timeout, so that they can more clearly own the
decision to allow potentially eternally renewed single sign on sessions.
I'm not sure the type of ticket should creep into the name of this
default policy, however. It could just be TicketExpirationPolicyImpl,
with properties for
* number of allowed uses (-1 means infinite)
* sliding window time length
* fixed window time length
* frequency of use throttle time length
That is, one class with all the features, and then two configurations of
this class in ticketExpirationPolicies.xml .
I'm not particularly invested in the meta policy idea I articulated in
CAS-1003. Your idea of a concrete policy that incorporates the known
behaviors seems simpler and more to the point. I suggest it's worth
introducing in 3.4.x, and worth retiring the existing policies in favor
of in 3.5.
Andrew
On 08/02/2011 10:06 PM, William G. Thompson, Jr. wrote:
Folks,
I'm looking for some design input on a current need regarding Ticket
Expiration Policies for the TGT. I'm hopeful this work will result in
both a happy deployer and an improvement to the baseline product.
Currently, the follow Ticket Expiration Policies are available for TGT:
* TimeoutExpirationPolicy (the default - with 2 hour indefinitely
sliding window)
* HardTimeoutExpirationPolicy (the old default)
* ThrottledUseAndTimeoutExpirationPolicy (should be the current default?)
The current requirement is to have both a Timeout (aka sliding window)
and a HardTimeout (aka fixed window) such that during the fixed window
the sliding policy is in effect. In other words, the sliding window
will extend the lifetime of the TGT until a HardTimeout is reached.
For example, implement a policy where the TGT has a 3 hour sliding
window within an 8 hour lifetime. ThrottledUse would also be thrown in
for good measure.
Combining sliding and fixed window would prevent an SSO session from
being held open indefinitely (dodging the pathological case where a
CAS SSO session is hijacked (say, a browser session left open) and
that hijacking results in a months-long ability to SSO as that user.)
So...I could:
* just implement a
SlidingWindowWithHardTimoutAndThrottleUseExpirationPolicy and add to
the growing list of options.
* implement a meta policy as described in CAS-1003
* encapsulate known behaviors in a
DefaultTicketGrantingTicketExpirationPolicy, with an eye towards
shipping with sensible defaults such that folks will just use it
Thoughts?
Best,
Bill
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev
