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