Separate libraries (IdP / SP) and no UI

[gitgitwhat]

Is your feature request related to a problem? Please describe.
This is a great project but it's way too bloated to be integrated into anything but a demo. While the saml2 library is available, you even make the point to tell people to not use it and with the lack of clear examples and documentation, it's difficult to even know where to start.

Describe the solution you'd like
Separate, independent libraries that focus on each side of the SAML solution. In my case, I only care about my project acting as a SP. I don't want or need all of the IdP code.

It should also be free from any UI.

Describe alternatives you've considered
I'm currently hacking my way through trying to figure out how I can separate only SP code into something I can integrate into my app along with changes to support multitenacy and cross-domain requirements

[thijskh]

I get the use case, but at the same time do not fully understand how the presence of the other parts that you do not use hurts you. Any library you will use will have functionality that your app doesn't need?

[jaimeperez]

Hi @gitgitwhat

SimpleSAMLphp is used all over the place to add SAML support to PHP applications, so definitely not just for demos. That sounds like a very light assessment, to be honest.

I believe you are also completely missing how complex and big SAML is, and that becomes obvious by the fact you don't know how to use the SAML2 library alone. That proves indeed that our recommendation to not use it directly is right. If you can't use the SAML2 library to implement whatever you need, that means you don't know SAML enough to do it securely anyway. SimpleSAMLphp abstracts all that complexity for you, so that the only thing you need to do is follow the documentation to install it (and use it) and move on to something more profitable. If there are things in the software that you don't need, you can just ignore them.

Using SSP in a multi-tenant environment is quite simple, too. You just need to integrate with your app and take advantage of the fact the configuration is PHP code to dynamically configure the baseurlpath option, and use the appropriate domain (or even path) for each tenant. This has been possible forever, and I was already doing that successfully 15 years ago. Back in those days, by the way, SSP was way more bloated since it included all modules in the base distribution. We stopped doing that years ago though.

You are also missing the point about the UI. A user interface is unfortunately necessary for multiple standard use cases, even when used as a service provider (e.g. a discovery service where users can select their IdP, or even the Single Logout interface, which will only really work when you have an actual UI). Sure, you may not want to use SLO, and you might have just one single IdP, but your use case is not necessarily the most common, and the whole point of SSP is to make all those things easy for the vast majority that needs them, not to cater exclusively to your basic needs.

Still, you have a point, and that's why I added it to the roadmap many years ago to have separate software products for SSP acting as an SP, IdP, or proxy (which would be the current product) in version 3. We just managed to release version 2, though. Such development, as you may have noticed, requires a significant amount of work, which has been very low priority given the lack of resources we've always had. The good news is that this is Open Source software, meaning you can not only take advantage of the altruistic work of many people and use the software for free, but you can also contribute back to it with whichever features you may want. Given this is a feature that has been part of the roadmap for that long, you'll be happy to know that your contribution to achieve it would be more than welcome! 😄

[gitgitwhat]

Hi @jaimeperez

Apologies for not giving the library its due. That wasn't my intent.

I understand SAML well although I'm no expert, but when a developer says "don't use this" that makes me question the product.

In terms of the UI, I understand a UI is required but SSP's UI (with Twig and all of the other pieces that make it work) is not and it's difficult to integrate with my own UI and workflows when there's a whole different templating system involved.

SSP could still abstract the complexities away but without such tight couplings with others pieces and allow for a more dynamic setup. Glad to hear that it's on the roadmap. If I can get this to where I want it to be, I'll be happy to contribute it back to the community.

@thijskh To answer your question, unused and dead code should always be removed. It's attack surface reduction, improves maintainability, etc, etc. If more parts of the library are not being used than are, then to me that's a problem.

[peter-]

In my case, I only care about my project acting as a SP. I don't want or need all of the IdP code.

It should also be free from any UI.

Seems like François' https://www.php-saml-sp.eu/ is what you want, then.

[tvdijen]

Either that or invoke our saml2-library directly

[cancan101]

I also think publishing some of the utils as their own library could be helpful. For example:

• https://github.com/simplesamlphp/simplesamlphp/blob/master/src/SimpleSAML/Utils/HTTP.php
• https://github.com/simplesamlphp/simplesamlphp/blob/master/src/SimpleSAML/Utils/XML.php

You end up finding people copy and pasting them in, e.g. https://github.com/sabir-jamia/saml-bundle/tree/master/Utils

and even the SSPcontainer: https://github.com/sabir-jamia/saml-bundle/blob/master/Service/ContainerService.php

And you have already published some parts as libs: simplesamlphp/xml-common.