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:
What's the Right Way to configure or extend the
attribute mappings?
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.
Also, where do I find the attribute mappings for other
protocols, like
OIDC? I looked at the pyoidc sources, but I didn't find similar data
structures or source code.
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.
How does <internal_attributes.yaml> relate to
the attribute maps defined in the Docker
container?
Can I assume the ones from pysaml2 are already loaded?
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