Has anymore happened on this issue?
More comments below...
On 11/16/10 19:24, Scott Battaglia wrote:
The notion has always been that you can affect downstream but not upstream
(i.e. a TGT's expiration has an effect on PGTs, but not vice versa).
There's a few reasons:
a. I think its what CAS2 did which is what we based everything off of (and
since Yale wrote the original spec and version ... :-))
b. if you go upstream, i.e. a PGT affects a TGT, its also affecting other
PGTs (not sure if that's really a desired behavior)
c. A PGT is held on by another system (i.e. a portal). I can in theory
continue to use that PGT even after a human is no longer present. Only a
TGT can really determine if a human is present (i.e. interacting with the
CAS server itself).
I however, can see your point. If you're spending all your time in the
portal, you, the user, are not interacting directly with the CAS Server and
thus could be subject to an artificial timeout.
I don't know what the correct way to handle this without increasing risk too
much. One answer would obviously be for PGTs to merely check if their
parent was manually expired vs. timed out (and then they only rely on
*their* timeout).
Scott, is this viewed as a security risk because of potential security
flaws in applications that use the proxy capability, or is it viewed as
a security risk if someone hacks a server that has proxy capability?
If it is the former, perhaps just make it an "option" that is disabled
by default? Organizations can restrict the proxyValidate to only
"approved" proxy applications, that they trust. Is that already an
option? That could be suggested in a comment in the config file.
Thoughts from anyone?
--
Trenton D. Adams
Senior Systems Analyst/Web Software Developer
Navy Penguins at your service!
Athabasca University
(780) 675-6195
:wq!
__
This communication is intended for the use of the recipient to whom it
is addressed, and may contain confidential, personal, and or privileged
information. Please contact us immediately if you are not the intended
recipient of this communication, and do not copy, distribute, or take
action relying on it. Any communications received in error, or
subsequent reply, should be deleted or destroyed.
---
--
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
