8:59 p.m.
Hello again,
On Mon, 12 Sept 2022 at 13:52, Kristof Bajnok <kristof(a)bajnok.hu> wrote:
Hi,
What is exactly the relationship between the attribute name format and
the mapping within attributemaps?
I couldn't fully understand that part of the code, but empirically it
seems that only the 'last' mapping file is considered, so it's not
possible to have multiple files for the same attrname-format, only one
mapping per name format is allowed. If this is correct, then adfs_v1x.py
and adfs_v20.py being separate files is pretty misleading.
I will not go into the ordering that takes place but it is more
complex than using the last mapping file. Having said this, I agree,
it is a bit misleading..
Also, the satosa tree contains a subset (I didn't
verify, whether it is
a true subset or not) of the pysaml's default attributemap dir, what is
the purpose of that directory?
I am guessing you are talking about this directory:
https://github.com/IdentityPython/SATOSA/tree/dbe9dd6/docker/attributemaps
Satosa, and any user of pysaml2, can configure its own set of mappings
using the 'attribute_map_dir' configuration option:
https://pysaml2.readthedocs.io/en/latest/howto/config.html#attribute-map-dir
Regarding whether that directory is the same as the builtins or not, I
don't think it matters a lot. The point was to demonstrate that one
can have their own mappings. You could potentially configure a saml
backend or frontend to use that dir, but the example files do not set
that option (anymore, iirc). So, unless somebody sets this option
explicitly to that specific path within the container, that directory
remains unused.
Note that the docker folder will be removed from the satosa repo and
we will point to https://github.com/IdentityPython/satosa-docker which
is now a Docker Official image. That image does not include an
attributemaps directory.
---
The big question is why we need these mappings and what they offer. I
have not figured that out yet. I am not sure why they were needed,
other than for convenience when referring to an attribute - they allow
us to refer to the friendly-name instead of the
urn/oid/canonical-name.
I had started an issue to track how the mappings can be removed and
what parts of the code will be affected. That evolved to a discussion,
which I have to catch up with to remember the outcome, but the general
feeling is that people would be fine with removing that overhead and
complexity from the code. Doing that would mean that any mention of an
attribute with its friendly-name will need to be replaced by the
attributes canonical-nane.
You can read about this here:
https://github.com/IdentityPython/pysaml2/issues/549
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3