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