CoSign: Collaborative Single Sign-On  
AnnouncementsDiscussion
 

cosign-discuss at umich.edu
general discussion of cosign development and deployment
 

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

Accessing secure sites



Our Cosign requirement was for a Reduced Sign-On solution rather than 
full Single Sign-on.  We always envisaged that there would be 
service providers who would want to take particular care with their 
service authentication.  We are now trying to address that 
requirement.

For example, our finance site is quite happy for an authenticated
user to read various records, but would like to be more certain of the
user before providing write capability for certain fields.  The
concern is, for example, that a PC has been left idle and the session
hijacked by someone else in the orignators absence.  They would like a 
limited time, explicitly autheticated access for this function.

Rather than the application writer again having to implement a local 
password solution for their application, it would be useful if we 
could provide a further challenge centrally, requiring the same 
password for the same user.  Something like a specific 
short-life service cookie that required explicit authentication to 
renew.

Do you have any similar requirements in Michigan and if so, how have 
you addressed them?

  Keith Farvis
--
Manager of Unix and Facilities Management Team
Edinburgh University Computing Services


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