At the end of October last year, during Boost Day #8, I talked to Joshua Behrens about an interesting Shopware plugin to allow external login providers in the administration panel of Shopware, which he developed on an open-source basis from the beginning. During this interview, I got interesting insights about why one would open-source the code he produced and how to get it listed on Shopware’s Plugin Store.
Interview with Joshua Behrens from HEPTACOM
Joshua, could you please shortly introduce yourself?
Hi Marco, nice to meet you. I am Joshua from HEPTACOM. I was born in Bremen, grew up in the countryside, and am finally back in the city of Bremen, Germany. I do mostly deep-level customizations in Shopware for B2B and B2C scenarios and am working on automations for data transfers.
Alright, thank you. Please let us know what your extension is for what is the main value for online merchants and developers.
The extension adds multiple login options to the administration for self-hosted environments. For example, adding Google or even Microsoft SSO logins to the Shopware admin panel is possible.
This way, the extension solves several issues for us as an agency: setting up, supporting, and onboarding/offboarding user access, protecting against impersonation, and accessing multiple environments with a single login.
This extension made managing and maintaining access for our environments easier. Unfortunately, sharing the same credentials between different environments (production | stage | testing) is quite common in other agencies. Sharing accounts might help onboard new people; however, this practice is never a good idea. For example, if you have to find out who was the actor in certain situations or if you want to limit access to a specific group. Shared accounts should not have administrative rights granted to all users. This helps prevent accidental actions and streamlines the user administration process by limiting the range of available actions.
Talking about onboarding, we have an onboarding process for new employees in our company. Part of this is to gain access to our centralized account management. With this at hand, we control access to all third-party services we have in place to support our daily work. For an administrator of a company, it is very simple to manage accounts for a person at a single point: the Identity Provider. Everyone here is used to clicking "Login with ..." or "HEPTACOM Login." Our clients obviously notice this extra login option in the administration and often get their own "Login with ..." button. This way, our clients (AKA online merchants) also gain more power in their user management.
Not only for our projects, but we could also minimize the number of necessary actions during the setup. In addition, we also receive positive feedback from other agencies and in-house developers at merchants who are also using it.
Got it, thanks. And how can I buy or install your extension?
Actually, that's very simple: Either install it from the administration panel of your Shopware installation (as you can install extensions listed in Community Store from there) or – if you are a bit more into development – use Composer to install it directly from packagist.org.
Is there any reason why it is only for admin logins, not for users/visitors of the shop?
That's an interesting question. Extensions such as "Login with Apple" or "Login with Google" for storefronts can already be found in the Shopware Community Store. However, as far as I'm aware, no extensions are currently available for providing these login options within the administration panel. There are specific reasons for this.
I imagine why this question popped up: “If you can do that for the one login – why not for the others?” It feels the same for a person clicking on the login button, but the management for both login types have totally different complexities. Visitor logins, in general, are covered by social logins that may supply, for example, email addresses, payment information, or other data. Looking at logins to the administration panel, this cannot simply be allowed for everyone, as one first has to check identity verification and access control. You often find the buzzword “Workforce Identity Management” for this topic. Changing the login in the administration also has an added level of complexity as, for example, extensions are not automatically loaded in the login mask.
You said the plugin could be installed directly via composer via packagist.org, right? As far as I can see, you set this extension under an open-source licence. Why did you do that? I mean, couldn't you earn a lot of money by selling it?
To provide some context: Uploading this extension to the Shopware Community Store could have generated income for us. However, our company primarily earns revenue through projects, and we don't aim to become an extension provider, as it could lead to additional support requests. Therefore, we decided to release the extension for free under an appropriate open-source license.
Additionally, open source is an important topic for us as a company as well as for a personal incentive. Let me add some pieces about my career to highlight the motivation: I used to work for a vendor of closed-source software, which sometimes followed the rule of "security by obscurity: if no one can read the source, it is less likely to break”. Since then, I am tending to accuse proprietary software of being less quality.
While taking part in open-source projects like Shopware v5 and v6, I got more options to contribute my thoughts and even pieces of code back to these projects. Real discussions with other community members and with the vendors on an eye level seems to be a gain for all parties. It is about learning, feedback, and making people talk to each other. Developers with deeper knowledge may investigate your code, eventually improving software quality – and your understanding of code.
We released our extension under an open-source license, allowing everyone to use, modify, and create new interfaces as they wish. As is typical in the FOSS (Free and Open Source Software) community, we encourage developers to contribute back by submitting pull requests to our repository, enhancing the extension's value for everyone.
Besides what I said before, with this attitude, we increasingly put ourselves into a top-dog position when it comes to high-quality open-source development.
That’s what I call generous :-) And why did you choose the Apache 2.0 licence over any other OS licence, is there a certain reason behind it?
Making a licensing decision is a challenging task. Eventually, we intentionally chose the Apache 2.0 licence because it – as the only OSS licence – does not include a copy-left. Instead, a NOTICE file (see §4 d) for documentation of all changes is required. This might facilitate the life of initial project developers as well as this of developers to take over the project.
I cannot give legal advice, but if you have to choose an open-source license yourself, I recommend checking out choosealicense.com, which is very helpful for comparison, even before asking for legal advice. Make sure your chosen license is compatible with Shopware’s MIT License.
Where to start with it? How to join this project? How can somebody else from the community contribute or resolve bugs?
There are just a few steps, and most of them look already familiar if you contributed to Shopware before: fork the project on GitHub, change code, sign the CLA (contributor license agreement), and create a pull request with a meaningful description. We will be happy to take over the rest.
As far as I understood, the module is finished in a manner that “can be used in production.” Which Shopware versions are supported, will there be further development or new features in the module?
Heads up: we are already preparing this extension for the upcoming v6.5 release. Like I said before, it is not our source of income. However, it affects the simplicity and convenience of our daily work, and therefore we develop this extension continuously along with the latest changes in new Shopware releases.
Moreover, we do not ditch old releases. Hence, you can still use the basic features since our first release for Shopware 6.2. Since the initial commit, we have used it in production for almost three years by the time of this interview.
As for our next steps, we are presently working on integrating the rule builder in a manner that can control ACL assignments for users. With the latest release, you can achieve this behavior by creating multiple login buttons with different ACL assignment settings. And in the future, we want to apply ACL by assigned groups in Microsoft Active Directory or simply by email-address. For this, we have already put our hands on a SAML integration, which will be released soon(ish). With SAML, IDP-driven ACL could be set up in a smooth way.
How to get support for this extension? Can I call you if I'm not able to correctly install the plugin?
The extension comes under an open-source licence which, in general, does not include support or any warranty. Of course, you might give us a call or drop us a message with your enquiry, but we will have to name a price for it.
However, it is very unlikely that you need installation or setup support as the extension is well-documented in the repository and Community Store, including setup instructions, and setup is really easy to handle by design - actually, you can’t make anything wrong. If you have questions or need help in any regard, you may look into the Shopware forum - there are many helpful people.
How did you manage to get this plugin listed in Shopware Plugin Store? Am I not responsible for support and maintenance if I want to do so?
The Shopware Community Store only requires extension manufacturers to offer support, if the extension is subject to charge. Hence, for a free plugin, there is no obligation for support or maintenance.
However, you would still have to have a confirmed company account – which, in our case, was not a problem as we are a Shopware Partner already.
Thanks for this interview, Joshua. I very much appreciated it. Cool insights.
And I thank you for this interview too, Marco. See you at the next onsite event, which will likely be SCUC 2023 for me.
