Hi Eric,
If I write a custom AuthenticationHandler that throws AccountException, can I tie into the transitions in login-webflow.xml? If so, is "code" or "type" the variable that would need to be set to "accountLocked"/"accountDisabled"/etc? Yes you can. The messages that you do see are based on the Ldap Password Policy Enforcement of CAS that allows one to detect certain Ldap error scenarios and translate them back to an actual flow throughout the logic experience. While those are specifically thrown and managed by Ldap authentication handlers as you have correctly noted, it wouldn't be farfetched to come up with a custom authentication handler that pretty much does the same. Ultimately the exception that you throw back should indicate what its "type" is, and that same type in the login webflow is translated back to a particular state to which the user is redirected to for additional instructions and maintenance. I am excited that you're building upon those extension points. LPPE itself is going through a set of improvements and enhancements that are outlined somewhat verbosely here: https://wiki.jasig.org/pages/viewpage.action?pageId=55543468 Throughout your endeavor, if you come across issues or feature improvements, please don't hesitate to speak up. Feedback and suggestions would be most welcome. Regards, -Misagh From: Stein, Eric [mailto:[email protected]] Sent: Tuesday, December 18, 2012 9:38 AM To: [email protected] Subject: RE: [cas-user] CAS and Login Intercepts Thanks, Andrew! Unicon does look like a great start. I wish I could use it out of the box, but since it relies on LDAP I've got some hacking ahead of me. I do have a question that may be Spring related. In login-webflow.xml, there are transitions for "accountLocked", "accountDisabled", etc inside <action-state id="realSubmit">. It looks like those come from AuthenticationException being thrown from BindLdapAuthenticationHandler#authenticateUsernamePasswordInterna()l. If I write a custom AuthenticationHandler that throws AccountException, can I tie into the transitions in login-webflow.xml? If so, is "code" or "type" the variable that would need to be set to "accountLocked"/"accountDisabled"/etc? Thanks, Eric From: Andrew Petro [mailto:[email protected]] Sent: Tuesday, December 11, 2012 3:19 PM To: [email protected] Subject: Re: [cas-user] CAS and Login Intercepts Hi Eric, Welcome to the CAS community. :) You might find this a good starting point for password change, password bootstrapping, etc.: https://github.com/Unicon/cas-password-manager CAS has features for automatically failing login attempts after too many failures too quickly. I posted about that recently here: http://www.unicon.net/blog/apetro/failed_login_attempt_throttling_cas You're right that current CAS doesn't differentiate between failure because of throttling failed login attempts versus failure because the password was wrong. Differentiating is probably a good idea allowing a better user experience, and of course once it was differentiating you could customize the differentiated error message to suggest the password reset opportunity. A common current practice is simply to put the account recovery link on the CAS login form page and users once sufficiently frustrated will click it to recover their account. Hope this helps, Andrew On Tue, Dec 11, 2012 at 12:38 PM, Stein, Eric <[email protected]> wrote: Hi, I'm running CAS 3.5.0. I've got a trivial application authenticating to our database (Yay!). I've now been tasked with adding all the standard stuff - change password screen, forgot password screen, user locked out after N failed attempts, etc. I haven't seen any documentation on the jasig site about doing any of these things. I have two webapps right now: hello-world.war - client application locus-cas-webapp - a CAS war overlay application a) Change password/forgot password - do these go in a third webapp, or can I put them in locus-cas-webapp? b) How do I lock out a user if they fail to log in X times? My current setup would have me updating a column in USER_TABLE. c) If the user is locked out, I'd like to push them to the "forgot password" screen. I didn't see any hooks into this kind of behaviour - how would this be handled? d) If a user has a temporary password (created by the forgot password screen and currently tracked in a column in USER_TABLE), how do I redirect them to the "change password" screen? For (c) and (d) it seems like I need a hook into CAS after the authentication information is entered and either before the authentication is performed or post-authentication and pre-forwarding. I've been doing java forever, but I know nothing about Spring, so please modulate any answers accordingly. Thanks very much, Eric Stein -- 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 -- 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 -- 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 -- 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
