laravel-saml2
laravel-saml2 copied to clipboard
aacotroneo
Cannot connect to multiple IDPs
If user wish to connect to multiple IDPs based on the user domain this plugin doesn't allow. All the IDP configurations are cached on application load and are compared every time the response is received from the IDP. I need to make changes to the validation function in the onelogin Response class to get pass through it.
@gaurravv5 did you find a solution to this?
I am having right now the same issue, I want to connect different IDP's but the configuration is based on the config file and its being cached by laravel
I would need this functionality as-well, is this a massive feature request or something that can be done in a PR?
The thing is that OneLogin doesn't support multiple IDPs per instance (I guess you could probably do it by managing multiple instances). And this library is pretty tied to 1 single instance and It's not easy to extend that.
I'm not sure you'll be able to make it work by just changing the configuration dynamically, or at least it wouldn't be as clean as having some static routes per IDP, such as the /acs... and the others a nice to have. And then for some other routes you need business logic to determine which instance to use. It's not easy to generalize until you actually have the case working and you start seeing all the difficulties.
I'd clone the library and start at the Saml2ServiceProvider trying to make an array instead of that singleton.
Yes I have found the solution, will be posting it here by tomm
On Mon 7 May, 2018, 5:48 PM Mohammad Ali Ghasemi, [email protected] wrote:
I also got same problem! has anybody found solution for multiple IdPs?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aacotroneo/laravel-saml2/issues/117#issuecomment-387046854, or mute the thread https://github.com/notifications/unsubscribe-auth/AFI5bO0Dyhkwt9qBtZsBaUgWEmgen9hcks5twDuLgaJpZM4RRjc3 .
@gaurravv5 That is great. I stuck to this problem and I cannot go further. It will help me a lot. Waiting for your update :)
You can connect to multiple IDPs by overriding the acs() and sls() functions and routes of the Aacotroneo\Saml2\Http\Controllers\Saml2Controller, for this you wont need to change anything in vendor. Keep all the IDP data in separate config file. Based on user domain you can select which idp to hit on and replace the saml2_settings idp data accordingly in the config for that session before calling Saml::login(). After the login you get response at your acs function. there you again change the idp data based on user domain in the config and then call Saml2::acs() and Saml2::getSaml2User(). Similarly you can logout by overriding the sls function. This works for me. cheers :)
@gaurravv5 Thanks. I did something like your solution. Thanks for your response 👍
We needed this functionality for our app at work. Ie. Each user belongs to a company. The company can be enabled for SSO so the IdP for each company is different. We store the IdP settings for each company in a SamlSettings table that has a relationship to the company.
We pass an email address to the login page and it identifies the user's company and redirects them to the relevant IdP based on the SAML settings. This is important for us as admins for a company can enable and configure SAML SSO through our web interface (saving the settings in the database).
We started out using this plugin but as we started overriding the acs() and sls() functions we realised the 90% of the plugin had been re-written.
Once we've got it into production, we'll likely create a new project/plugin based on our code on github. We're also using Ionic to deliver a hybrid native mobile and browser app and have it working using SAML SSO through our laravel implementation. So we'll likely bundle the core parts of that into the project in case anyone else is trying to do the same.
@jmtech-online That sounds really interesting. I need this for a similar setup. Can you share the code so that I can have a look? Thanks :-)
I had the same need so I used the fork from nirajp https://packagist.org/packages/nirajp/laravel-saml2 and it does the job ^^
We have a fork running where I basically rewrote the entire package, yet made the endpoints compatible with the existing package - https://github.com/dwarfhq/laravel-saml2/tree/multi-providers
The multi-providers branch hasn't been merged yet since it's still WIP, and readme needs to be updated as well.
I've forked the repo and implemented multi-tenancy support, I hope that would simplify things for someone :)
https://github.com/24Slides/laravel-saml2
I needed this too, and found nirajp/laravel-saml2, a fork from a few years ago that added support for multiple IdP config by changing it to not be a singleton.
But it got quite out of date with this upstream project since then, and specifically I needed PHP 7.1/7.2 support provided by onelogin v3. So I re-synced it with the latest from this repo and made the changes needed to be up to date with new features & configs added in the past few years.
@aacotroneo, would you have any interest in merging nirajp's fork back into yours? I see there's folks who have done large rewrites, which is fine. But his fork is more like minimal changes needed to support multiple IdPs, if you look at the diff it's really quite small.
I'm asking because:
- I can see there's other like me who have a laravel stack and need multiple IdP support
- Your project is far and away the main one library for saml2, but wasn't designed for multi IdP
- nirajp's fork is "small changes" to yours, to get multi IdP
- Right now is a great opportunity since it's synced up
- If you wanted to accept the changes, it would really "simplify the saml2 landscape" for laravel devs.
If this interests you, I'd prepare a PR - the only additional changes needed is in a couple of places where "aacotroneo/laravel-saml2" was changed to "nirajp/laravel-saml2" and would need to be changed back.
Also if you're open to the PR, you could also indicate what version number you'd like it to have. It's a breaking change on the config side, so I wonder if you'd want to make it a bump to 2.0.0 so that consumers of your library would not get upgraded unexpectedly.
Let's do it! interest on this feature surely has grown a lot and I never thought the solution was that easy while preserving the spirit of the library. Props to @nirajp and you @darynmitchell for putting it all together. It deserves 2.0! Open the PR and publish here so everyone else has a chance to comment and then we merge it. Thanks a lot!!