HTCondor Workshop Autumn 2020

[Basney, Jim]

Hi,

If you're attending the HTCondor Workshop this week (registration is free & still open), please join my session on "From Identity-Based Authorization to Capabilities: SciTokens, JWTs, and OAuth" on Friday at 11am ET (https://indico.cern.ch/event/936993/contributions/4020913/) followed by Jason and Zach presenting on "Allow HTCondor jobs to securely access services via OAuth token workflow" (https://indico.cern.ch/event/936993/contributions/4022103/). Plus there's other interesting sessions all week!

-Jim

[Paul Millar]

Hi Jim,

My apologies for the delay reply -- I was off on holiday last week.

Unfortunately, I was unable to attend the sessions, but I hope they went
well.

One topic that might have turned up is about how jobs running within
HTCondor might access services.

Aside from Jason and Zach's work, one option might be to provide the job
with the SciToken (if any) used to create the job. I believe this is
(roughly) what is shown on slide 17 of your presentation, with the job
interacting with a data server.

I was wondering if you would be interested in including dCache as a demo
service that supports SciTokens?

Currently, there are a few dCache instances that trust the
"https://scitokens.org/dteam" issuer to identify members of the DTEAM VO.

I believe it would be possible to extend this to support for some other
SciToken issuer (perhaps "https://demo.scitokens.org") on
prometheus.desy.de. This would allow easy demonstrations of this
job-storage interaction working with real-world services.

Cheers,
Paul.

[Basney, Jim]

Hi Paul,

> Unfortunately, I was unable to attend the sessions, but I hope they went
> well.

Thanks!

> One topic that might have turned up is about how jobs running within
> HTCondor might access services.
>
> Aside from Jason and Zach's work, one option might be to provide the job
> with the SciToken (if any) used to create the job. I believe this is
> (roughly) what is shown on slide 17 of your presentation, with the job
> interacting with a data server.

