Skip to content
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

Dynamically adding identity providers #29

Open
jhchen opened this issue Oct 16, 2018 · 5 comments
Open

Dynamically adding identity providers #29

jhchen opened this issue Oct 16, 2018 · 5 comments

Comments

@jhchen
Copy link

jhchen commented Oct 16, 2018

Is there a recommended way to add identity providers at runtime? Currently we are doing Application.put_env(:samly, :identity_providers, identity_providers) and generating identity_providers from IdpData.load_providers/1 which doesn't feel like the cleanest since it has to re-generate existing identity providers.

Happy to contribute a PR if there is interest supporting an API to add a new identity provider at runtime. The use case for us is we allow users to integrate their Okta organization so different users Okta accounts ex. company1.okta.com and company2.okta.com which would correspond to company1.slab.com and company2.slab.com on our end. These would have different metadata XML files that we would add during runtime.

@handnot2
Copy link
Owner

The current config/metadata XML-in-files model may not be suitable in that dynamic world. I was thinking of addressing such a requirement after the 1.0 release.

A PR that could move Samly in that direction would be welcome.

@jhchen
Copy link
Author

jhchen commented Oct 18, 2018

Okay yes we are actually doing a hacky JIT writing to file right now but maybe we can just start with this. Will try to find some time in the next couple of weeks.

@kanes115
Copy link

@jhchen @handnot2 is there any progress on this?

@tielur
Copy link

tielur commented Sep 16, 2019

I'm interested in this as well. I'm wondering if we can follow something similar that was done for the State where a behaviour is written. The first implementation could be a Config version where it does what Samly currently does now reading from the application environment.

Then we can build other implementations on top of that, such as databases, ets, ect...

@handnot2 thoughts?

@samrobinsonsauce
Copy link

samrobinsonsauce commented Oct 31, 2024

I also need the ability to dynamically add idp's to support my use case.

Was any progress made on this?

@handnot2 @jhchen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants