2:32 a.m.
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?
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.
8: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
10:44 p.m.
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.
Thanks for the confirmation Ivan.
I think this example configuration in GitHub for the SAML frontend
https://github.com/IdentityPython/SATOSA/blob/master/example/plugins/fronte…
is helping to mislead people. It includes the configuration
name_id_format: ['urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
'urn:oasis:names:tc:SAML:2.0:nameid-format:transient']
I don't see looking at the code that the configuration option
'name_id_format' is ever referenced by
.../src/satosa/frontends/saml2.py.
It is probably only passed to pysaml2 and used in the configuration of
the underlying "IdP object", but again given the way SATOSA functions
that configuration is never exercised.
I propose we modify that example configuration and remove that line
entirely.
Thoughts?
If nobody objects I will do it...
Thanks,
Scott
6:40 p.m.
hello Scott,
On Tue, 7 Jul 2020 at 23:44, Scott Koranda
<skoranda at sphericalcowgroup.com> wrote:
(leaving this as a permanent URL to that file)
https://github.com/IdentityPython/SATOSA/blob/0ddf568/example/plugins/front…
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.
Thanks for the confirmation Ivan.
I think this example configuration in GitHub for the SAML frontend
https://github.com/IdentityPython/SATOSA/blob/master/example/plugins/fronte…
is helping to mislead people. It includes the
configuration
name_id_format: ['urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
'urn:oasis:names:tc:SAML:2.0:nameid-format:transient']
I don't see looking at the code that the configuration option
'name_id_format' is ever referenced by
.../src/satosa/frontends/saml2.py.
It is probably only passed to pysaml2 and used in the configuration of
the underlying "IdP object", but again given the way SATOSA functions
that configuration is never exercised.
I propose we modify that example configuration and remove that line
entirely.
The `name_id_format` configuration option there, says that this entity
(the saml frontend that will be instantiated) will advertise on its
metadata the <NameIdFormat> elements with the values that have been
set.
Your concern seems to be how this is /enforced/ internally - ie,
currently if the line above is set, but the backend sets
`internal_response.subject_type` to a different value, that value will
be used directly.
- How do we fix this and which component is responsible to handle this?
This is not fixed by hiding the configuration option. Even if we
remove it from the example file, it will still be available for
configuration.
And if we go further and remove it from the configuration, we will be
removing our ability to control that part of the metadata of this
entity.
What we should work towards doing is
- get the format that the backend sent,
- get the format the entity advirtises on its metadata,
- compare than and if they match then proceed
what happens though, if they do not? Then we need a way to convert
from one format to another and along with the format we must adjust
the value. I do not think we can express that with a simple
configuration option. Thus, the way to handle this should be through a
custom module - a micro-service. The micro-service should know which
formats we are targeting and try to make that conversion and transform
(or select) the value appropriately. This is what we discussed in the
previous emails ;-)
So, I don't think we should remove the option from the example, but I
agree that we should better document what it does.
Then also document the behaviour above and how one can control what
the resulting format will be through a micro-service.
We could also say that if in the end the format is not valid (it's not
one of the value defined by name_id_format), then stop the flow and
error out. Would that be useful?
cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
12:46 p.m.
Hi,
Comments inline below.
Ah, yes. Thanks. I forgot that it would be used in the SAML metadata
generation.
Thanks for the
confirmation Ivan.
I think this example configuration in GitHub for the SAML frontend
https://github.com/IdentityPython/SATOSA/blob/master/example/plugins/fronte…
(leaving this as a permanent URL to that file)
https://github.com/IdentityPython/SATOSA/blob/0ddf568/example/plugins/front…
is helping to mislead people. It includes the
configuration
name_id_format: ['urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
'urn:oasis:names:tc:SAML:2.0:nameid-format:transient']
I don't see looking at the code that the configuration option
'name_id_format' is ever referenced by
.../src/satosa/frontends/saml2.py.
It is probably only passed to pysaml2 and used in the configuration of
the underlying "IdP object", but again given the way SATOSA functions
that configuration is never exercised.
I propose we modify that example configuration and remove that line
entirely.
The `name_id_format` configuration option there, says that this entity
(the saml frontend that will be instantiated) will advertise on its
metadata the <NameIdFormat> elements with the values that have been
set. Your concern seems to be how this is /enforced/
internally - ie,
currently if the line above is set, but the backend sets
`internal_response.subject_type` to a different value, that value will
be used directly.
- How do we fix this and which component is responsible to handle this?
This is not fixed by hiding the configuration option. Even if we
remove it from the example file, it will still be available for
configuration.
And if we go further and remove it from the configuration, we will be
removing our ability to control that part of the metadata of this
entity.
What we should work towards doing is
- get the format that the backend sent,
- get the format the entity advirtises on its metadata,
- compare than and if they match then proceed
what happens though, if they do not? Then we need a way to convert
from one format to another and along with the format we must adjust
the value. I do not think we can express that with a simple
configuration option. Thus, the way to handle this should be through a
custom module - a micro-service. The micro-service should know which
formats we are targeting and try to make that conversion and transform
(or select) the value appropriately. This is what we discussed in the
previous emails ;-)
So, I don't think we should remove the option from the example, but I
agree that we should better document what it does.
Then also document the behaviour above and how one can control what
the resulting format will be through a micro-service.
We could also say that if in the end the format is not valid (it's not
one of the value defined by name_id_format), then stop the flow and
error out. Would that be useful?
Yes, I think documentation is what is needed.
Thanks,
Scott
1408
days inactive
1414
days old
4 comments
2 participants
participants (2)
-
ivan.kanak＠gmail.com -
skoranda＠sphericalcowgroup.com