You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was looking at the SAML_CONFIG_LOADER callable to select an IdP (or possible even set scoping attributes later ;-)) based on other logic. (Since the callable is used in a new authentication request for every user, one could use the hostname or part of the path for instance, or something from a session.)
In the djangosaml2 documentation I read:
# in this section the list of IdPs we talk to are defined
# This is not mandatory! All the IdP available in the metadata will be considered instead.
'idp': {
for the idp section in the SPConfig { "service": { "sp": { "idp": [] } } }, but looking at the code, I wonder if any of this idp information is used at all? Because djangosaml2.utils.available_idps() only considers metadata from the SPConfig.
Maybe it could be another way to get a selected_idp (and of course I'm also looking at Scoping), or am I misinterpreting this?
In the pysaml2 documentation I found this section:
Defines the set of IdPs that this SP is allowed to use; if unset, all listed IdPs may be used. If set, then the value is expected to be a list with entity identifiers for the allowed IdPs. A typical configuration, when the allowed set of IdPs are limited, would look something like this:
Which also implies to me that there is no point in considering other IdPs from the metadata. Also, the example there is different from the example in djangosaml2. (Looks like it's taken from idp definition instead of preselection?)
The text was updated successfully, but these errors were encountered:
consider that you can have multiple idp in a metadata store (let's assume we have a MDQ) and just enable one of these in your SP.
that's something that belong to pysaml2, three years at this part that I don't use this feature so I would appreciate your patches if needed and coupled with some tests as well
tell more about your use case if there's something that we could share for a better implementation
Hi,
I was looking at the
SAML_CONFIG_LOADER
callable to select an IdP (or possible even set scoping attributes later ;-)) based on other logic. (Since the callable is used in a new authentication request for every user, one could use the hostname or part of the path for instance, or something from a session.)In the djangosaml2 documentation I read:
for the idp section in the SPConfig
{ "service": { "sp": { "idp": [] } } }
, but looking at the code, I wonder if any of this idp information is used at all? Becausedjangosaml2.utils.available_idps()
only considers metadata from the SPConfig.Maybe it could be another way to get a selected_idp (and of course I'm also looking at Scoping), or am I misinterpreting this?
In the pysaml2 documentation I found this section:
Which also implies to me that there is no point in considering other IdPs from the metadata. Also, the example there is different from the example in djangosaml2. (Looks like it's taken from idp definition instead of preselection?)
The text was updated successfully, but these errors were encountered: