SSO Support for Busy IT Admins 2 — THE LAB
So, that’s it… you’ve been given the weighty responsibility of SSO support for your organization. Or perhaps you’re new to the IAM team. Now what?
This post is the secondof a five-part series on the Fundamentals of SSO Support for IT Administrators.† You can see our first post here, our third post here, our fourth post here, and our fifth post here.
The Lab is Your BEST Friend
No matter what issue you’re facing when it comes to SSO, if you can’t dive into an environment that’s almost like your production environment and mess everything up trying to make something happen, you’ll never be able to manage SSO support for your organization. And there are countless tools, like Docker and Git, that make keeping a lab environment a breeze.
The Lab Should Be Production Lite
If you’re responsible for a load-balanced Shibboleth and CAS dual-deployment environment with two-nodes for each, then no, you don’t NEED to have 4 more server VMs running for the lab. But in that kind of case, it’s entirely reasonable to keep a dev CAS and a dev Shibboleth instance on hand, separated in the same way they are separated in production, but simply not load balanced.
Likewise, if your production server runs on an AWS t2.2xlarge doesn’t mean that a t2.micro wouldn’t suffice. If you’re leveraging a cloud provider resource like AWS already, there’s no reason that you can’t keep your dev instance spun down (but NOT terminated) effectively indefinitely.
Furthermore, when it comes to SAML, the single most important bit of information is the entityID. You can have a dev Shibboleth IDP for example, which is configured with the same entityID as your production environment. Then, so long as you point the DNS hostname of the production IdP to your dev server’s IP address, authentications will occur against that box. That means it’s relatively trivial to test configuration changes (like attribute release policies) BEFORE moving the configuration to production.
Don’t Be Afraid to Break Things
I use git to manage my configs on all of my dev environments which utilize file-based configurations. (Others prefer subversion.) Every time I want to make a new major change (say, experiment with a new, custom MFA provider in Shibboleth) I’ll create a new branch. That way, if I need to, I can just checkout the last working branch and all of my work is still safe and sound in the “indev” (as I like to name them) branch.
Here’s another use case… let’s say you’re responsible for idp.example.org, a Shibboleth IdP. You need to work on onboarding two service providers, Company A and Company B. You can work on these configurations separately within two branches, without worry that changes you make for Company A will throw things off for Company B’s integration. As the integrations start to near completion… you merge the branches separately.
If you’re also leverage git for production, when you’re ready to push the configs live, it’s just a matter of a simple git push to the relevant remote and a restart of Shibboleth (or a call to a reloadable service)
Similar functionality can be achieved in the ADFS / Windows sphere with Virtual Machine Snapshots and Powershell, though that’s inherently a bit trickier.
Next… To the Internet!
Next week… we’ll dive into the standard first action you should always, ALWAYS taken when confronted with a new issue: GOOGLE THE HECK OUT OF IT!
Can’t Wait?
Need help now? Well what would a blog post be without a sales pitch? IDM Engineering is a team of dedicated, honest SSO support engineers that are readily available to help you architect a new single sign on environment, manage or improve existing SSO infrastructure, or just dig in and quickly solve a integration issue. We speak SAML… and OAuth… and ADFS… and SimpleSAMLphp… and more. Furthermore, we have a carefully curated collection of technological experience and expertise that can assist you with whatever single sign-on issue you’re facing. Give us a shot! Let us know how we can help you today!
† Or — how I learned to stop worrying and love XML.
