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 <[email protected]> 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" <[email protected]> > To: [email protected] > 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 [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- > 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 -- 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
