[CalendarServer-users] Errors with group based access control
Frank Strauß
strauss at ibr.cs.tu-bs.de
Fri Dec 15 02:10:47 PST 2006
Wilfredo Sánchez Vega wrote:
> Just FYI-
>
> The server on trunk no longer uses the CalendarPrincipalURI attribute
> on users, groups, and resources; all records are presently provisioned
> regardless of whether this attribute or present or not.
>
> The reason for this is that we are going to implement a new directory
> schema, which is still in the works. We found that having the server
> host name in the user records was kind weak, because if you change the
> host name, you have to update all of your user records. So we'll be
> using some intermediate record type to store server access information
> and point the user records at that.
I'm not sure whether such an indirection would really make life easier.
If some LDAP client wants to get information on a user, this information
is usually available by a request on the user's LDAP entry, and that's all.
For example, if I want to get Frank's email address, I request the
attribute "email" from my entry on our LDAP server and get back
"strauss at ibr.cs.tu-bs.de". That's it. It's not that I just get "strauss"
and a pointer to another piece of information that will tell me that our
institute currently has the email domain name "ibr.cs.tu-bs.de". The
domain name is a kind of information that is hopefully well chosen when
it was introduced and that changes very very rarely. So the benefit of
easy access to the full email address is more important than an easy way
to change it sometime in the future. And even _if_ we would have to
change it, a simple script would do the job easily in the LDAP database.
All the places out there where this information is already stored cannot
be changed, anyway.
I think the same holds true for calendar principal URIs. I would prefer
to add a note to the server documentation that the CalDAV server name
should be well chosen (e.g., a "role name" like cal.ibr.cs.tu-bs.de, not
the canonical host name) and keep the directory schema simple as it is now.
Just my $.02
PS: Just curious: Are there counter examples where such a kind of
indirection is already modeled in LDAP schemas?
More information about the calendarserver-users
mailing list