9:42 a.m.
Morgen,
On 14 Aug 2025, at 16:08, Peter Brand <peter.brand(a)univie.ac.at> wrote:
Hej,
Simon Lundström via satosa-users <satosa-users(a)lists.sunet.se> [2025-08-14 15:15
CEST]:
AFAICT: SATOSA doesn’t set a default and I can’t find the pysaml2 default even though I’ve
looked for a while.
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.
That too might be a bug but that follows the reasoning that I have regarding SATOSA (and
it might be wrong and if so this should be a bug?
My reasoning is that there are two SAML sessions going on:
1, Between SaaS SP and SATOSA frontend
2, SATOSA backend and Shibboleth IDP
And that those two are separate but sure, we can use attributes from 2 to send back via 1.
But we can also use microservices and change both 1 and 2, CRUD data from 1 to 2.
What supports my reasoning is that:
1, The AuthnRequest[ID] between SaaS SP and frontend we reuse when sending
Response[InResponseTo] (I mean, of course otherwise we’d break the SAML spec)
2, We also return all attributes that the SaaS SP asked for via metadata (or configured)
3, While attributes from Shibboleth IDP are sent to SaaS SP they have the correct
Response[Destination], Response>Signature, Response>Assertion>Issuer and
Audience.
The only thing that is missing is the asked for NameID format.
This is what makes me think this is a bug.
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.
hahaahahhaah. This is what I love about the SSO communities!
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.
Speaking of, I’m *very* surprised that the SaaS SP doesn’t error out when they ask for
unspecified and we return them transient. But then again, reading the SAML Core 2.0 spec
(3.4.1.1 Element <NameIDPolicy>) it says that:
If the Format value is omitted or set to
urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified, then the identity provider is free
to return any kind of identifier, subject to any additional constraints due to the content
of this element or the policies of the identity provider or principal.
So I guess I’m just wrong.
Schönes Wochenende!
BR,
- Simon