On July 13, 2011 23:19 , Nick Ragusa <nrag...@brandeis.edu> wrote: > My department has recently been tasked with requiring our users to > fill out a web form or allow them to opt-out. Since the vast majority > of our applications are CoSign protected, we thought this would be a > great place to capture our users and redirect them after a successful > login. The current thinking is we'd have an additional factor on all > of our CoSign services which will be responsible for determining > whether or not the user has filled out our form (or decided to > opt-out) and either redirect them to this form (passing the > appropriate refer) or allow them to continue to whatever application > they originally were authenticating to (assuming we've verified they > filled out the form or opted out). I've noticed when specifying the > CosignRequireFactor directive, it looks for a script to simply return > a 0 or 1. Without major modification, is it possible to extend this > functionality to accomplish what we're after? Perhaps it's possible to > accomplish this using something other than the CosignRequireFactor > directive?
Here's one idea. It assumes that you control your institution's central weblogin servers. Create a new external factor. This factor should check (e.g., in a database you maintain) to see if the user has completed the form or has opted out; if so, it should return 1. Otherwise, it should return 0. When a user who has neither completed the form nor opted out accesses a service that requires this factor for the first time in a given web browsing session, they will be redirected to the weblogin page (the log-in form), since one of the factors was not satisfied. Add JavaScript to the weblogin page that checks the "factors" query string parameter for the name of your factor. If it is present, redirect the user to the web server that provides the web form. Include as a parameter the URL for the service that the user was originally trying to access (you can get this from the weblogin page query string). The other server will then let the user fill out the web form (or opt out), record this fact (in the database mentioned above), and then redirect the user's web browser to the URL of the service they were originally trying to access; this will restart the authentication check for this service, and the next time through, your new external factor will succeed, and the user will be able to access the service. You may need (or want, as a safety net) to have the JavaScript on the weblogin page check your database via an AJAX call before deciding whether to redirect the user. If you do this, you can get the user's username from the "login" field of the "factors" form. A problem with this approach is that you're trusting that the URL of the service the user was originally trying to access is not malicious. One (not great) solution would be to do validation of this URL in the same way the cosign filters do. Another approach would be to send the user back to the weblogin page with the same query string parameters they had the first time and let the weblogin server send the user back through the validation URL for that service (note that I have not tried this, so I don't know if it would actually work). This is all a little kludgy, but maybe someone else can suggest a better way. -- Mark Montague m...@catseye.org ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