We didn't have time for an HTCondor SciTokens demo at the workshop last week. Jason's presentation (https://indico.cern.ch/event/936993/contributions/4022103/) focused on the example of submitting a job that accesses box.com storage, which demonstrates the HTCondor OAuth mechanism that we also use with SciTokens. For prior demos we've shown HTCondor jobs accessing StashCache, XrootD, and CVMFS storage.

> I was wondering if you would be interested in including dCache as a demo
> service that supports SciTokens?

Yes! I'm aware of the dCache-SciTokens interop work, but I've neglected to put anything about it on https://scitokens.org/. Is https://dcache.org/old/manuals/UserGuide-6.0/webdav.shtml a good reference on dCache's SciTokens support that I could link to?

> Currently, there are a few dCache instances that trust the
> "https://scitokens.org/dteam" issuer to identify members of the DTEAM VO.
>
> I believe it would be possible to extend this to support for some other
> SciToken issuer (perhaps "https://demo.scitokens.org") on
> prometheus.desy.de. This would allow easy demonstrations of this
> job-storage interaction working with real-world services.

Yes, that'd be great -- so people would be able to get a token from https://demo.scitokens.org and read something from prometheus.desy.de. Presumably you wouldn't want to allow writes, since there's no restriction on who can get tokens from https://demo.scitokens.org.

https://demo.scitokens.org/.well-known/openid-configuration should contain what you need to allow tokens from the https://demo.scitokens.org issuer. We could add a link to https://scitokens.org and https://demo.scitokens.org with instructions on using the token with prometheus.desy.de (i.e., what the token payload should be set to). Maybe add another button for "set payload for access to dCache demo".

The source for the https://demo.scitokens.org site is at https://github.com/scitokens/scitokens-heroku. While we're at it, we should update the demo to match the current SciTokens specification (i.e., "scope" instead of "scp").

Once that's all working, we could work on a dCache-SciTokens demo that also involves HTCondor.

Regards,
Jim

[Paul Millar]

Hi Jim,

On 29/09/2020 15:53, Basney, Jim wrote:
[...]

>> I was wondering if you would be interested in including dCache as a demo
>> service that supports SciTokens?
>
> Yes! I'm aware of the dCache-SciTokens interop work, but I've neglected to put anything about it on https://scitokens.org/.


> Is https://dcache.org/old/manuals/UserGuide-6.0/webdav.shtml a good
> reference on dCache's SciTokens support that I could link to?

Hmmm, this is currently a little tricky.

dCache has supported SciTokens since dCache v5.1. However, I'd be
tempted to suggest that you point to the latest version of the
UserGuide, as the guide is (unfortunately) updated only in fits and
starts and most changes are not back-ported.

The latest version of dCache is v6.2, so the latest version would be
https://dcache.org/old/manuals/UserGuide-6.2/webdav.shtml.
Unfortunately, we don't have a 'latest' User-Guide link.

Also, the User Guide should include a chapter focusing on SciTokens in
general, since they are a protocol-agnostic concept. This is especially
true given that we support SciToken authentication for xrootd with
dCache v6.2, and the next major version of dCache (v7.0) will support
using SciTokens when making SRM requests.

So, I think the WebDAV link is fine for now (thanks), but I hope we can
provide a better link in the future.


[...]

> Yes, that'd be great -- so people would be able to get a token from
> https://demo.scitokens.org and read something from
> prometheus.desy.de. Presumably you wouldn't want to allow writes,
> since there's no restriction on who can get tokens from
> https://demo.scitokens.org.

I should be able to rig together something like that.

The prometheus machine is wiped and rebuilt every day, so I'm fairly
liberal in handing out access, but I think I would draw the line with
allowing write access to demo.scitokens.org because, as you say, anyone
can get a token.

I think allowing write access would be no problem if the OP was backed
by, say, CI-Login based authentication.

> https://demo.scitokens.org/.well-known/openid-configuration should
> contain what you need to allow tokens from the
> https://demo.scitokens.org issuer. We could add a link to
> https://scitokens.org and https://demo.scitokens.org with
> instructions on using the token with prometheus.desy.de (i.e., what
> the token payload should be set to). Maybe add another button for
> "set payload for access to dCache demo".

Thanks, something like that would be good.

On prometheus (when rebuilt) contains a default directory structure,
which includes both public files and private files: ones that only the
VO can read. There is also a private directory, that only members of
that VO can list.

So, it might make sense to provide a couple of buttons (or something
similar) that would select the correct scopes to authorise reading a
specific private file (but nothing else), or that would allow access to
the private directory.

> The source for the https://demo.scitokens.org site is at
> https://github.com/scitokens/scitokens-heroku. While we're at it, we
> should update the demo to match the current SciTokens specification
> (i.e., "scope" instead of "scp").

Ah, unfortunately that's a bit of a problem.

dCache currently only looks at the "scope" claim. It ignores any "scp"
claim.

(Technically, I could add support for "scp", but I believe this claim
isn't part of the SciToken documentation any more.)

On the web-page, I can manually change the JWT payload so the demo
server asserts "scope" rather than "scp", but someone who would like to
"just try it" is unlikely to know they should do that.

So, would it be possible to update demo.scitokens.org so that is uses
the "scope" claim by default?

(Also, isn't "scp" claim value meant to be a JSON array of JSON Strings?
In demo.scitokens.org, the default has the "scp" claim as a JSON String,
which looks wrong.)

> Once that's all working, we could work on a dCache-SciTokens demo
> that also involves HTCondor.

That would be great.

Cheers,
Paul.

[Basney, Jim]

Hi Paul,

> So, I think the WebDAV link is fine for now (thanks), but I hope we can
> provide a better link in the future.

OK I've added the dCache link on https://scitokens.org/.

> I think allowing write access would be no problem if the OP was backed
> by, say, CI-Login based authentication.

Sounds good. We're very close to adding SciTokens issuance on https://demo.cilogon.org/.

> So, would it be possible to update demo.scitokens.org so that is uses
> the "scope" claim by default?

Yes. I submitted a pull request for Derek's review:
https://github.com/scitokens/scitokens-heroku/pull/3

Regards,
Jim

[Paul Millar]

Hi Jim,

I've updated https://prometheus.desy.de/ so that it now accepts
SciTokens issued by https://demo.scitoken.org

There is a dedicated area /VOs/demo-scitoken for these users:

https://prometheus.desy.de/VOs/demo-scitoken

In keeping with other VO areas, there is a public file that anyone ca
read, a private file that only members of the VO can read, and a Private
directory (with a demo file) that only members of the VO can "enter".

The endpoint accepts WebDAV requests, and the directory generates some
(rudimentary) HTML, that allows web-browser based navigation and file
download/viewing.

In addition to specifying the token in the Authorization request header,
you can embed a bearer token in the URL; e.g.,

https://prometheus.desy.de/?authz=<SciToken>

This allows web-browser based exploration with a SciToken.

If you want to explore WebDAV more, I can recommend rclone. This has
support for bearer token authentication:

https://rclone.org/webdav/

The documentation talks about macaroons, but the same support should
also work with SciTokens.


A few things to note:

1. dCache rejects a SciToken if the JWT doesn't contain any "scope" claim.

By default, the https://demo.scitokens.org/ page generates a token
without any "scope" claim. Therefore, this is currently "broken" (for
dCache) and requires the user to add a "scope" claim.


2. dCache adds the "/VOs/demo-scitoken" prefix to the scope claim.

So, a scope like "read:/" will work fine, but only allow read access to
/VOs/demo-scitoken directory.


3. dCache defaults to anonymous access if the SciToken is rejected.

This is potentially confusing, as things like directory listing will
work (in some cases) as the anonymous user. It's something I'll take a
look at when I get a spare moment.


4. Adding a "scope" claim will limit the directory listing.

For example, a token with "scope" claim "read:/private-file" will see
only the file /VOs/demo-dcache/private-file (and the parent directories)
and nothing else.


5. Support is read-only for now

As we discussed, the demo-scitokens account has read-only access for
now. We can enable uploading data once the CI-Login support is working.

On 02/10/2020 22:41, Basney, Jim wrote:
>> So, I think the WebDAV link is fine for now (thanks), but I hope we can
>> provide a better link in the future.
>
> OK I've added the dCache link on https://scitokens.org/.

Thanks.

>> I think allowing write access would be no problem if the OP was backed
>> by, say, CI-Login based authentication.
>
> Sounds good. We're very close to adding SciTokens issuance on https://demo.cilogon.org/.

Would this be by adding a LoA claims within the JWT (perhaps following
REFEDS), or by removing the possibility of obtaining a SciToken anonymously?

>> So, would it be possible to update demo.scitokens.org so that is uses
>> the "scope" claim by default?
>
> Yes. I submitted a pull request for Derek's review:
> https://github.com/scitokens/scitokens-heroku/pull/3

Thanks.

Paul.

[Derek Weitzel]

Hi Paul,

Could we work on a full token that would allow access?  Then I could add a “button” to generate the correct token.

What is the required ‘aud’ for these tokens?

What I have so far:

“scope”: “read:/“,

“aud”: <unknown>

The curl command needs to end with "/VOs/demo-scitoken"

-Derek

--
You received this message because you are subscribed to the Google Groups "SciTokens Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss+u...@scitokens.org.
To view this discussion on the web visit https://groups.google.com/a/scitokens.org/d/msgid/discuss/ad27d148-f080-3a23-2ca3-9c6c1555748d%40desy.de.

[Paul Millar]

Hi Derek,

On 05/10/2020 16:18, Derek Weitzel wrote:
> Could we work on a full token that would allow access?  Then I could add
> a “button” to generate the correct token.

OK.

> What is the required ‘aud’ for these tokens?

To be accepted, a token must either leave out the "aud" claim altogether
(a non-targeted token) or have an "aud" claim with a value from
{"https://wlcg.cern.ch/jwt/v1/any", "https://prometheus.desy.de:2443",
"https://prometheus.desy.de"}.

I'd say "https://prometheus.desy.de" would be a good fit, here.

That said, it's trivial to configure dCache so it will accept additional
"aud" claim values, so just let me know if you'd like a different value.

> What I have so far:
> “scope”: “read:/“,
> “aud”: <unknown>
>
> The curl command needs to end with "/VOs/demo-scitoken"

Providing the curl command is certainly a good option.

You might like to also provide a downloadable rclone configuration file,
and a direct link (for web browsing).

(There is at least one dCache site that uses rclone configuration files
as a way of encapsulating bearer tokens for their end-users.)

You could also provide different scopes (for example, in a drop-down
box), so people could explore how the system reacts.

Off the top of my head, I think these scopes might be of interest:


"read:/"
"read:/private-file"
"read:/Private"


Note that the curl command should include the "-L" option, as dCache
uses redirection by default, but otherwise should be pretty
straight-forward; e.g,.


curl -L -H "Authorization: Bearer <SciToken>"
https://prometheus.desy.de/VOs/demo-scitokens/private-file


The direct access (allowing the user to explore the contents) would have
the SciToken embedded in the URL; e.g.,


https://prometheus.desy.de/VOs/demo-scitokens?authz=<SciToken>

HTH,
Paul.