And please ignore the typos (Apple auto-correction is playing tricks on me again this morning) ;-)
On Sep 24, 2014, at 10:03 AM, Dmitriy Kopylenko <dkopyle...@unicon.net> wrote: > The current implementation “caches” principal attributes in memory (Map > object attached to Principal) once resolved and associates them (via this > authenticated Principal) in TGT (web sso session). No new attributes in the > back end store are reflected until the sso session is killed and the new one > is re-establised. > > If my vote counted, I’d +1 for adding this behavior encapsulated be hid > higher level Principal abstraction (as discussed in the PR). > > Cheers, > Dmitriy. > > On Sep 24, 2014, at 9:52 AM, Waldbieser, Carl <waldb...@lafayette.edu> wrote: > >> >> Am I correct in understanding that the current behavior is to load the >> attributes at the time of authentication and they get stored for the life of >> the TGC (in the CAS ticket store)? >> >> And the proposal would be to allow the attributes to be re-populated >> whenever a /serviceValidate or /proxyValidate request was successfully made? >> >> I hadn't noticed this behavior. I had rather assumed the dynamic behavior >> was how CAS was working all along. What exactly would be the concerns with >> enabling that as an option? Are there performance concerns? Or some kind >> of consistency concerns? >> >> Thanks, >> Carl Waldbieser >> Systems Programmer >> Lafayette College >> >> ----- Original Message ----- >> From: "Misagh Moayyed" <mmoay...@unicon.net> >> To: cas-dev@lists.jasig.org >> Sent: Wednesday, September 24, 2014 5:23:29 AM >> Subject: [cas-dev] Dynamic Principal Attributes: scope and feedback >> >> Team, >> >> >> >> Context: >> >> https://github.com/Jasig/cas/pull/676 >> >> https://github.com/Jasig/cas/issues/468 >> >> >> >> There is a pending pull and corresponding issue that tries to bring forth >> support for dynamic principal attributes. This is the case where principal >> attributes are not cached to the length of the SSO session, but are forced >> to always be up-to-date when called upon. I want to emphasize that this is >> not proposed replace the default behavior now, yet simply allows one to do >> this, should the use case come up. >> >> >> >> Jérôme and I have been conversing on pros and cons of this feature, and >> what it would mean for CAS deployers to turn on support for this. We are >> at a point where we need more eyeballs and feedback on the issue and the >> solution presented. It would be great if you could take a look at the >> conversation and provide suggestions on how to best proceed forward. >> >> >> >> Regards, >> >> >> -- >> You are currently subscribed to cas-dev@lists.jasig.org as: >> waldb...@lafayette.edu >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev >> >> -- >> You are currently subscribed to cas-dev@lists.jasig.org as: >> dkopyle...@unicon.net >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
