[Documentation] Optional multiple user_id_from_attrs

[peppelinux]

Hi,
I'm using SaToSa with two Saml Backends, through this additional feature. These two Saml2 backends gets different attributes from their IDPs (target endpoint). If one of them do not return any 'eduPersonTargetedID' but another id with a different name, then SaToSa goes in Exception Unknow Error because it cannot find eduPersonTargetedID as attribute name.

Using this patch I can consider multiple uid, if anyone of them could be unavailable SaToSa will try another One, following this internal_attributes example:

user_id_from_attrs: ["edupersontargetedid", "eppn", "thatname"]

I share as it came, if you will like to spend some more word on this...
thank you in advance

All Submissions:

• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Have you added an explanation of what problem you are trying to solve with this PR?
• Have you added information on what your changes do and why you chose this as your solution?
• Have you written new tests for your changes?
• Does your submission pass tests?
• This project follows PEP8 style guide. Have you run your code against the 'flake8' linter?

[peppelinux]

As previously discussed during an idpy call - we can close this PR with an example about getting the same result with the current asset

[c00kiemon5ter]

Using this patch I can consider multiple uid, if anyone of them could be unavailable SaToSa will try another One, following this internal_attributes example:

user_id_from_attrs: ["edupersontargetedid", "eppn", "thatname"]

Instead of doing this here, you can set a new internal attribute that gets a value from all those attributes. Then this internal attribute will map to the user_id.

attributes:
  the_user_id:
    saml:
      - eduPersonTargetedID
      - eduPersonPrincipalName
      - mail

user_id_from_attrs:
  - the_user_id

---

Even more flexible would be to have a micro-service to set the internal_data.user_id to whatever you need, with the logic you need.

[c00kiemon5ter]

Having said this, I'm not opposed to what you suggest here. I am not sure whether the semantics should be all those attributes need to have a value (what currently happens) or all those attributes may have a value (what you suggest). There is no way to indicate if it's one or the other, while it should be clear.

I am thinking that maybe user_id_from_attrs and user_id_to_attr should be removed entirely and internal_attributes should just be about the mapping.

These changes will probably come along the switch from friendly names to canonical names.

I will leave this open for now, but we should come back to it at some point. I have some ideas on how to generalize many of these decisions so that they can be configurable, but this needs to be tried out first with something small.

[peppelinux]

Great, thank you for the example, I think that's fine. If this thread could improve in any way the general asset I'll follow you

[peppelinux]

Got it to work as you explained.
We could close this issue

[peppelinux]

Todo: convert this PR to Documentation, to help users to handle this use case.