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