Missing concrete configuration details/examples for WLCG/IAM tokens

[paulmillar]

The current gplazma documentation is insufficient to understand how to configure dCache to support tokens.

In addition, example configuration that shows how to configure dCache to work with Indigo-IAM-issued WLCG profile would be helpful.

[vokac]

Very basic documentation for oidc plugin is available, but it doesn't really describe all details and configuration options that must be used for real storage with token support configuration. Also storage-authzdb could be replaced with multimap and omnisession plugins...

[paulmillar]

Just an update here.

I think the gPlazma documentation is a little, err, "conflicted" at the moment.

A general philosophy is that "The Book" would contain (amongst other things) three kinds of material:

• reference material, providing exhaustive description of a service but without a broader context,
• overarching concepts, features of dCache that (typically) span multiple services,
• cookbook examples, providing starting points for real-world scenarios.

I think this documentation is currently more the cookbook-style documentation. It is good that this exists, but could (still) be improved.

it doesn't really describe all details and configuration options [...]

On a related note, I recently added the reference documentation for the oidc plugin. It is available under the plugins section, here. This is a first version (and currently only available in v9.2 documentation); the text may not be perfect, but (again) it's hopefully a reasonable starting point.

Also storage-authzdb could be replaced with multimap and omnisession plugins

I agree. This is (personally) a long-term goal to get rid of storage-authzdb, but I think we may need some support scripts to handle migrating sites before we can drop the gPlazma plugin altogether. In any case, I would say this topic should be recorded as a different issue.

[vokac]

Thanks, I missed new oidc plugin reference, looks good and provides a quicker overview of plugin configuration than my previous method of studying source code.

You already wrote stoarge-authzdb to omnisession migration script and if I ignore issue that it is currently impossible to specify target omnisession file https://github.com/dCache/dcache/blob/e80d893e69fa6698857d694826589cddcf5eb451/skel/sbin/dcache-convert-authzdb-to-omnisession#L69-L71 (second parameter should use $2 and not $1) this seems to me usable for session authzdb -> session omnisession. It should not be very difficult to have something similar for map authzdb -> map multimap. Unfortunately it's too late with these changes for ongoing/upcoming token reconfiguration campaign.

[paulmillar]

Thanks for reporting the problem with the migration script. I've created a separate issue to track the progress on fixing this.

The work on that migration script largely stalled due to a lack of testing: I didn't want to recommend something that I hadn't properly verified worked correct. If you (@vokac ) were able to help with the testing the script then I think we can make progress in migrating people away from using the authzdb plugin.