[dev] External access tickets

Ralf Lang lang at b1-systems.de
Mon Mar 11 07:43:26 UTC 2019


Hi Michael,

Am 10.03.19 um 23:58 schrieb Michael J Rubinsky:
>
> Quoting Ralf Lang <lang at b1-systems.de>:
>
>> Hallo,
>>
>> 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
>>
>> OR
>>
>> - Make this a feature of Horde_Shares (separate table
>> app_sharesng_tickets)
>>
>> OR
>>
>> - Make this a feature of the RPC/Rest/access stack.
>>
>> What would make most sense / have a chance for committing back into
>> Horde?
>>
>>
>>
>> Kludges/Workarounds
>>
>> - 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.
>
Hallo Michael,

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.


--
Ralf Lang

Linux Consultant / Developer
Tel.: +49-170-6381563
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 mailing list