hi, one thing you could do is to store a flag in the Authentication-object (using the attributes-map) indicating that the password must be changed.
before issuing a service-ticket an extra webflow action checks for this flag (you need to create a lookup tgt -> authentication). if the flag is present all you have to do is to verify that the reason for the flag still exists (against your database, ldap or whatever you are using). if so, the service-ticket will not be created. keep in mind, that the attribute-map of the authentication-object is immutable. cheers odilo On Thu, Nov 17, 2011 at 10:26 PM, Trenton D. Adams <[email protected]>wrote: > Le 2011-11-05 06:13, Marvin Addison a écrit : > > I guess what I was really looking for is a way of making sure the handlers >>> get run again. >>> >> >> I can say from experience that you can do just about anything you can >> imagine with Spring Webflow. We don't have any documentation on the >> makeup of the CAS login webflow because it's basically >> self-documenting. (Assuming the reader has general SWF background.) >> >> Is there a way of having those run during authentication, AND during any >>> redirection to the service, AND store information in the session for >>> later >>> retrieval? >>> >> >> Your mention of session is concerning. Storing data in the SWF flow >> scope is synonymous with session storage (since it uses that under the >> hood), but it's important that you understand the scope of the login >> webflow is relatively short. It begins when the user first hits the >> login form, and in the case of successful authentication ends with the >> generation of a service ticket. The flow state effectively evaporates >> at that point. >> >> More generally, even if you were to store data directly in the >> session, it would be unreliable at best since interaction with CAS is >> sporadic and you'd likely have session timeouts where your session >> data on the CAS server is lost. So if you mean session to be the >> lifetime of a CAS SSO session, then both flow storage and underlying >> session storage is unsuitable for your needs. At that point your >> integration scenario becomes much more complex since you'd need to >> store your data into a durable store like that used by TicketRegistry, >> for example. >> > > We have an issue that we want to deal with. The handlers we have, detect > if the user needs to change their password (due to a bad one, for example), > and a variety of other things regarding the state of their login account. > > If there is something wrong with their account, we redirect them to a > service to change their password. So, in the case of the password check > handler, we can't just re-run it, because we no longer know the password, > because the SSO session is established. However, if we could store the > resulting "state" of the handlers, we wouldn't need to re-run them. > > I'm not concerned with session timeouts, seeing that the original handlers > would run again during the authentication process. > > All fine and dandy. But, if they simply hit the back button (to CAS), it > forwards them to the service they wanted to be at, rather than forcing them > back to the password manager. > > I was hoping to solve this at the CAS level, rather than at the password > manager application level. IMO, it's a hack to mess around with forced > redirects at the password manager application, to render the browser back > button unusable. I could also do a JavaScript hack to clear the previous > history, but again, that's a hack. I'm not aware of any "proper" way of > preventing back buttons from working, other than maybe forcing a "post" to > CAS at the end, to force the browser to say "hey, you shouldn't do that". > > After the password manager, we redirect back to CAS, with the original > service URL. I was hoping to append an extra parameter to CAS that I could > pick up, to wipe out the handler "state" mentioned earlier. This would > allow further passes through CAS to pass through un-interrupted. > > If someone has an idea on how to deal with that, other than through CAS, > I'm all ears. :P > > > -- > 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-user<http://www.ja-sig.org/wiki/display/JSG/cas-user> > -- 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-user
