storage.modify scope not honoured by scitokens-cpp

[andreaceccanti]

Hi,

while testing scope-based authz support in XRootD with @dciangot and @riccardodimaria we noticed that the scitokens library is not compliant with the WLCG profile. The storage.modify scope, in particular, is not honoured. Probably the cause of this is the following code:

scitokens-cpp/src/scitokens_internal.cpp

Line 583 in 746a79c

if (me->m_validate_profile == SciToken::Profile::COMPAT &&

There's no "storage.write" scope in the WLCG profile.

And probably this shows up only in compatibility mode, which is however used by default IIUC.

[andreaceccanti]

Hi @bbockelm, can you comment on this?

[andreaceccanti]

@bbockelm kind reminder.

[djw8605]

Hi, We are looking into this with the change in #30 . We are reviewing the change now.

[andreaceccanti]

Hi,
this is a blocker for the ESCAPE testbed.
Is there any progress?

[djw8605]

You are right, storage.modify is not honored. How would storage.modify be mapped to read/write? Should it be considered a "write" authorization?

[andreaceccanti]

You can see the precise definition on what's expected from storage.modify here:

https://github.com/WLCG-AuthZ-WG/CommonJWTProfile/blob/master/profile.md#capability-based-authorization-scope

[djw8605]

Right, I read the definition the other day as well. But I'm curious what the scitokens-cpp library should do? The library primarily translates from the WLCG token profile to the SciTokens profile. In this case, it would simply translate the storage.modify to write access. Does that sound correct to you? If that's the case, it should be a simple change to add storage.modify = (SciTokens) write.

[bbockelm]

@djw8605 - Xavi bumped me on this.

Indeed, I think we should just map WLCG's storage.modify -> write internally. Can you do the change and crank a release?

[djw8605]

Ok, can do. @andreaceccanti where do you get scitokens-cpp from? EPEL or OSG? EPEL has a bit of a delay due to testing and karma.

[riccardodimaria]

I personally get it from EPEL. Are you recommending to use OSG?

[djw8605]

Nope, EPEL is fine. I'll push the update this morning and reply here when it is done.

[andreaceccanti]

@djw8605 Typically EPEL, but a fast track OSG repo will work fine for our testbed, thanks!

[djw8605]

The builds are now in testing for EPEL:
EL8: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-34e9284c7a
EL7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-805503deaa

Please leave positive karma if it works for you.

[dciangot]

Hi, I can confirm that now everything works as expected. Thanks!