Force UpdateProfile/SetupResponses problem with NAM

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Enable the User Activation module
2. Enable the Update Profile module + enable the Force Update Profile
3. Enable Setup Response + Force Response Setup in the Challenge policy
4. Place PWM behind NAM
5. Go through the activation process with a user

What is the expected output? What do you see instead?
After the token verification of the User Activation, the User gets logged in by 
PWM. After the login of the user, the public Change Password URL is called. 
However, we get a redirect, because the Force Update Profile and Force Response 
Setup kicks in.

This is working as expected, but the actual redirect URL of both Force Update 
Profile and Force Response Setup starts with "/private/". This is a big 
problem, as this is a protected resource by NAM. This results in the NAM login 
page being presented to the users. This leads to a dead end of the Activate 
User Process, because the User has to log in to NAM, but he/ she has not set a 
Password yet.

Proposed solution:
If Force Update Profile and Force Response Setup are called upon User 
Activation we need to make sure that public URL's are available for those 
Servlets and are called as well. I have adapted both the AuthenticationFilter, 
PwmServletURLHelper and web.xml to support:

- pwm/public/UpdateProfile
- pwm/public/SetupResponses

Attached a diff with the necessary changes

Original issue reported on code.google.com by sebastia...@gmail.com on 27 Jun 2013 at 12:07

Attachments:

• pwm-issue-412.diff

[GoogleCodeExporter]

Actually, the activate user module was broken under certain conditions 
(specifically with edir password-read enabled).  Where activate user should 
have always redirected only to change password, but instead it was simply 
logging in the user without marking the status correctly to force a change 
password.

Updated in revision 578.  Please test and see if this fixes your problem.

Original comment by jrivard on 1 Jul 2013 at 5:50

[GoogleCodeExporter]

Actually this patch creates a new problem for me, instead of fixing it. ;)

I assumed that Force Update Profile and Force Response Setup were meant to be 
run before the force password change. Otherwise the user is not encouraged to 
fill in the necessary information. This results in a less effective Forgotten 
Password module, because the user is not enforced to setup his C/R.

The above patch skips both steps and brings the user directly to the change 
password screen. After changing the password, the user gets logged in and the 
CommandServlet is redirecting that user to pwm/private/SetupResponses, instead 
of logging out the user. I would have expected that the user gets logged out 
after the password change.

Is there a reason for not putting Force Update Profile and Force Response 
Setup, before the change password?

Original comment by sebastia...@gmail.com on 2 Jul 2013 at 7:58

[GoogleCodeExporter]

bump ;) Could you have a look at my feedback? Thanks in advance!

Original comment by sebastia...@gmail.com on 2 Aug 2013 at 2:09

[GoogleCodeExporter]

On my system it is logging out the user after change password, do you have 
change password -> Logout after change password set to false?

Original comment by jrivard on 5 Aug 2013 at 11:30

[GoogleCodeExporter]

I'll test this again, maybe something has changed during new revisions. My 
"bump" was however targeted on the Force Update Profile and Force Response 
Setup timing.

Is there any reason why not to force users before the actual change? I think 
that would be a great way to make the Forgotten Password module more effective. 
If users are not forced to fill in the C/R before the password change, the 
ratio of actual users that have a C/R set would be significantly lower, because 
there is no momentum anymore to force them to do so. I would love to hear your 
feedback on his.

Original comment by sebastia...@gmail.com on 6 Aug 2013 at 7:05

[GoogleCodeExporter]

So from a use case perspective, your case makes sense.  After activation (and 
new user) , it would be lovely to go to profile update & setup responses.   The 
case for activation is a little slighted by the fact that having the user be 
"half-activated" (between when the activation generates a pwm login, and the 
user sets a password) is not ideal - so quickly getting to change password is 
ideal)

However the implementation complexity (and security concerns) has always turned 
me away from this.  Both urls would need to be made /public, and flow then has 
to keep track of the initial state.  

Additionally, its not hard to make nam force setup responses/update profile on 
authentication, so motivation is low.

I'm willing to consider a patch, but you might want to discuss your approach 
before working on it.

Original comment by jrivard on 7 Aug 2013 at 7:51

• Changed state: NeedInfo
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I understand that quickly getting to change password is ideal. We should not 
change that. My approach is that the check on Update Profile and Force Response 
Setup should have a higher priority so that they are forced before the Change 
Password. So the flow still ends in a force Change Password, only two extra 
enforcements before that.

After some extensive testing of making both public, I haven't seen any security 
issues. Making both Update Profile and Force Response Setup both public (beside 
a private URL) works much in the same way as the ChangePassword public URL:  
both need to go through the AuthenticationFilter to enforce a logged in User. I 
don't see how that differs from the current public ChangePassword 
functionality. Probably I'm overlooking something, your opinion?

Tracking the initial state could be done by looking at isRequiresNewPassword 
from the UserinfoBean. setRequiresNewPassword is only being called from 
ActivateUserServlet and ForgottenPasswordServlet.

About the motivation: when you have NAM in front of all your application 
(including PWM) the use case is not very viable. However my estimation is that 
most PWM implementations don't have NAM in front. In my personal situation we 
have just introduced NAM for a very limited amount of applications. The 
majority of the applications are still besides NAM. This makes the motivation 
higher, agree?

Original comment by sebastia...@gmail.com on 8 Aug 2013 at 8:18