IDP v3 - OpenLDAP password policy - forcing password reset

[Cantor, Scott]

On 5/19/15, 11:30 PM, "Emilio Penna" <emilio.penna at seciu.edu.uy> wrote:


>
>The shibboleth part: not allow authentication at idp, until the user has
>changed her password. (I think it would be possible given the
>integration with ppolicy via ldaptive and the great configuration
>flexibility of idpv3)

Just about anything is possible, but it can be difficult sometimes to get 
webflow flowing the way you need it, or there can be problems with the 
event handling behaving in unforeseen ways, it's not got all the kinks 
worked out. There's a lot of speculative pieces in place to hopefully 
allow certain things to plug in but not many of them were tested or 
explored.

>Given the message generated in ValidateUsernamePasswordAgainstLDAP:189,
>I think that I don't have the error code to map/catch in 
>password-auth-config (or somewhere else), for trying to change the flow 
>to deny user login...

Well, I think the main operation there is the bind. If that succeeds, I 
don't think anything you put into the map of messages is going to make it 
actually fail, but the ACCOUNT_WARNING string looks like it's just part of 
the default message being built:

String.format("%s:%s:%s", "ACCOUNT_WARNING", response.getResultCode(),
	response.getMessage())

That may be too aggresively mapped to ExpiringPassword because it looks 
like that will happen no matter what the Code or Message values are. I 
don't know if that's intentional or not, but the mappings are obviously 
not anything we care about, they should be whatever you need.

If you remove that from the configuration and add a mapping for whatever's 
coming back for the code or message to your own event, that becomes a 
custom event you can react to, and you could actually end up blocking the 
user from continuing with the login flow until they pass through a subflow 
that has a view to prompt for the password and do the change before 
continuing. If the login flow never finishes, the authn flow as a whole 
never finishes, and the profile flow never finishes, etc. I don't think 
anything the user does to trick it will make it continue if you build the 
view and action beans correctly.


So yes, I think it's possible.

The set of condition flows are extensible to additional ones that are 
called based on different events, you just have to modify 
flows/authn/conditions/conditions-flow.xml to know about them and call 
your new one.

Basically, you have: saml2-sso -> authn -> authn/Password -> 
authn/conditions -> something new

They're subroutines, basically. If the new one ends with "proceed", 
everything else finishes. If not, everything else fails.

-- Scott