[dev] External access tickets
lang at b1-systems.de
Mon Mar 11 07:43:26 UTC 2019
Am 10.03.19 um 23:58 schrieb Michael J Rubinsky:
> Quoting Ralf Lang <lang at b1-systems.de>:
>> I need to provide throwaway access to some shared resources in a
>> horde_shares based application.
>> This means, the subject to grant access to will not be a horde user, but
>> access will not be granted globally.
>> Think of a scenario where you want to give - potentially time-limited,
>> revokable - access to a calendar, addressbook, file or similar resource
>> to an external party.
>> Strategies to implement
>> - Have an application specific table with some auth string, related
>> resource ID, expiry date
>> - Make this a feature of Horde_Shares (separate table
>> - Make this a feature of the RPC/Rest/access stack.
>> What would make most sense / have a chance for committing back into
>> - have a separate vhost with a separate auth table/source but shared
>> application/resource tables.
> Is the idea to grant API access only, or full UI access?
> I'm not sure the Horde_Shares strategy would work, though I honestly
> like that as an idea the best. How would we be authenticated to the
> actual application?
> It would be great if we could use this as a basis for a full
> role-based authentication and claims system.
for the downstream use case, it would be only API access
(read/download). Thus, a separate endpoint (similar to rampage.php but
with auth disabled) to serve the resource matching to the ticket string
or http auth header.
I think at some point in the past we had something like an embeddable
calendar widget which used an embed token. I don't remember using it though.
Thinking about it a bit more, this problem is a bit similar to the rest
poc where I also delegate auth and permission checks to a pre filter
class before the actual request handling.
Linux Consultant / Developer
Mail: lang at b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
More information about the dev