Comments (7)
I think it would make most sense to override the list_apps()
adapter method:
By default, it reads SocialApp
records from the database, as well as apps configured in settings. But, there is nothing stopping you from doing:
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:
The List of hundreds of idps would clutter the "accounts/login" page
Isn't that just a matter of altering the login template? Though, we could streamline that with supporting app.settings['visible'] = False
.
Would this approach address your needs?
from django-allauth.
@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,
I agree that overriding list_apps and changing the login template is the faster and direct approach.
from django-allauth.
Ok, let's try it this way first.
from django-allauth.
@pennersr I was able to configure multiple IdP with my own list_apps() method as long as each had a different client_id
. But this leads to a problem regarding the client_id
/organization slug
in the acs
URLs
The sls
URLs may have the same problem, but I have not tested this.
The SP Metadata information is managed via a national service portal and is shared with all IdPs in the
DFN AAI
/ eduGAIN
. The IdPs check if the URLs used are listed in the metadata information
for the SP. I can provide multiple acs
and sls
URLs but wildcards are not supported.
At the moment there are ~400 IdPs in the DFN AAI
and ~5600 in eduGAIN
. Adding and managing
that many URLs in my SP metadata information is not feasible.
So for the saml authentication to work with federations, i see two possible implementations
- a special
acs
URL should be used, that is independent of theclient_id
. - multiple IdPs with the same client_id should be supported.
The SAML Response has to be parsed in both cases to extract the entityID of the IdP,
to look up the configuration as the client_id
is not provided with the URL in the first case,
or is not sufficient access the correct configuration.
At the moment I tend to the independent special URL implementation, as it seems to have
the least impact on existing code.
from django-allauth.
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 /accounts/saml/{1..400}/acs/
, as well as 400 metada urls /accounts/saml/{1..400}/metadata/
. So, the issue is that you need to manually configure those 400 metadata urls over at the portal? Because here you mention:
Adding and managing that many URLs in my SP metadata information is not feasible.
... 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?
from django-allauth.
Thinking out loud how this could be supported out of the box:
- You would only setup one SAML app, with the actual IdP information left blank.
- Then, over at the ACS view, we could dynamically extract the issuer using
base64.b64decode(request.POST['SAMLResponse'])
. - Then, we would need to fetch this URL https://mds.edugain.org/edugain-v2.xml and see if the issuer is known.
- If known, we can dynamically put together the
settings.idp
configuration of the app, and continue as is now.
I guess this is what you were suggesting in your initial comment? I am not sure though what "ds_url": "https://wayf.aai.dfn.de/DFN-AAI-eduGAIN/wayf/www/WAYF.php"
is meant for?
from django-allauth.
first, I am new to saml authentication and I am a sysadmin and not a professional programmer,
so take my information with a grain of salt.
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
/accounts/saml/{1..400}/acs/
, as well as 400 metada urls/accounts/saml/{1..400}/metadata/
. So, the issue is that you need to manually configure those 400 metadata urls over at the portal? Because here you mention:
Yes I am only implementing the SP side. For security reasons the IdPs do not fetch the metadata from SP,
but use the metadata provided by the federation via the portal. So as far as I know the metadata url is not relevant.
Adding and managing that many URLs in my SP metadata information is not feasible.
... 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?
The IdP entetyID is included in the SAMLResponse
Thinking out loud how this could be supported out of the box:
* You would only setup one SAML app, with the actual IdP information left blank.
My Initial idea was to provide a metadata file with all the IdPs , or I could create a configuration
for each IdP a my own list_apps()
method. The later case might be usefull to overwrite some settings
e.g. Attribute Mappings
* Then, over at the ACS view, we could dynamically extract the issuer using `base64.b64decode(request.POST['SAMLResponse'])`.
yes,
* Then, we would need to fetch this URL https://mds.edugain.org/edugain-v2.xml and see if the issuer is known.
I would use a local copy with only the IdP metadata, but yes, Use the entiryID to extract the config parameters like certs,
* If known, we can dynamically put together the `settings.idp` configuration of the app, and continue as is now.
I guess this is what you were suggesting in your initial comment? I am not sure though what
"ds_url": "https://wayf.aai.dfn.de/DFN-AAI-eduGAIN/wayf/www/WAYF.php"
is meant for?
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
if you want to use an other IdP
from django-allauth.
Related Issues (20)
- How to match existing, local accounts to social accounts by username? HOT 2
- Headless mode: reset password not working HOT 2
- is_existing not updating after saving a new user connected to SocialLogin HOT 3
- module 'jwt' has no attribute 'PyJWTError' HOT 2
- Headless Demo: Add ability to delete user HOT 1
- Headless Logout should return 200 instead of 401 HOT 2
- Adding class for input doesn't word HOT 1
- Document the usage of (dynamic) auth_params such as kc_idp_hint within provider_login_url
- [Headless] Auth not working in headless mode via sessionid cookie HOT 1
- Change in socialaccount providers imports causing pytest error HOT 2
- Allow to customize tokens mock in OAuth2TestsMixin HOT 6
- Google access token and refresh token are not getting saved in `SocialToken` model
- [Suggestion] Signing up should (re)send verification mail HOT 7
- [Suggestion] Make it possible to patch `reverse()` HOT 8
- [Suggestion] Add a small tip about rates when testing HOT 2
- Forcing use of SAML nameID for email HOT 1
- can not login with google account in deployment HOT 1
- Outdated user object passed to `complete_social_signup` HOT 2
- Specifying a Discovery service URL HOT 1
- Page listing social connections should use email addresses or usernames, instead of names HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from django-allauth.