RE: Cosign Multi-factor Authentication Spec

["Carson, Cassandra" <clcarson@xxxxxxxxxxxx>]

Hi Wes,

Just to be sure....Will this also work in reverse?  Meaning the user
visited henonprodop, but provided their token and then went to heprodop.
Since the cookie had the second factor, they would be accepted at
heprodop and not be prompted to provide the token again. 


-----Original Message-----
From: Wesley Craig [mailto:wes@xxxxxxxxx] 
Sent: Tuesday, October 11, 2005 11:54 AM
To: Meyer, Seth
Cc: Linderman, Mark; cosign-discuss Discussion;
mais.twofact.tech@xxxxxxxxx; Dandamudi, Bindu; Thomas, Katarina
Subject: 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.

:wes