saml

SSO Enterprise: Future-Forward User Management For Your Trello Team

Posted on by Emily Chapman
Providing lots of manual controls and settings can be great for admins of teams who want to customize their workflows. As a company creeps over 100 employees, however, manually setting up accounts for each new user on every single service can become tedious and inefficient.

IT Admins can’t keep track of every tool and maintain its security for every employee of a large company. Lucky for them, they don’t have to. Learn why SSO and SCIM and other fun acronyms are a boon for employee security, and bulk actions make transitions a breeze.

Read the rest on the Trello blog

SAML 2.0 for the Quasi-Technical

Posted on by Emily Chapman

I’ve recently begun the process of transitioning over to a role as a Technical Account Manager at Trello. What this means is—as with all “you’re the first person to do it” roles at startups—a little bit TBD, but for right now it involves being the point person for Single Sign On (SSO) implementation for our Enterprise customers. SSO allows our customers to set up their own login portal for all of the services that their employees use. That portal handles credentials, meaning that end users only have to remember one username and password combo (as well as providing an easier way to disable access to those services if someone leaves the company). It’s the business equivalent of using the “log in with Facebook/Google” option you’ll see on many websites.

SSO can be implemented with a few different protocols, because the internet is full of slightly-different wheels. I’m learning about Security Assertion Markup Language (SAML), which has two versions: 1.1 and 2.0. The SAML protocol provides a standard for how to format XML passed between an Identity Provider (whatever a company is using to keep track of its users and their information) and the Service Provider (Trello, in this case). Trello’s SSO implementation is (currently) Identity Provider (IdP)-initiated SAML 2.0. This stands in contrast to Service Provider (SP)-initiated SAML, and the non-SAML alternatives.

As part of moving in to the new role, I wanted to read up on SAML and get a general sense of how the protocol actually works. This was to help reduce the number of times I needed to go to engineers for communication reasons—because I didn’t know what the user was talking about when they mentioned federation and they didn’t know which cert I meant when I asked for an SSO cert.

(For the record, the cert I needed in that particular instance was a Base64-encoded X.509 cert. Hat tip to Amanda Allison for teaching me to recognize base64-encoded strings by sight/the basics of “certs, what do” and to Barry Clark for telling me the “X.509” bit.)

Unfortunately, trying to educate myself about SSO—and SAML in particular—proved very difficult. The resources that exist are mostly targeted to two audiences: end users at large corporations who need to know a bit about how their particular SSO product works (too low-level and IdP-specific for me) and developers with an interest in cryptography who are actually building SAML integrations (impenetrably dense, and way higher-level than I needed).

Continue reading →