Hi,

On 20.06.18 12:56, Paul Millar wrote:
> Hi Fabrizio,
>
> On 20/06/18 11:48, Fabrizio Furano wrote:
>>   Paul, surely it's available in DPM 1.10 (latest in epel)
>
> Excellent.
>
> Could you say which option needs tweaking in order to enable the support?
>
> The DPM v1.10 release notes don't seem to mention macaroons much.

 indeed, we don't consider them a released feature ready for
prime time. Eventually they will.

 To enable then, one needs to make sure that the Apache config
contains:
 - (in the Location match for /dpm) NSMacaroonSecret <secret>
 - SSLVerifyClient must be "optional"

Cheers
Fabrizio

>
>>   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.
>
> :-D
>
>>   About the authentication, I take the statement "every authenticated
>> client",
>> which in our world may mean X509, X509/VOMS
>
> Yes, it includes X.509.  For dCache, this is also true for
> OpenID-Connect, Kerberos, username+password and macaroons.
>
> (You can even use a macaroon when requesting a fresh macaroon.)
>
> I'm working on adding SciToken support now.
>
>>   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?
>
> Yes, beyond a global enable/disable switch.
>
> The CPU cost of generating a macaroon is rather trivial.
>
> In the Birgisson et al paper, they measured the crypo overhead of
> minting a macaroon (in Python) at 20 µs, plus 55 µs per caveat.  For
> comparison they measured RSA keygen (as used by SciToken) as taking 54
> ms (54000 µs) in OpenSSL.  So a typical macaroon is about two orders of
> magnitude faster to generate than an RSA key-pair.
>
> There's no problem with multiple requests filling up any storage:
> typically macaroons share the same secret.
>
> It doesn't authorise users to do anything they can't already do,
> especially with X.509 proxies.
>
> For example, consider a user that generates and emails a friend a
> macaroon that grants the bearer the ability to read some data.
>
> That user could email their friend an X.509 proxy.
>
> Failing that, they could even download the data and simply email it to
> their friend.
>
> At least with macaroons, the user can limit activity to reading data (no
> deletion) and only a specific portion of the namespace.
>
>>   For the records, the DPM implementation is considered experimental
>> because it may miss something... however it's good to gain experience.
>
> Agreed.
>
> Cheers,
>
> Paul.



########################################################################
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