[SAML] Views/endpoints for users setting the organization's SAML configuration

[mecampbellsoup]

In our application, users "bring your own SAML config", i.e. they go into their e.g. Okta apps list, and create a new SAML configuration that maps their IdP data to our application.

Within our application, there is a form where they input this SAML configuration and submit it to our API.

We wrote a lot of this code ourselves, as it just barely predated when allauth released its SAML module(s).

I'm exploring instead using the now-built-in allauth modules so we don't have to maintain our own code, but I don't see views/endpoints to which new SAML configurations can be submitted, effectively replicating the static configuration approach in the docs.

Is there a way to dynamically/at runtime manage and modify what is represented as settings.SOCIALACCOUNT_PROVIDERS["saml"]["APPS"] list in the docs example?

I see this note:

How all of the above is configured in practice is shown below. Note that here we are using the settings based configuration, but you can setup the SocialApp via the Django admin as well

We are not using Django admin but I suppose we could utilize similar or even the same Django views perhaps?

Thank you and happy holidays! 🎄

[pennersr]

Is there a way to dynamically/at runtime manage and modify what is represented ...

Yes. You can create SocialApp instances yourself. Alternatively, you could override the socialaccount adapter, specifically, its list_apps() methods. If you already store the require data elsewhere, in a model of your own, you can use that as the single source of truth and return (unsaved) SocialApp instances based on that in the list_apps() method.

[mecampbellsoup]

Thank you @pennersr - I appreciate hearing from you always!

Question: are there any existing views you would recommend we hook into or call when receiving a customer's new SAML configuration?

[pennersr]

Depending on where you need that, DefaultSocialAccountAdapter.pre_social_login or the regular account signal user_logged_in ...

[mecampbellsoup]

I mean when, at runtime via our API, customers submit to us their SAML configuration files to enable "Login w/ SAML SSO" for their account. (In our app, an organization has n users, so the SAML config is applied to all the org's users.)

[pennersr]

That likely involves a model with foreign keys to an organization/company/customer model, and how that is modeled and stored is beyond scope of allauth. There are no views for this either.