[Cosmo-dev] Understanding the Cosmo server side target users

[Brian Moseley]

On 8/29/06, Vinubalaji Gopal <vinu at osafoundation.org> wrote:

> >      +  External directory integration (LDAP, Kerberos (Apple has these)
> >            + Auth only, profile in Cosmo
>
> It will allow a end-user to use his existing setup, which means a user
> can just deploy Cosmo without adding any users in Cosmo. All the user
> authentication information will be part of an external LDAP or Kerberos
> server and Cosmo will query this external server.

more precisely, when a user logs into cosmo through the web ui or one
of the protocols, cosmo will ask the external directory to
authenticate the user rather than doing that itself. all the rest of
the user's info will still be in cosmo (perhaps copied manually or by
some tool from the directory).

> >            + Profile in the directory
> Does it include all the events, address book, resource associated with a
> user?

no, this means that the user's email address, name and so forth are no
longer copied in cosmo but only live in the directory. so the part of
the cosmo web ui that deals with user mgmt would have much less to do
(unless we made cosmo able to manage the user profiles in the
directory server, which i think we should stay away from).

> >      + Integration with single sign-on/digital ID
> >            + Shibboleth/SAML/Library
> >            + OpenID?
> A different form of security. Using this the end user may not register
> an account with Cosmo (similar to LDAP) and use a different centralized
> service for  authentication. Its in a way similar to LDAP
> authentication, but the authentication information is kept in a
> different domain. For eg: say a user has an account with Yahoo and he
> can use the same account information to login to a couple of websites.
> Each of the above spec provide a different kind of authentication
> mechanism and I am referring to one of them.

from a technical perspective, the main difference between these
scenarios and the external directory scenarios is that in this case,
the user does not even go to cosmo to log in. he logs into some other
service somewhere else and then comes to cosmo, which recognizes that
the user logged into some other place. there's more to it than that,
but that's the general gist of it.

> >      + Import existing data
> Backup solution.

much more than that. no existing caldav clients will allow you to
create a calendar on the server, so cosmo needs to give you a way to
do that. it also eases adoption by allowing people to migrate their
existing calendars from ical, outlook, google, what have you into
cosmo.