Hello Kristof,
You need a micro-service to do this and then you can make it as complex as
you need. On the init phase of the micro_service you register the
configuration and on the process phase you would get the mapped attributes,
the mapped NameID value and format and the context of the request. You can
then create, update or delete attributes or the NameID based on any checks
you need.
You may want to have a look at:
-
https://github.com/IdentityPython/SATOSA/wiki/Anatomy-of-a-response-micro-s…
In pseudocode you would do:
if data.subject_type == NAMEID_FORMAT_PERSISTENT:
data.attributes[eppn] = [data.subject_id]
Assuming eppn is the internal name of the attribute that should get the
value of the Subject/NameID element. Note that the value of the
data.attributes elements is a list.
You could easily convert the above to a configurable list of interval
attribute names that would get the NameID value, and extend it as needed.
Let us know if this helps.
Kind regards,
On Thu, Aug 4, 2022, 15:27 Kristof Bajnok <kristof(a)bajnok.hu> wrote:
Hi,
I'm looking for a way to map the SAML2 NameID to an attribute so that I
can use its value in the response generated by the frontend. In my use
case, different SAML2 IdPs might want to send the user identifier in
different attributes *or* in the NameID, and I want to pass this
information on to my application that is connected to the frontend. I
think I can not do this with the current attribute mapping code, because
it only works on attributes, and the NameID is not an attribute.
What is the best way to achieve this?
(I'm considering to perform the inclusion of the NameID only if the
NameIDFormat is something reasonable to use as a user identifier, but
first I need to get hold of the value on the frontend side.)
Thanks,
Kristof
_______________________________________________
Idpy-discuss mailing list -- idpy-discuss(a)lists.sunet.se
To unsubscribe send an email to idpy-discuss-leave(a)lists.sunet.se