Issue with motley_cue version 0.3.0-1

benoitroland commented 1 year ago

Dear Diana @dianagudu, dear Marcus @marcvs,

until some weeks ago, we were using motley_cue version 0.3.0-1 without any problem on some login node at KIT.

The configuration of the login node has not changed, but the use of the motley_cue version 0.3.0-1 seems now to be "broken".

The output of mccli ssh c4p-login-dev.gridka.de --debug is the following:

debug: HTTP requests cache installed at /root/.cache/mccli_cache.sqlite
info: Trying to get ssh hostname from arguments.
debug: Running this command to get ssh configuration: ssh -G c4p-login-dev.gridka.de
debug: Found hostname by parsing command output: c4p-login-dev.gridka.de
info: Got host 'c4p-login-dev.gridka.de', looking for motley_cue service on host.
info: Looking for motley_cue service at 'https://c4p-login-dev.gridka.de'...
info: ...FOUND IT!
info: No access token provided.
info: No oidc-agent account provided.
info: No issuer URL provided.
info: Trying to get list of supported AT issuers from https://c4p-login-dev.gridka.de...
info: Using the only issuer supported on service to retrieve token from oidc-agent: https://login.helmholtz.de/oauth2
https://c4p-login-dev.gridka.de/user/get_status
<Response [500]>
error: Something went wrong: Expecting value: line 1 column 1 (char 0)
error: Failed to get ssh username

With the help of Manuel @giffels, we thought that there could be a possible issue with some of the eduperson_entitlement.

The output of flaat-userinfo $(oidc-token punch-aai) contains the following entitlements:

   "urn:mace:dir:entitlement:common-lib-terms",
   "http://bwidm.de/entitlement/bwLSDF-SyncShare",
   "urn:geant:helmholtz.de:group:KIT#login.helmholtz.de",
   "urn:geant:dfn.de:nfdi.de:punch:group:PUNCH4NFDI:punch_intra#login.helmholtz.de",
   "urn:geant:h-df.de:group:HDF#login.helmholtz.de",
   "urn:geant:dfn.de:nfdi.de:punch:group:PUNCH4NFDI#login.helmholtz.de",
   "urn:geant:helmholtz.de:group:Helmholtz-member#login.helmholtz.de"

We then retrieved the information about these entitlements by adding the lines:

if isinstance(value, list):`
    with open("/tmp/value.log", "w") as f:`
       for val in value:`
                  f.write(f"Value: {val}, {self.parse(val)}\n")`

in the function def is_satisfied_by(self, user_infos: UserInfos) -> CheckResult: from /usr/lib/motley-cue/lib/python3.8/site-packages/flaat/requirements.py.

The output is the following:

Value: urn:mace:dir:entitlement:common-lib-terms, None

Value: http://bwidm.de/entitlement/bwLSDF-SyncShare, None

Value: urn:geant:helmholtz.de:group:KIT#login.helmholtz.de, <G069 namespace_id=geant delegated_namespace=helmholtz.de group=KIT group_authority=login.helmholtz.de>

Value: urn:geant:dfn.de:nfdi.de:punch:group:PUNCH4NFDI:punch_intra#login.helmholtz.de, <G069 namespace_id=geant delegated_namespace=dfn.de subnamespaces=nfdi.de,punch group=PUNCH4NFDI subgroups=punch_intra group_authority=login.helmholtz.de>

Value: urn:geant:h-df.de:group:HDF#login.helmholtz.de, <G069 namespace_id=geant delegated_namespace=h-df.de group=HDF group_authority=login.helmholtz.de>

Value: urn:geant:dfn.de:nfdi.de:punch:group:PUNCH4NFDI#login.helmholtz.de, <G069 namespace_id=geant delegated_namespace=dfn.de subnamespaces=nfdi.de,punch group=PUNCH4NFDI group_authority=login.helmholtz.de>

Value: urn:geant:helmholtz.de:group:Helmholtz-member#login.helmholtz.de, <G069 namespace_id=geant delegated_namespace=helmholtz.de group=Helmholtz-member group_authority=login.helmholtz.de>

Namely the information related to the two first entitlements does not seem to be defined.

Maybe these two entitlements are new and were not present when we did our test some weeks ago, the reason why it was working fine at that time?

