-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
how to add support for SAML federations #3749
Comments
I think it would make most sense to override the By default, it reads def list_apps(self, request, provider=None, client_id=None):
apps = super().list_apps(request, provider=provider, client_id=client_id)
for some_config in some_source:
app = SocialApp(provider="saml", provider_id=...) # convert some_config
if client_id and client_id != app.client_id:
continue
if provider and app.provider_id != provider and app.provider != provider:
continue
apps.append(app)
return apps As for this:
Isn't that just a matter of altering the login template? Though, we could streamline that with supporting Would this approach address your needs? |
@pennersr Thank you for your input. I had not considered the option to override the default adapter. While i still think that the support for saml federations in gjango-allauth might be useful in the long run, |
Ok, let's try it this way first. |
@pennersr I was able to configure multiple IdP with my own list_apps() method as long as each had a different The SP Metadata information is managed via a national service portal and is shared with all IdPs in the So for the saml authentication to work with federations, i see two possible implementations
The SAML Response has to be parsed in both cases to extract the entityID of the IdP, At the moment I tend to the independent special URL implementation, as it seems to have |
Just to be sure that I am fully grasping the issue -- you are implementing the SP side of things. So you have ~400 IdPs, meaning, You have 400 acs urls
... suggesting that you are not managing those in the portal but in your SP metadata somehow? But suppose there is just one special acs URL and a user is using that to authenticate. How could you lookup the IdP without having it available in the URL? |
Thinking out loud how this could be supported out of the box:
I guess this is what you were suggesting in your initial comment? I am not sure though what |
first, I am new to saml authentication and I am a sysadmin and not a professional programmer,
Yes I am only implementing the SP side. For security reasons the IdPs do not fetch the metadata from SP,
The IdP entetyID is included in the SAMLResponse
My Initial idea was to provide a metadata file with all the IdPs , or I could create a configuration
yes,
I would use a local copy with only the IdP metadata, but yes, Use the entiryID to extract the config parameters like certs,
The discovery service url aka "Where Are You From" is a fancy version of the IdP selection that uses cookies and geoip information to pre-select the last used, or the most likely IdP and lets you search for your organisation |
I want to allow authentication by all IDPs in a saml federation (e.g. DFN-AAI or eduGAIN).
I am willing to try to implement this feature myself, but I am not a programmer but a system administrator.
Therefore i would like to get feedback on how to best implement the support for SAML federations.
At the moment a manual configuration for each idp in the federation is possible, but:
But some federations distributed the metadata via an aggregate file, and therefore the sp metadata must be identical
for all idps
My goals are:
DFN-eduGAIN-WAYF
to help the user find the correct IDP
Below is a skeleton example configuration
The text was updated successfully, but these errors were encountered: