4:08 p.m.
Hej,
Simon Lundström via satosa-users <satosa-users(a)lists.sunet.se> [2025-08-14 15:15
CEST]:
In the AuthnRequest the SaaS SP asks to NameIDPolicy
AllowCreate="true"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified”.
The backend then sends an AuthnRequest to our IDP without any
NameIDPolicy (which is fine) and by default our IDP chooses to use
urn:oasis:names:tc:SAML:2.0:nameid-format:transient via
Subject>NameID which is fine.
But then the frontend answers the SaaS SP with a
urn:oasis:names:tc:SAML:2.0:nameid-format:transient via
Subject>NameID which I think is weird and wrong. I mean the SaaS SP
requested unspecified, shouldn’t that be what SATOSA answers with?
I think you can't have it both ways: Finding it unprolematic that the
backend sends an authn request without a NameID Format to your IDP
(when the original format was "unspecified") and finding satosa at
fault that when the IDP consequently returns whatever it likes satosa
passes that on verbatim.
I.e., if you want to find satosa at fault here it would have to be
that it recieves a request with "unspecified" and passes on that
request *without* a format, IMHO.
Now of course the original SP's reliance on specifically the
"unspecified" format is very silly but I guess you're not putting a
SAML proxy between that SP and your IDP because the SP works so great.
I would *assume* you'd be able (or should be able) to incluence what
NameIDFormat the backend passes on, in relation to what it recieved.
(If not then I find it weird that it wouldn't use the same format
outgoing as incoming. Again that may be due to "unspecified" having
been requested. That's not a proper format such as others the spec
defines.)
If you're curious what's legal as per the SAML spec I'd suggest asking
about that on saml-dev(a)lists.oasis-open.org (if that's still around)
for clarification.
Best,
-peter