This Week At Call Theory
Enterprise SSO support for Mission Control!
Before we jump into the meat and potatoes, here's what's going on at Call Theory this week:
- Tuesday (today), 3pm Eastern - Office hours for call centers
- Thursday, July 4th 🎆 - No scripting sessions this week
Office Hours is a place to bring any technical or scripting topic you can think of and work or talk through it together with Call Theory in a group setting with other customers.
With no Scripting Sessions this week due to the July 4th holiday, you should bring any script questions you have to office hours on Tuesday!
Now, onto the fun stuff!? (It's rarely fun, sorry.)
Better Emails Custom Templates
Custom email template support is now available - have your own developer/designer create a template, use one of our pre-built options, or have us custom design a template to match your brand!
SAM L. Jackson
If you've ran across JSON discussed in the wild - say, at a conference - there will inevitably be someone who calls it Jason: like the person's name. For those of us cursed as technorati - hearing "Jason" when referring to JavaScript Object Notation (JSON) will typically put a quirky smile on our face.
Call Theory recently added Service Provider SSO support for SAML2.0 applications in the Mission Control dashboard - but as part of our research and development, we came across a product that we just had to share with all of you: SAML Jackson.
I learned a lot from BoxyHQ's SAML Jackson:
- from UI best practices,
- to general SAML SSO setup,
- and even integration with the Laravel Framework (which is what Mission Control is built-on.)
Ultimately, I ended up using the Saml2 service provider for Socialite, but I wouldn't have been nearly as effective if not for BoxyHQ and SAML Jackson's open documentation.
(Now, the actual fun part?)
"I am sick and tired of these multi-factor logins on this multi-factor security scheme" - Samuel L. Jackson when not using SSO, probably (credits: Jay)
Going a little further back, the references don't end with Snakes on a plane:
"Say 'sign-on' again! I dare you! I double-dare you multi-factor, say 'sign-on' one more goddamn time!" - Samuel L. Jackson, probably (credit: random Reddit user)
We are bordering on inappropriate, so let's go ahead and move on...back to SAML SSO and Mission Control!
Mission Control SAML Support
We've tested against Google Workspace and Microsoft 365 (Entra ID) SAML SSO options with great success: supporting both IdP and Sp initiated login flows.
The IdP/Sp thing just means that you can put a login link directly in your Identity Providers application list, or get in from the login page of Mission Control - both using the same configuration.
Currently, The givenname, surname, and emailaddress SAML Attributes are passed as assertions and synced with user accounts within Mission Control, but we're hoping to bring more customization to this in the future.
We are also planning for automated provisioning through the SCIM protocol to cover groups and other directory attributes for zero-touch creation, assignment, and removal of users from Mission Control.
In conjunction with SAML support, we've also greatly expanded the user-management side of things, allowing a systematic overview of Users & Teams, instead of individual team-based management interfaces.
The SSO Tax
But look, we have to talk about SSO (again.) More specifically, we have to talk about the SSO Tax: the idea that SSO is a major differentiator for enterprise purchasing and therefore is often hidden behind expensive enterprise plans.
Call Theory fundamentally rejects this model - and as a result, SAML-based SSO is available at no additional cost for all Mission Control customers. We are also adding the aforementioned SCIM 2.0 support for all Mission Control customers at no additional cost.
In fact, we don't charge for individual features or utilities made available to the Mission Control dashboard - and if a feature requires a 3rd-party provider, you can bring your own account.
Open, Source Available?
I want to take Mission Control back to it's open-source MIT-licensed roots - so I'm evaluating the Functional/Fair Source License options that have recently gained traction.
Essentially, it boils down to:
- a fully source-available...
- commercial non-compete license,
- that reverts to fully-permissive MIT after 2 years
From the Functional Source License website:
What can I do with FSL software?
You can do anything with FSL software except undermine its producer. You can run it for almost all purposes, study it, modify it, and distribute your changes, including proposing improvements back to the producer. After two years it becomes permissive Open Source software under Apache 2.0 or MIT.
I'm still a ways away from making a licensing decision, but this would effectively allow me to reject (read:litigate) third-parties from re-selling the product until after the 2-year DOSP (delayed open source publication.) Anyone else could use it first-party immediately.
What are your thoughts on licensing? Does it even matter to you? Hit reply and let me know.