Thanks Brian, I hope you had a restful vacation! Do you know what the
package name will be? I assume, then, you will not be checking the code into the
xrootd.org repo named xrootd-macaroons (
https://github.com/xrootd/xrootd-macaroons),
right?
As for API changes, now is the time to explore them as we are heading tnto
R5 territory where we can break ABI’s. From what I can see, it would be good to
have fields in the XrdSecEntity structure where you could point to the macaroon
and it’s length. Likely the same problem for SciTokens, though that one would be
just as easy to pass via a CGI element that avoids the whole problem in the
first place. Thought?
Andy
Sent: Monday, July 02, 2018 9:42 AM
Subject: Re: Macaroons support for XrdHttp
Hi
Andy,
(Back from vacation today... apologies if you get many rapid-fire
emails...)
Indeed, I'm planning on doing this prior to the first release.
Because the macaroons are short-lived and only valid for the local site storage
system, it's a bit easier to evolve the claims than in SciTokens (which must be
understood by multiple storage systems, all on their own release cycle).
Note that I just pushed libmacaroons to be scheduled for the next EPEL7 and
Fedora 28 release. That means this code's dependencies should be
resolvable for those platforms (one of the conditions Andy set out in his
original email below). For me, getting this into the base xrootd install
would ease any future pain of coordinating API changes within Xrootd itself --
no need to manage more complex sets of compatible versions, since we only have
to target a single version!
Thoughts?
Brian
Actually,
it would be good if the macaroon contained UID/GID (or whatever you consider
describing ownership) from the get go -- even if it is not used for certain
system. These things evolve quickly and I don't think it would be good to
constrain the evolution simply because we don't have enough information.
Putting this in after the fact is usually far more problematic than one
initially assumes.AndyOn
Wed, 20 Jun 2018, Brian Bockelman wrote:
Hi Andreas,
dCache currently embeds the UID / GID(s) of
the original entity that generated the token into the token
itself.
XRootD does not really have a concept of "file ownership"
(authorization module is completely separated from the filesystem module),
so I don't currently include this in the XRootD-generated
macaroon.
As I've been trying out a few use cases locally (locally,
XRootD sits on top of HDFS which, like EOS, does have file ownership), I'm
hitting ownership issues like you outline below. I think the
XRootD-generated token is going to include the user and group info too for
the case where XRootD is sitting on top of distributed
filesystems.
Brian
On Jun 20, 2018, at 7:33 AM, Andreas-Joachim
Peters <[log in to unmask]>
wrote:
I have one question if you use macaroons for writing. If I
allow with a macaroon to write into 'my' directory, will a file be created
with my identity or the identity of the authenticated client with the
macaroon? Or is the identity for creatoin also specified in the macaroon?
Reading is clear.
Cheers Andreas.
On Wed, Jun 20, 2018
at 1:58 PM, Fabrizio Furano <[log in to unmask] <mailto:[log in to unmask]>>
wrote:
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 <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 <https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1>
########################################################################Use
REPLY-ALL to reply to listTo
unsubscribe from the XROOTD-DEV list, click the following link:https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1