Re: Cosign Re-Authentication Specification

[Brett Lomas <b.lomas@xxxxxxxxxxxxxx>]

Jo

this is very cool, and is some the University of Auckland would be very
interested in also. One thing which might be nice (but is a larger
impact) is the ability for the filter to tell the cosign server to
reauthenticate (i.e. passing a reauth tag to the CGI, no registration
etc). This means the filter might then be able to force the user to
reauthenticate perhaps every 10 minutes to continue to access the
financial system etc? What do you think? Also the advantage of this is
it leads to forcing reauth for certain URLs in the application, like for
example in the finacials, to change the pay rate or something like that.
Thoughts?

Brett

On Fri, 2005-03-25 at 09:05, johanna bromberg craig wrote:
> Hey Cosign List,
> 
> We've been kicking around the idea that a specific Cosign service would 
> be able to force a re-authentication before allowing a user access to 
> that service. This has been suggested as a requirement by people in 
> both the financial and medical (HIPAA) arenas of the University of 
> Michigan.
> 
> Based on the conversation we had with some people in Michigan's 
> Administrative Information Services (MAIS) group on Friday, here's the 
> preliminary spec for how Re-Auth should work. We welcome comments, 
> suggestions, and questions from the entire Cosign community.
> -----------------
> 
> Setup ( to be done beforehand ):
> 
> A specific service name ( cosign-[servicename] ) registers with the 
> central cgi/daemon to assert that Re-Auth is required to access said 
> service. Other than that, there is no special configuration necessary 
> for the filters ( java/apache/iis ).
> 
> How it works:
> 
> Upon hitting a page protected by a servicename that is registered with 
> us as Re-Auth, the user will be redirected to the central cosign 
> server, where 1 of 2 things will happen.
> 
> 1) First Time (not logged in already):
> 
> If this is the first CosignProtected service they've visited during 
> their session ( aka they ARE NOT logged in ), they will be presented 
> with the normal login screen ( https://weblogin.umich.edu ), where they 
> will have as many opportunities to type their correct username and 
> password as they like. Upon correctly entering in a login/password 
> pair, they will be redirected back to the page they were previously 
> trying to access ( the one that required re-auth ) and the "time of 
> re-authentication" will be when the local copy of the service cookie is 
> created.
> 
> 2) Already logged in somewhere:
> 
> If the user has already accessed another CosignProtected service ( aka 
> they ARE logged in ), they will be redirected to the Re-Authentication 
> Page ( see https://cosign-test.www.umich.edu/reauth.html for a mock-up, 
> but don't type your password as this is not a real page! :) where they 
> will be prompted for the password of the user who is already 
> authenticated ( ie the login name will be a static field, as shown ). 
> They will then have N chances ( 3 is on the table, as may be other 
> numbers ) to correctly enter the password for that particular username. 
> If they fail after N attempts, they will be logged out of the central 
> Cosign server and all their sessions will be terminated. They will then 
> be brought to the N Strikes page ( see 
> https://cosign-test.www.umich.edu/3strikes.html, again merely a 
> suggestion, not the actual text ) where this will be explained and they 
> will have the opportunity to try again. Should they choose to try again 
> and are able to succeed, they will be redirected back to the original 
> referrer ( the servuce that required re-auth ).
> 
> Please send all comments to the list.
> 
> Thanks,
> Johanna and the Cosign Development Team
>