And it took a viewing of the famous Star Trek episode called Mirror Mirror for me to best illustrate and articulate the difference between the creation and management of a user account and credentialed rights and the funneled applications that entity is allowed to see. For those unfamiliar with the episode, it’s the one where Kirk is transported into an alternate universe and meets evil Spock (the one with the beard)…but more about that soon.
Simply, IDaaS is the administrative function that creates and maintains a user’s network identity. It segments their privileges by roles and rules. This is called provisioning. Your starship just hired a new lieutenant to communicate with new life and new civilizations as you boldly go places—in this world we call it inside sales, but you get the idea. In the organizational hierarchy, this officer needs access to certain functions and applications-but not others. So when her “enterprise” identity is created, she is assigned certain access rights. She needs to see the languages database, but not the weapons console. Her identity group, as a junior officer, is similar to others of her job description and rank. Identity management establishes her credentials, manages her passwords, and the provisioning synchronizes this information instantly so that a specific level of the network is accessible. This works in reverse as well. As soon as she resigns her commission, automatic de-provisioning rescinds those rights and prevents her from accessing information after she’s left the ship. It’s all based on process and workflow.
So how is this different than access management? If Identity Management is about the development of a privilege strata and the source of password details, why does a company need access management? Because it is the difference between authentication and authorization. it’s the difference between administrative availability and tightly controlled access. Case in point: our communications officer is standing on the planet Saas and dialing into the Enterprise (BYOD!). Her identity settings allow her to access the ship’s computer, but it is her SSO that channels her access see only certain applications. And because access management is about single sign on, once she is authenticated, all of her applications (including the dozens of unique passwords) are controlled from a single portal (and blocked from seeing/accessing other). The single sign on function also authenticates each individual application, so she doesn’t have to do it again once she is within the protection of the portal. And the segmentation of each application is also personalized to her rights automatically. She sees only the slice of the database she is permitted to see. But what if it wasn’t her? What if it was a Klingon who cloned her tricorder or her body was taken over by a non-corporeal lifeforce? Single sign on enforces multi-factor identification. So if her password is stolen, the nasty Romulan might not know the year she graduated from the Starfleet Academy or the name of her first pet was Cochrane. Simply put, IDaaS is the intelligence and SSO is the locked doorway– and they need to seamlessly integrate to create a better security platform. Having one without the other is like transporting into an alternate universe and having to fight an evil Spock. (I told you I’d get to it!)
While looking to acquire dilithium crystals, the Enterprise gets hit by an unexpected ion storm (for our metaphoric purposes, let’s call this a suspicious intrusion resulting in breach!). This causes a landing party to transport (access management) to an alternate universe. In this world everyone looks the same (except for Spock’s Machiavellian beard!), but their intentions are less than honorable. Conversely evil Kirk is now on the original Enterprise. Allegorically, if this were a fully integrated and unified security Enterprise, the SIEM program would have noted the original suspicious activity and Mr. Scott would have received an immediate alert based on the parameters of what constitutes a breach. But if Evil Kirk gets through nonetheless and tried to log onto the system to arm the photon torpedoes, there are a few security hurdles in his way. His alternate universe password of “UglyKittens6” doesn’t work. In fact after several tries, he is locked out and an alert is sent to Mr. Scott for review and remediation. But Evil Kirk is wily. He clicks “forgot password” because he figures he can self-serve and generate a revised password. However the system asks him how many TekWar novels he’s written (or any other personalized information to further verify his identity) and without the correct answer, his evil machinations are again thwarted. However, let’s say the passwords match (“OverActing4#5!”) and he is authorized into the access portal. He may be captain (CEO) of the ship, but his role does not include the direct management of weapons systems, so this application is absent from his portal of available applications.
Silliness aside, the IT moral of this episode is that identities are just a single level of integrated security. That controls WHO you are. As a partner or employee, the enterprise affords you this amount of visibility within the network. Access controls the applications to which you may connect .As most companies use a wide variety of applications—on premise legacy, cloud-based ASP/SaaS or general web-based programs—the need to channel controls is mission critical. This is Access Management. There simply can’t be a login name and password that provides any user limitless exposure to the network. Best practice, regulatory compliance and strong security demand that these functions work in concert.
But best practices that require investment into two separate solutions, two separate deployments with two separate providers, and the extra eyeballs to continuously monitor activity seems to be counterproductive…right?
The fact that SSO and IDaaS are two different solution sets is tempered by cloud-based security deployment. As a singularly sourced seamless operation from the cloud, the pairing increases the ability to control who gets to see what across a heterogeneous enterprise with competing priorities, needs and identity types. Just as partners and vendors need certain access that is separate from employees—not all employees are the same; and they too fall into unique roles and rules that can be managed by identity Management and Controlled by Access Management. There are many solutions on the market that address either IDaaS (IDM) or Access (IAM, SSO) in the cloud, but I obviously know of only one that provides both as a multi-tenant (true-cloud) initiative. This mixes the best practice of best-of-breed with the all the cost and productivity benefits promoted by the cloud.
And if my metaphors and wink-and-a-nod sci-fi geek inferences were too obscure, here is a straightforward listing of the differences between IDaaS and SSO:
Standard IDaaS features (Administrative):
Standard SSO features: (Active Application of Administrative Controls)
Live long and securely prosper!
To learn more about a working solution that incorporates the secret sauce, check out CloudAccess’ identity management cloud based identity management offering