Yes. In effect, the frontend configures its metadata
but what it will
finally send is depending upon what the backend returned. The backend is
configured on its own and that configuration may differ. The backend may
not even talk saml.
So, how the received claims or attributes or NameID are transformed to the
format that the frontend needs should be implemented by a micro-service
(which can be as complex as you want).
Right now, that micro-service will need to be configured again, or imply
that the NameID format needed is "x", as the micro-service does not have
access to the frontend configuration. If it did, it could be clever and
always try to construct the NameID value with a correct format, without the
user having to keep the two (the frontend configuration and the
micro-service configuration) settings in sync. Maybe it's time to make
those available through the context object.
Thanks for the confirmation Ivan.
I think this example configuration in GitHub for the SAML frontend
https://github.com/IdentityPython/SATOSA/blob/master/example/plugins/fronte…
is helping to mislead people. It includes the configuration
name_id_format: ['urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
'urn:oasis:names:tc:SAML:2.0:nameid-format:transient']
I don't see looking at the code that the configuration option
'name_id_format' is ever referenced by
.../src/satosa/frontends/saml2.py.
It is probably only passed to pysaml2 and used in the configuration of
the underlying "IdP object", but again given the way SATOSA functions
that configuration is never exercised.
I propose we modify that example configuration and remove that line
entirely.
Thoughts?
If nobody objects I will do it...
Thanks,
Scott