Authorization and shared calendars

[raboof]

Is there any infrastructure in place for specifying which users are
allowed to perform which actions?

I think it would be useful to be able to add users
- who cannot subscribe themselves to calendars
- who can read, but not write (some) calendars

The former could be implemented by
- allowing `superusers' to specify roles for users
- allowing `superusers' to add calendars to other users
- adding something like Wasp/Swarm or perhaps wicket-auth-roles to
enforce those rules

The latter by
- allowing `superusers' to modify other users' calendars
- adding a 'readonly' flag to calendars which only superusers can
modify

(eventually I can imagine the CalendarUser relation might have to
become a many-to-many, in that case I suppose the 'readonly' flag
should be on the CalendarUser relation instead of on the Calendar)


Arnout

[Ivo van Dongen]

Hi,

I can answer most of your questions with no I believe. In the initial
design of webical we excluded these matters to be able to use container
authentication mechanisms. There is only one exception; the system
administrator who has privileges to alter system wide configuration.

It would however surely be possible to add this to webical. But atm I
don't really see your use case. Could you explain as what you are trying
to accomplish?

On 11/30/08 10:57 PM, raboof wrote:
> I think it would be useful to be able to add users
> - who cannot subscribe themselves to calendars
>

Why would you want to restrict users to subscribe to calendars?

> - who can read, but not write (some) calendars
>

As the calendars are hosted externally and are not controlled by webical
you can restrict access at the webdav layer if you want.

I think that if you want to implement a strict access control in webical
you would need a bit of an overhaul of the current design. The reasoning
now is that all resources are controlled and regulated externally. This
has the advantage that webical can be extermely pluggable, but the
disadvantage that access control has to be implemented somewhere else.
One way to do this is to couple webical and your webdav server to a
central ldap server for authentication for example (this was our own
business case).

Thanks for your input, you're welcome to step in with more ideas if you
like.

Regards,
Ivo

[raboof]

Thanks for your quick replies

On Nov 30, 11:55 pm, Ivo van Dongen <ivovandon...@gmail.com> wrote:
> Atm I don't really see your use case. Could you explain as what you are trying
> to accomplish?

Basically, I'm considering using webical to publish information to
specific people (like communicating release schedules for various
products to our customers). This way, instead of mailing back and
forth various versions of the schedule, the latest version is
accessible to everyone in convenient formats.

Allowing (some) users to modify the calendar online is a nice extra,
and using java/wicket imho is an advantage over projects like
phpicalendar.

> > - who cannot subscribe themselves to calendars
>
> Why would you want to restrict users to subscribe to calendars?

Because the available calendars are not really public, and we don't
have authorization (yet) on the lower layers.

I guess this is a nice-to-have - in our case I think managing
authorization externally might be overkill, but as we trust our users
some degree of 'authorization by obscurity' might be acceptable.

> > - who can read, but not write (some) calendars
>
> As the calendars are hosted externally and are not controlled by webical
> you can restrict access at the webdav layer if you want.

In our case the calendars are not hosted externally - the point is to
(partially) expose our internal calendars :). Configuring the
authorization at the webdav layer might be an option, i'd have to take
a look at that.

If the logged-in user does not have write access to the selected
calendar, is that detected by webical? Of course UI for calendar
manipulation (pluses, 'add event...' etc) should disappear.

> I think that if you want to implement a strict access control in webical
> you would need a bit of an overhaul of the current design. The reasoning
> now is that all resources are controlled and regulated externally. This
> has the advantage that webical can be extermely pluggable, but the
> disadvantage that access control has to be implemented somewhere else.
> One way to do this is to couple webical and your webdav server to a
> central ldap server for authentication for example (this was our own
> business case).

While that's an elegant architecture that should certainly remain
supported, using an LDAP server seems rather heavyweight (no pun
intended) for our use case. I'll try and take a look what options are
available for doing the access control at the webdav layer.


Arnout

[Ivo van Dongen]

Hi Arnout,

>> Atm I don't really see your use case. Could you explain as what you are trying
>> to accomplish?
>>
>
> Basically, I'm considering using webical to publish information to
> specific people (like communicating release schedules for various
> products to our customers). This way, instead of mailing back and
> forth various versions of the schedule, the latest version is
> accessible to everyone in convenient formats.
>

Well, that's certainly a bit off from what we thought off when we
designed webical. Our design is a lot more like google calendar's where
a user manages his own account with his own calendars. If some of those
calendars happen to be shared among users that is fine. Actually webical
is even more seperated from the data source as it has no internal way of
specifying that a calendar is in fact a shared calendar.
If we are to support this we should reconsider our interface with the
calendar backends (caldav/webdav atm). There should be a way to change
the ACL to provide those services from within webical.

> Allowing (some) users to modify the calendar online is a nice extra,
> and using java/wicket imho is an advantage over projects like
> phpicalendar.
>

Do you have experience with wicket?

>
>>> - who cannot subscribe themselves to calendars
>>>
>> Why would you want to restrict users to subscribe to calendars?
>>
>
> Because the available calendars are not really public, and we don't
> have authorization (yet) on the lower layers.
>

That would be a show stopper yes :)

> I guess this is a nice-to-have - in our case I think managing
> authorization externally might be overkill, but as we trust our users
> some degree of 'authorization by obscurity' might be acceptable.
>

It can be acceptable. Although it is fairly easy to set up a
webdav/caldav (or any other http based) server to provide some means of
authentication and authorization. We've used simple servlet filters for
example in the past.

>
>>> - who can read, but not write (some) calendars
>>>
>> As the calendars are hosted externally and are not controlled by webical
>> you can restrict access at the webdav layer if you want.
>>
>
> In our case the calendars are not hosted externally - the point is to
> (partially) expose our internal calendars :). Configuring the
> authorization at the webdav layer might be an option, i'd have to take
> a look at that.
>

See my comment above. If you need help just let us know, perhaps I have
an example lying around somewhere.

> If the logged-in user does not have write access to the selected
> calendar, is that detected by webical? Of course UI for calendar
> manipulation (pluses, 'add event...' etc) should disappear.
>

Well, it's a manual setting atm. If you try to write to a calendar and
it is forbidden the user gets an error page. I don't know if the
calendar is set to read only automatically as in sunbird for example.

>
>> I think that if you want to implement a strict access control in webical
>> you would need a bit of an overhaul of the current design. The reasoning
>> now is that all resources are controlled and regulated externally. This
>> has the advantage that webical can be extermely pluggable, but the
>> disadvantage that access control has to be implemented somewhere else.
>> One way to do this is to couple webical and your webdav server to a
>> central ldap server for authentication for example (this was our own
>> business case).
>>
>
> While that's an elegant architecture that should certainly remain
> supported, using an LDAP server seems rather heavyweight (no pun
> intended) for our use case. I'll try and take a look what options are
> available for doing the access control at the webdav layer.
>

Well actually we use ldap for all the authentication, in webical as well
as the webdav layer. It's also possible to use flat files or a database
if you prefer.

Regards,
Ivo