Re: [Cosign-discuss] unsetting a factor?
On Fri, Sep 11, 2015 at 10:15 AM, Jorj Bauer wrote: > > I think I get the desired behavior if the expiry factor script exits > with return code 2 (COSIGN_CGI_PASSWORD_EXPIRED) when the account is > expired, instead of issuing the factor. > > That will work as long as you're invoking it as a factor, and not a > userfactor. The latter doesn't have any checks around the return code > (which is probably a bug). > There are currently two portions - an expiry check and and expiry enforcer. The check is via userfactor, the enforcer is a factor factor. Could it have all been done in a factor? Liam -- ___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] unsetting a factor?
Sent from my iPhone > On Sep 11, 2015, at 9:48 AM, Liam Hoekenga wrote: > > I think I get the desired behavior if the expiry factor script exits with > return code 2 (COSIGN_CGI_PASSWORD_EXPIRED) when the account is expired, > instead of issuing the factor. That will work as long as you're invoking it as a factor, and not a userfactor. The latter doesn't have any checks around the return code (which is probably a bug). > > What would you think about an additional argument to "factor" that would > require the factor be evaluated every time? Maybe invoking the reauth > mechanism? Maybe. In general I'm loathe to extend the interface without cleaning up what's already there. And if what's already there is sufficient, even more so. -- ___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] unsetting a factor?
On Fri, Sep 11, 2015 at 7:51 AM, Jorj Bauer wrote: > A better (cleaner) solution might be to rename your primary factor to, for > example, UMICH-PREAUTH, and then have the user factor check that the > password's not expired and that the PREAUTH factor is fulfilled before it > issues your old primary factor. I think I get the desired behavior if the expiry factor script exits with return code 2 (COSIGN_CGI_PASSWORD_EXPIRED) when the account is expired, instead of issuing the factor. What would you think about an additional argument to "factor" that would require the factor be evaluated every time? Maybe invoking the reauth mechanism? It's always kind of bugged me that one token code would unlock everything that needed a token code for the entire duration of a cosign session.. Liam -- ___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] unsetting a factor?
Without trying it, I think your user factor script could remove the cookie from disk and to force a re-auth; it could also do some jiggery-pokery in Kerberos to disable or remove the principal. A better (cleaner) solution might be to rename your primary factor to, for example, UMICH-PREAUTH, and then have the user factor check that the password's not expired and that the PREAUTH factor is fulfilled before it issues your old primary factor. There are probably other ways to do this too; those are the two that quickly spring to mind. -- Jorj Sent from my iPhone > On Sep 10, 2015, at 10:04 PM, Liam Hoekenga wrote: > > Our CSO has mandated that we implement password expiry. > Cosign uses kerberos for it's credential store, but the password policies > will be stored in LDAP. > > If the user logs in, and their password is in a warning period, cosign will > report that the user's password is expiring soon, and give them the option to > either continue to their service, or change their password now. > > If the user logs in, and their password has "expire", cosign will tell the > user that their password has expired, and send them on the password > management application. > > We're using the userfactor stuff to handle this. The userfactor invokes a > script that checks the cosign service, and the user's password status via a > webservice. > > If the user is in the warning period or their password has expired, we > requires the "pw_expiry" factor. (If the cosign service they're trying to > access is the pw management application, we just let them through). > > The pw_expiry factor is satisfied by stuff in the pw expiry UI element. > > We'd like to prevent users whose passwords have expired from accessing any > services until they've changed their password, resetting those results > returned by the webservice. > > What we've got now works ok, but if someone has satisfied the pw_expiry > factor, the next time they access a cosign protected service, they're passed > right through. > > To get the desired behavior, it seems like we'd need to unset the pw_expiry > factor. > Any suggestions on how to implement this without unsetting the factor? Or > how we might implement unsetting the factor (maybe logging that factor out)? > > thanks! > Liam > -- > ___ > Cosign-discuss mailing list > Cosign-discuss@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cosign-discuss -- ___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
[Cosign-discuss] unsetting a factor?
Our CSO has mandated that we implement password expiry. Cosign uses kerberos for it's credential store, but the password policies will be stored in LDAP. If the user logs in, and their password is in a warning period, cosign will report that the user's password is expiring soon, and give them the option to either continue to their service, or change their password now. If the user logs in, and their password has "expire", cosign will tell the user that their password has expired, and send them on the password management application. We're using the userfactor stuff to handle this. The userfactor invokes a script that checks the cosign service, and the user's password status via a webservice. If the user is in the warning period or their password has expired, we requires the "pw_expiry" factor. (If the cosign service they're trying to access is the pw management application, we just let them through). The pw_expiry factor is satisfied by stuff in the pw expiry UI element. We'd like to prevent users whose passwords have expired from accessing any services until they've changed their password, resetting those results returned by the webservice. What we've got now works ok, but if someone has satisfied the pw_expiry factor, the next time they access a cosign protected service, they're passed right through. To get the desired behavior, it seems like we'd need to unset the pw_expiry factor. Any suggestions on how to implement this without unsetting the factor? Or how we might implement unsetting the factor (maybe logging that factor out)? thanks! Liam -- ___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
