 |
 |
Thank you Paul and Brian, Paul, surely it's available in DPM 1.10 (latest in epel) It may be available on slightly older DPMs if the sysadmin has upgraded the HTTP frontend alone (lcgdm-dav 0.20). Needless to say, I don't encourage package alchemies in prod setups. About the authentication, I take the statement "every authenticated client", which in our world may mean X509, X509/VOMS That was for generating. I am a bit puzzled about authorization. Really you don't apply any kind of authorization to generate a macaroon? Do you check everything only when a macaroon is received? For the records, the DPM implementation is considered experimental because it may miss something... however it's good to gain experience. Cheers Fabrizio On 06/20/2018 11:30 AM, Paul Millar wrote: > 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