Co-founder of BoxyHQ here - We've crafted an open-source enterprise SSO because we firmly believe that robust security shouldn't be a privilege limited to large organizations. Ideally, essential enterprise-level features like this should become commonplace for all.
While we acknowledge the reasons behind SSO being in the enterprise tier, we're all on a collective journey to enhance our security measures. Open Core models are indeed a good option (my preference), yet the dynamics vary across solutions and industries. It's up to each of us to explore, experiment, and discover what resonates with our market. In doing so, we can foster growth while maintaining our commitment to supporting the community in the long run.
Well stated. I was merely showing how one could implement an open core strategy. I’m a firm believer in SSO for all (and not limited to social platforms or GitHub).
Hey everyone, Retraced is an audit logs OSS product, that was initially built by Replicated and it has been enhanced by BoxyHQ.
With it you can now give your users the superpower to track every critical event within your product, and get full visibility over their account’s activities on your app. You will also allow them to send security-related events to their SIEM. It would be great to get your feedback.
Key features:
- Compliant audit logs for your product
- Record user and system activities
- Admin UI to view logs. Also embed the viewer anywhere in your product
- Export events to CSV or security systems like your favourite SIEM
- Cryptographically guaranteed immutability of logs with a verifiable digest
Thanks for the insights, have you seen any good practice (tips) on how 'security mechanisms for development' could actually help security teams and developers work smoothly? Instead of being the reason for conflict.
I think the most trivial mechanism is to have your own subnet for developers that maybe has fewer restrictions. Not really a DMZ, but perhaps skip deep package inspections. Most tools can be configured to allow self-signed certs, but it is still a lot of hassle, especially for test systems. In exchange the dev subnet should only have restricted access to the rest of the internal network. But lacking convenience here is preferable to not being able to download some dependencies.
Ensuring the security of a product doesn't have as tangible bragging points as shipping new features. Failing the former is unlikely to be blamed on product, but achieving the latter will almost certainly be credited to them. Responsibility for an insecure endpoint or poorly configured service falls to the engineers, despite the managerial influences that will often lead engineers to cut corners on things like security in the first place.
Sounds like BoxyHQ could be relevant here. Plug-n-play for developers that need to build enterprise features like SSO, audit logs, directory sync, privacy vault and other boring stuff that are required to be compliant.
100% free & self-hosted. It's Open source (Apache-2.0 license)
[I am one of the co-founders, sorry for the plug]
While we acknowledge the reasons behind SSO being in the enterprise tier, we're all on a collective journey to enhance our security measures. Open Core models are indeed a good option (my preference), yet the dynamics vary across solutions and industries. It's up to each of us to explore, experiment, and discover what resonates with our market. In doing so, we can foster growth while maintaining our commitment to supporting the community in the long run.