If we again modify the function def is_satisfied_by(self, user_infos: UserInfos) -> CheckResult: from /usr/lib/motley-cue/lib/python3.8/site-packages/flaat/requirements.py to skip the "undefined" entitlements:

        if isinstance(value, list):
                for val in value:
                    if not self.parse(val):
            continue
                    if self.matches(self.value, self.parse(val)):
                        matched_value = val
                        matched = True
                        break

the output of mccli ssh c4p-login-dev.gridka.de --debug is then the following:

debug: HTTP requests cache installed at /root/.cache/mccli_cache.sqlite
info: Trying to get ssh hostname from arguments.
debug: Running this command to get ssh configuration: ssh -G c4p-login-dev.gridka.de
debug: Found hostname by parsing command output: c4p-login-dev.gridka.de
info: Got host 'c4p-login-dev.gridka.de', looking for motley_cue service on host.
info: Looking for motley_cue service at 'https://c4p-login-dev.gridka.de'...
info: ...FOUND IT!
info: No access token provided.
info: No oidc-agent account provided.
info: No issuer URL provided.
info: Trying to get list of supported AT issuers from https://c4p-login-dev.gridka.de...
info: Using the only issuer supported on service to retrieve token from oidc-agent: https://login.helmholtz.de/oauth2
https://c4p-login-dev.gridka.de/user/get_status
<Response [200]>
info: State of your local account: not_deployed
info: Creating local account...
error: Failed on deploy: [HTTP 500] {"detail":"Something went wrong when trying to reach state deployed"}
error: Failed to get ssh username

Namely we can go "a step further" in the authentication by skipping the "undefined" entitlements.

We would like to ask you if you could please have a look at this issue?

Thanks a lot in advance!

Manuel, Benoit

dianagudu commented 1 year ago

Hi there, I believe this is the same issue as https://github.com/indigo-dc/flaat/issues/63, which was fixed in flaat v1.1.5 and will be included in the next motley-cue release, that I am preparing at the moment.

giffels commented 1 year ago

Hi @dianagudu,

thanks a lot for your answer. Do you have an estimate when the next motley-cue release will be available? We will have a demonstration in the PUNCH4NFDI context in about two weeks and need to fix the group name too long issue before that.

Thanks, Manuel

benoitroland commented 1 year ago

Dear Diana @dianagudu,

concerning the shortening of the too long group name, we can add in the latest version of the feudalAdapterLdf something like:

--- extract namespace and group name word_split = regex.search(r'(?P\S+):group:(?P\S+)', word) word_namespace = word_split.group('namespace') word_group = word_split.group('group') logger.warning(F"word: {word} - namespace: {word_namespace} - group: {word_group}")

and then use the word_namespace: word = word_namespace

Cheers, Benoit

dianagudu commented 1 year ago

Hi there,

there will be a new release of motley-cue today, but this does not contain the fix for the group name too long. Regarding the timeline, two weeks is quite short, with our participation at the EGI conference next week. But it will be the next issue to tackle after that.

My understanding after our discussion was that in order to make the mapping more flexible, and at the same time that you can immediately fix this, we'd have the plan as described here, i.e.:

the entitlements are split in two components: namespace and group information
there will be the option to configure in the feudal_adapter.conf a regex for each component on how to translate & shorten it
meanwhile, you can hard code the translation in your feudal installation, and you're free to make that as specific as possible, even "always translate urn:dfn.de:nfdi-de:punch:group:punch4nfdi:punch:role=intra to nfdi_punch_punch4nfdi_punch" (or actually regex 1 -> replace namespace urn:dfn.de:nfdi-de:punch with nfdi_punch and regex 2 -> what is already implemented, punch4nfdi:punch will be replaced with with punch4nfdi_punch)
when this feature is released, you will be able to simply adjust the configuration to fit your hardcoded behaviour, so that you would not need to rename the groups already created.

This feature has the potential to cause quite a bit of damage if not properly tested and documented.

dianagudu commented 1 year ago

Was fixed in feudal v0.7.1.

Use carefully! Changing the way local groups are named from entitlements will result in new groups being created and the user being removed from the old groups, so you'll have to handle any necessary data migrations manually.

Check out the note in feudal for additional information: https://git.scc.kit.edu/feudal/feudalAdapterLdf/-/issues/71#note_637005

Check out the feudal config template for how to configure the new group features: etc/feudal_adapter.conf

dianagudu / motley_cue

Issue with motley_cue version 0.3.0-1 #48