CoSign: Collaborative Single Sign-On  

cosign-discuss at
general discussion of cosign development and deployment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cosign Multi-factor Authentication Spec

On 11 Oct 2005, at 11:35, Meyer, Seth wrote:
There is a URL containing /heprodnonop/ which we want to be single
factor protected. Conversely, there is a URL containing /heprodop/ which
we want to be two-factor protected. Each of these is hosted by wolverine
access web servers.

There are dozens of ways that might be configured. One simple way might be to establish different cosign service names for the two URLs, with different options.

Working through the sequence of registers, I don't think it's necessary to have different service names, tho. If the user visited / heprodnonop/ first and registers, then the locally cached data will list the single factor. When the user visits /heprodop/, the CosignRequireFactor check will fail, causing the filter to set a new cookie and redirect the user to the registration URL. The old cookie is overwritten in the browser. The UI would then indicate the need for the additional factor, the user would succeed (or fail) to login, and the user would be redirected back to the application, either / heprodop/ or a SiteEntry location. At that point, the locally cached data will list both factors, so either URL works.


Copyright © 2002 - 2004 Regents of the University of Michigan :  Page last updated 15-December-2010