 |
 |
Hi Fabrizio, On 20/06/18 10:34, Fabrizio Furano wrote: > slightly OT, may I know what are the actual desiderata for > a macaroon-based system ? I think different people will answer this differently. For me, the initial stimulus was to solve the "web portal" problem. How does a web-portal authorise direct client-storage interaction? Ideally each token may be strongly limited (reducing damage if stolen), is fast, supports autonomous delegation with attenuation, and doesn't create state on the server. Macaroons could also be used elsewhere, though; for example, a macaroon could allow users to share non-public data with other people who are unknown to the storage system. Another interesting use-case is to delegate authz decisions to catalogues. As a concrete example, Rucio has a permission model that authorises activity of ATLAS members. However, that is independent of the authorisation in the storage system. With macaroons, it is possible to enforce the Rucio security model by the storage system only allowing the Rucio server direct access, and ATLAS members obtaining macaroons from Rucio for their direct storage interaction. This is broadly similar to the ALICE model. There's also HTTP 3rd-party copy. A macaroon is quite a convenient way of delegating authorisation. The client fetches a macaroon from one endpoint and hands this to the other endpoint during the COPY request. The macaroon is then used to authorise the corresponding GET/PUT request. I'm pretty sure there are other potential uses -- macaroons are quite a convenient "building block" for higher-level services. > As I was mentioning, DPM has the macaroons code in the > frontend (disabled by default), yet we consider it experimental. From which DPM version is experimental macaroon support available? > Which authentication/authorization criteria may have to > be applied to generate a macaroon? What does dCache do for example? In dCache, anyone can request a macaroon and it is enabled by default, because: 1. generating a macaroon doesn't takes up any server state(*), 2. doesn't grant the user any additional permissions, 3. dCache ensures all macaroons expire (1 day, by default). A macaroon may be attenuated, by adding caveats: either as described in the macaroon minting request, or by the client autonomously. dCache supports six types of caveats, which limit what activity is allowed, against which part of the namespace, from which IP address requests are accepted, the caveat's validity, etc. If you would like more information on these caveats, see: https://www.dcache.org/manuals/workshop-2017-05-29-Umea/000-Final/anupam_macaroons_v02.pdf HTH, Paul. (*) -- This is once the server-side secret has been generate. Secrets have a lifetime and are rotating out once they expire. In general, many macaroons use the same secret, so creating an additional macaroon generates no additional server-state. ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1