3:14 p.m.
Hi all,
We’ve started to use SATOSA to handle some… peculiar… vendors (mostly SaaS) and we’re
liking it a lot so far!
One issue that we found I haven’t been able to figure out so I thought I’d try the list to
see if we’re doing something wrong or we actually found a bug.
The flow/setup that we’re using is:
SaaS SP <-> SATOSA frontend <-> SATOSA backend <-> Shibboleth IDP.
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?
A work around that I have tried is setting
config.sp_config.service.sp.name_id_policy_format:
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified AND making the Shibboleth IDP to
prefer unspecified.
This makes the response from frontend to SaaS SP use unspecified like SaaS SP requested.
I don’t think this should be necessary. Am I wrong?
BR,
- Simon
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
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
143
days inactive
144
days old
2 comments
2 participants
participants (2)
-
Peter Brand -
Simon Lundström