With sal setup to use saml as authentication, there exists a potential for the django session table to become extremely large, when a user has loaded a dashboard, and that user's saml session later expires.

When the dashboard from sal is loaded, each widget makes a XMLHttpRequest to get its data at regular interval (refresh regularly). Should a session expire while the user has the page loaded, the widget properly redirect the data query to the login page (30x redirect), which, without saml, causes each widget to be replaced by a set of 'login boxes'. However, with SAML, the query is redirected to that same login page, which is turn, is redirected to the IdP, presumably in a different domain (google, okta, onelogin, etc). CORS blocks those queries, and causes the page to try to load the data again without waiting. For each 'pass' at the login page (before the 302 to the IdP), django will create a session entry in the DB for that user, causing the table to potentially grow pretty quickly (we were looking at our DB growth at over 10MB/sec).

It might be possible to update the sal-saml code to use something like https://github.com/ottoyiu/django-cors-headers module and provide CORS headers to allow calls to the IdP, which should (in theory) allow for the existing behavior to stay the same (present the content of the login page inline the widget). Full implication of that change are tbd though.

An alternative would be to change the decorator to require a certain set of permissions rather than a login (which would give an access denied, rather than cause repeated 302 passes over the SAML sal login redirect page...

Currently SAL uses djangosaml2==0.18.1 however there are number of known fixed issues within pysaml2 & djangosaml2 mainly around signed response support.

IdentityPython/pysaml2#845

This is an open issue to please not update djangosaml2 to version 0.16.0 or any version that pins to pysaml2==4.4.0, as it breaks Okta authentications.

Once pysaml2 has another release we can retest.

All of this is so we can avoid maintaining patches in this docker container.

Okta PR incoming...

Issue

When a new release of this docker container is created dockerhub currently attempts to rebuilds all branches instead of just the most recent version + latest. This means build times for new releases are crazy long until/unless Graham goes into the dockerhub GUI and cancels old builds.

Potential fix

I've tested the following on my fork sal-saml and the following autobuild settings fixed this for me.

This should limit dockerhub to only build branches in the format of X.X.X or patches named X.X.X.X. Then when a new branch is pushed dockerhub only builds the new branch.

based off: https://stackoverflow.com/a/44796846