6:03 a.m.
Hello Scott,
On Tue, Jul 7, 2020, 03:32 Scott Koranda <skoranda at sphericalcowgroup.com>
wrote:
Hi,
I have been asked off-list the same question by a couple of different
people. The question is "how can I get SATOSA to send a specific NameID
value and format to the requesting SP?"
They usually ask after trying, in vain, to configure the SAML2 frontend
and/or the SAML metadata for the SP to specify a particular NameID
format (e.g. urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress).
My reading of lines 339 to 353 in .../frontends/saml2.py is that there
is no way to force, either through configuration of the frontend or in
SAML metadata what format is used for NameID, nor what value is used.
Rather what happens is that the frontend takes whatever values are set
for
internal_response.subject_id
internal_response.subject_type
and creates a NameID element object and passed it to pysaml2 to create
the actual response. The only exception to that rule is if
internal_response.subject_id
is None, then pysaml2 is passed None, and it has code that then defaults
to creating a transient NameID (which I argue is the most sensible thing
it can do).
So to my reading, the only and correct way to affect what the SATOSA
SAML frontend sends for the NameID is to have a response microservice
that sets
internal_response.subject_id
internal_response.subject_type
before the frontend begins processing the response. The only alternative
is to just accept what is passed through from the backend.
Is my analysis correct?
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.
Cheers,
Thanks,
Scott K
P.S. I have been using a microservice(s) to set
internal_response.subject_id
internal_response.subject_type
for quite some time and it works just fine.
_______________________________________________
Satosa-dev mailing list
Satosa-dev at lists.sunet.se
https://lists.sunet.se/listinfo/satosa-dev