 |
 |
Hi Brian, true, macaroons are implemented by DPM and dcache. Having them also in xrootd would be great. About the distribution, my personal preference is to have these things handy to install and clean on the source tree, so I'd love to see macaroons and scitokens in the Xrd codebase, respecting all the strict project rules about makefiles (e.g. turning off the component) and deps. What did you do for libmacaroons? Since it's not distributed, we build it with DPM so far. Are you doing the same? Maybe we want to find a volunteer packager that submits it to epel/debian, etc. and only then refine the details of a build with Xrd ? Fabrizio On 06/13/2018 04:08 PM, Brian Bockelman wrote: > Hi, > > I have an initial (but functioning) support for Macaroons in Xrootd: > > https://github.com/bbockelm/xrootd-macaroons > > Macaroons are a symmetric-key-based token format. It allows an entity with access to the secret key generate a bearer token > embedding one more "caveats" (rules for usage, such as restrictions on path, expiration time, or valid operations). The bearer > of the token can add additional caveats (reducing permission) but doesn't have the ability to remove them. > > Anyone else with the secret key (such as the same host or another host in the cluster) can then verify the token as apply the > authorization rules in the caveats. > > Why is this useful? A few cases: > > 1. Delegating fine-grained access: Rucio generates a token to access a single file at a site (using its X509 client cert to > authenticate), then sends the token to an end-user. Hence, the end-user doesn't need to authenticate with the site (no user > X509 necessary) in order to download files. The VO (ATLAS, via Rucio) can manage the fine-grained rights they delegate to the > user -- even if the storage is run by the site. > > 2. Enabling third-party-copy: If client C wants server A to download from server B, the client can contact server B for a > fine-grained access token and provide it to server A as part of the HTTP COPY request. > - I suspect I'll get the first FTS3-based transfers working today. > > IIUC, Macaroons are implemented by dCache and DPM. I utilized the same caveat formats and API for requesting new tokens, but > generally one would not expect tokens to be reusable across different implementations or site installations. > > Currently, the token is generated via a XrdHttp plugin but should be usable throughout the authorization framework; however, you > need an encrypted channel between client and server to use it safely. > > The obvious question is "how does this differ from SciTokens"? > - SciTokens are based on asymmetric (public key) cryptography whereas Macaroons are symmetric key. This means anyone can verify > a SciToken but only the issuing entity can verify a Macaroon. > - In the SciTokens model, the VO issues the authorization, which may be valid across many sites. The macaroon is specific to > the site and requires an interaction with the site to generate. > - Macaroons can be attenuated (made weaker) by the end-user. I can take a powerful macaroon and add additional limitations > without contacting a third-party, then safely give the limited macaroon to another person if I desire. SciTokens can only be > attenuated by contacting the VO to exchange the powerful one for a new one (hence, the VO always generates the token). > > Just as one uses a mix of asymmetric and symmetric cryptography throughout the course of the day, I see SciTokens and Macaroons > as complementary approaches, each enabling some distinct and some common use cases. > > So - one natural question for me is whether this better lives inside the xrootd repository or standalone. Unlike SciTokens, the > dependency stack for Macaroons is more manageable (a direct dependency on libmacaroons - https://github.com/rescrv/libmacaroons > - and an indirect dependency on libbsd). This means upstreaming of the macaroons code is more approachable than the SciTokens > code. Additionally, since the code includes both an issuer and a verifier, Macaroons are more immediately usable - no > non-Xrootd services setup. > > Accordingly, I'm leaning to converting this into a module inside the xrootd repository. > > Thoughts? > > Brian > > -------------------------------------------------------------------------------------------------------------------------------- > > 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 > ######################################################################## 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