[an error occurred while processing the directive]
![]() |
cosign-discuss at umich.edu |
general discussion of cosign development and deployment | |
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