Hi everyone, There are these two concepts: * Attribute mapping is an action applied to the attributes it receives, in order to make attributes comply with the outgoing protocol. The behaviour is defined in the internal_attributes.yaml[0] file. An example: ``` attributes: displayname: openid: [nickname] saml: [displayName] ``` Here the attribute identified by 'nickname' that was processed by the a module with the option 'attribute_profile' set to 'openid' (which happens to be the default value for the satosa.backends.openid_connect.OpenIDConnectBackend) will be mapped to the internal-attribute 'displayname' which in turn will be mapped to an attribute with identified as 'displayName' and processed by a module with the option 'attribute_profile' set to 'saml' (which happens to be the default value for the satosa.backends.saml2.SAMLEIDASBackend and satosa.frontends.saml2.SAMLFrontend). This is complex enough - one could say that this maps the attribute with friendly-name 'nickname' to the attribute with friendly-name 'displayName' through the internal attribute 'displayname', but this is not the whole truth. * Attribute maps is a list of attributes that map their friendly name to their URI-name. For example: MAP={ 'identifier': 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri', 'fro': { 'urn:oid:2.16.840.1.113730.3.1.241': 'displayName' }, 'to': { 'displayName': 'urn:oid:2.16.840.1.113730.3.1.241' } } An attribute with NameFormat 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri' and URI-name 'urn:oid:2.16.840.1.113730.3.1.241' is mapped to the friendly-name 'displayName', and (the other way around) the friendly-name 'displayName' is mapped to the URI-name 'urn:oid:2.16.840.1.113730.3.1.241'. These two are very different things and take place in different projects. Attribute mapping belongs to SATOSA, and satisfies the knowledge needed to translate one attribute to another. Attribute maps belong to pysaml2, and satisfies the knowledge needed to manage attributes the same way whether they are provided by URI-name or friendly-name. In addition, pysaml2 has a configuration option to allow users to define their own attribute maps (because they might be working on a new profile, or attributes may be missing, or profiles are extended and they want to test new things etc). That configuration option is called 'attribute_map_dir'. You can read more about it in the documentation[1]. Using this option is the right way to use your own attribute maps if they are not defined upstream. Attribute maps are partly and indirectly used by attribute mapping through the 'internal_attributes.yaml' configuration. What really happens is that SATOSA maps one identifier to another through an internal-identifier. The identifiers get a value through: - the friendly name of attributes as defined in attribute maps, for the SAML protocol - the claims as processed by the OpenID-connect modules Claims[2] do not have "double" names - there is no friendly and uri name. Claims only have friendly looking names. So the identifiers are either friendly-names or claims. Having said all that, lets see if we can answer your questions: I feel that "attribute mapping" here is ambiguous. Attribute mapping is defined in internal_attributes.yaml. Attribute maps are defined by providing new 'MAP-structures' and pointing there with the 'attribute_map_dir' configuration option. As I mentioned earlier, claims do not have "double" names - there is no friendly and uri name. Claims only have friendly looking names. So there is no need for an equivalent of attribute maps for OIDC. Attribute mapping happens by directly using the claims. I put these two together as they are related with the docker setup. Quick answers would be: - The SAML-related attributes in internal_attributes.yaml should be defined in those attribute-maps and those should be used through the attribute_map_dir configuration option. - You should expect pysaml2 attribute maps to be loaded! I'm not sure if any of that happens though. Let's dig into that to see how it works. When the image is built, the attribute maps are copied under /opt/satosa/attributemaps[3] and then under the DATA_DIR[4] as defined by the environment, otherwise /opt/satosa/etc/attributemaps [5], unless that location is already filled when mapping the project dir as a volume[6]. So, this gives us a directory with attribute maps. However, nowhere in the configuration is a pointer to that directory through the relevant attribute_map_dir option. That means that while the files are there, they remain unused. Of course, one could change the saml frontend or backend config to point to /opt/satosa/etc/attributemaps and thus start using those - but this does not happen with the default configurations. If attribute_map_dir is not set[7], then by default pysaml2 uses the attribute maps it defines[8]. To sum up, with the default config -no attribute_map_dir config option set- you should assume that you are using the attribute maps that pysaml2 bundles. If you set attribute_map_dir config option to '/opt/satosa/attributemaps' you should be using the attribute maps under docker/attributemaps/ (or the attribute maps you have locally defined under such a directory). I hope all this makes things clearer. [0]: https://github.com/IdentityPython/SATOSA/blob/deef6bf39e4070a06db4e4dbb1c69… [1]: https://github.com/rohe/pysaml2/blob/4f0a45c361bbd46b1f56f468d4712c0ef9797c… [2]: https://openid.net/specs/openid-connect-core-1_0.html#Claims [3]: https://github.com/IdentityPython/SATOSA/blob/deef6bf39e4070a06db4e4dbb1c69… [4]: https://github.com/IdentityPython/SATOSA/blob/deef6bf39e4070a06db4e4dbb1c69… [5]: https://github.com/IdentityPython/SATOSA/blob/deef6bf39e4070a06db4e4dbb1c69… [6]: https://github.com/IdentityPython/SATOSA/blob/deef6bf39e4070a06db4e4dbb1c69… [7]: https://github.com/rohe/pysaml2/blob/4f0a45c361bbd46b1f56f468d4712c0ef9797c… [8]: https://github.com/rohe/pysaml2/blob/4f0a45c361bbd46b1f56f468d4712c0ef9797c… Cheers, -- Ivan c00kiemon5ter Kanakarakis >:3