RE: Cosign Multi-factor Authentication Spec

["Meyer, Seth" <smeyer@xxxxxxxxxxxx>]

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.

Seth 

-----Original Message-----
From: Wesley Craig [mailto:wes@xxxxxxxxx] 
Sent: Tuesday, October 11, 2005 11:23 AM
To: Linderman, Mark
Cc: cosign-discuss Discussion; mais.twofact.tech@xxxxxxxxx; Dandamudi,
Bindu; Thomas, Katarina
Subject: Re: Cosign Multi-factor Authentication Spec

On 11 Oct 2005, at 09:22, Linderman, Mark wrote:
> I'm not finding anything in the spec about the ability to selectively 
> multi-factor protect individual url-patterns within a single filtered 
> resource.  For example, we use a single instance of the Java cosign 
> filter to protect a suite of Peoplesoft applications, only some of 
> which we'd like to multi-factor protect.  The rest would continue to 
> require only a single factor.  Should I assume this would require as 
> many filter instances as there are url-patterns with different 
> security requirements?

No.  I think you're referring to the possible bug in the Java filter
that you have previously reported?  If so, I don't think that's germane
to the multi-factor discussion.

> It would be nice to see the multi-factor capability extended to re- 
> auth.
> Our re-authenticated resources are not really distinct from the rest 
> of our application content.  As mentioned above, we'll turn on multi- 
> factor for some of that content and would like to be able to 
> re-authenticate for certain sub-components with the same factors used 
> to authenticate.

It's not currently spec'd that way because re-auth must be configured
centrally, while multi-factor is configured in the filters.  It's not
possible to mix central & filter configurations in the way that you
describe.  Instead, the capability you describe would require much more
to be configured centrally.

:wes