Re: External access tickets
Ralf Lang <[email protected]> Mon, 11 Mar 2019 08:43:26 +0100
| Newsgroups | gmane.comp.horde.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Michael, Am 10.03.19 um 23:58 schrieb Michael J Rubinsky: > > Quoting Ralf Lang <[email protected]>: > >> 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: [email protected] B1 Systems GmbH Osterfeldstra=DFe 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- = dev mailing list Frequently Asked Questions: http://wiki.horde.org/FAQ To unsubscribe, mail: [email protected]