|
|
 |
cosign-discuss at umich.edu
|
|
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
- To: "Drumm, Daniel" <dgdrumm@xxxxxxxxxxxx>
- Subject: Re: Cosign Multi-factor Authentication Spec
- From: Wesley Craig <wes@xxxxxxxxx>
- Date: Tue, 11 Oct 2005 20:03:44 -0400
- Cc: "Carson, Cassandra" <clcarson@xxxxxxxxxxxx>, "Meyer, Seth" <smeyer@xxxxxxxxxxxx>, "Linderman, Mark" <mlinderm@xxxxxxxxxxxx>, "cosign-discuss Discussion" <cosign-discuss@xxxxxxxxx>, <mais.twofact.tech@xxxxxxxxx>, "Dandamudi, Bindu" <bdandamu@xxxxxxxxxxxx>, "Thomas, Katarina" <kkit@xxxxxxxxxxxx>
- In-reply-to: <27AE62311E924149926D0A0B86ED548701110AAA@bf-it-equinox02.bf.umich.edu>
- References: <27AE62311E924149926D0A0B86ED548701110AAA@bf-it-equinox02.bf.umich.edu>
On 11 Oct 2005, at 16:39, Drumm, Daniel wrote:
Seth mentioned the futility of passing a "OTP=BOGUS" name/value pair
back in the query string from weblogin. It informs the referring
filter
that the OTP validation wasn't "real", but there is no way of
informing
any further websites of that fact.
There seems to be some confusion, here.
Nothing like OTP=BOGUS is passed on any query string. A protected
application might pass "factors=OTP" on the query string. The UI
would present OTP as a requirement. The PAM implementation in the
spec is sensitive to the return value "user_unknown", and appends
some string ("-junk" in the example in the spec) to the factor. The
browser would then be redirected back to whatever URL the application
gave as "referring-url".
Back in the application, the filter gets back from the server which
factors, if any, have succeeded. One such factor might be "OTP-
junk". The filter may have the option "CosignIgnoreFactorSuffix" set
to "-junk", in which case "OTP-junk" and "OTP" would seem to be
equivalent to the filter. If "CosignIgnoreFactorSuffix" wasn't set,
the filter is able to count "OTP-junk" and "OTP" as different.
:wes
|
|
