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: friend functionality
The simple answer is: guest accounts that aren't in (and probably
don't belong in) our Kerberos database.
As we were rolling out our weblogin service on Michigan's campus, we
discovered that one of the major sticking points with many departments
was the pre-existence in their systems of non-umich 'guest' accounts
that CoSign couldn't really account for. Some of these users had a
clear relationship with the University (vendor, visiting scholar, etc.)
that should have (and, in many cases, has) entitled them to a Kerberos
principal. There were, however, numerous levels of guest user who
didn't make sense to include in our campus SSO but who, nonetheless,
needed login accounts on web servers (e.g. young athletes visiting our
summer camps, research study participants, someone at a remote site
trying to download a single, private, large file, etc.).
Phil Ray, manager of IT services for UM's School of Natural Resources
and Environment, recommended to us that a centralized guest account
system would solve this problem while making the management of accounts
easier for campus admins and users alike. Now guest users create a
single account with a single password (that they set initially and can
reset or change later) and campus admins don't have to do any account
creation or management at all for them (although they still have to
handle AuthZ, of course).
Is this the kind of explanation you were hoping for?
On Mar 29, 2004, at 10:30 AM, Darren Jacobs wrote:
Don't have a lot of experience with webiso systems (yet <g> ) so
please excuse me if my question is a bit basic...what exactly does the
friend functionality of Cosign give you?
University of Toronto
... "In, as you say, the mud." ...