Extended AAI meeting

Wednesday 4 Jun 2025, 13:00 → 14:00 Europe/Berlin

Zoom connection:

Zoom ID 693 6852 8032
Kenncode 345442
Einladungslink https://desy.zoom.us/j/69368528032

 

participants:

- Kilian Schwarz

- Marcus Hardt

- Oliver Freyermuth

- Sander Apweiler

- Giovanni Pederiva

- Bjoen Hagemeier

- Uwe Jandt

- Bonoit Roland

- Hofer Laura

- Daniel Mallmann

- Huber Simma

 

Agenda:

TOP1: short introduction (Kilian)

we come together in order to discuss how to proceed with our PUNCH AAI from here on.

We will start with an introductory presentation by Oliver which will tell us the state of the art and what happened so far

and it will also outline possible paths into the future.

After that I hope that we will have a fruitful discussion and a good result which will guide us where to go.

 

TOP2: introductory presentation (Oliver)

Oliver shows slides

 

comments:

Scopes ==> Entitlements or EduPersonEntitlement

which should be the standard one

but this would require more adaption to the WLCG tools

how to do it upstream ?

This is more a comment, in the end it is based on the tools

WLCG needs to be convinced to support the "grand unifiying token"

 

why scope to be changed to a PUNCH specific one ?

if HGF operators agree, that we do storage.read:punch then we can do this

will that be accepted for compute by htcondor ?

htcondor might need to be tweaked

 

filter is available on the production instance of the AAI.

 

prefix for storage

may be misunderstanding

Sander is not against it, but there are other communities using this mechanism

it might be difficult to evaluate without further information if a person is authorised

2 or 3 other consortia are on Helmholtz AAI, not all of NFDI

other Helmholtz projects might be the issue

 

this is just a policy issue.

Since it is not used so far we can define a convention

 

storage part is not the problem

In compute part the extension does not exist

 

the service needs to understand

matter of trust relation between services and issuer

 

Entitlements are made for that, it has the name space 

but if this is the easier way this may be a way to go

 

in future maybe we will have the grand unified token scheme

Indigo puts authorisation into list of scopes

 

for compute part we have to look into the code of htcondor

==> token parsing library, needs to be checked 

reduces the amount of changes we have to do

storage.read:punch

would be the way to go

 

look at the issue is not enough if we have several NFDI instances

 

policy before or after AAI;

non standardised approach is not a bad idea

one could use the same interface on Variant A, also for B   

then we have both options

==> A) is the better choice to go

 

seems to be easy to configure

OPA ?

variant A is easier than B

For Unity is the same effort ==> then clearly variant A is the better way

we may not close the path

==> go for variant A without closing door for variant B

 

connection between unity and policy engine: API or token exchange ?

this is the opportunity to leave door open for variant B

We need a token exchange interface, which is RESTish 

we need a token exchange interface on policy engine behind AAI

or a user info, which might be simpler

 

why is version A not standardised ?

putting things in scope request and getting things back is not the standard in OAuth protocol

but Indigo IAM does it in a similar way

 

storage.read:punch

==> name identical as for the VO, which would be punch4nfdi

so then interchange is easier

 

nice would be /punch4nfi which we could do, this would be a logical file path

the path describes the object

this would allow destinction between different VOs to avoid overlap

The PATHs are not VO global unique since the name space is VO specific

we need to make it unique by VO

therefore the VO name  might be a good part of the virtual path

 

maybe issue as first thing in path, but issue might be the same for different communities

but fairmat and some other nfdi use plain helmholtz aai, have therefore same issuer

 

if we request desy services we would also go via helmholtz id and not punch issuer

 

with oidc agent they use also pre defined issuer

 

for HIFIS Storage dCache this is already done that the VO is part of the path

 

storage.read:/punch4nfdi

would be the way to go

 

maybe for htcondor the fix can be in the scitoken library

also there something can be issued for compute

they are open for extensions towards at+jwt tokens

 

 

TOP3: disussion   

see above

 

TOP4: conclusion

storage.read:/punch4nfdi

Policy Engine behind the AAI with possible interface for token exchange

 

see above

we create Indico

there we put minutes and slides

 

13:00 → 13:10 introduction

Speaker: Dr Kilian Schwarz (IT (IT Scientific Computing))

13:10 → 13:25 presentation

Speaker: Dr Oliver Freyermuth (University of Bonn (DE))

presentation-040625.pdf

13:25 → 13:45 discussion

13:45 → 13:50 conclusion

13:50 → 13:55 AOB