One interesting dilemma SaaS presents is the lack of association of the user’s identity from the SaaS application, to the enterprise – meaning your employees, business partners or just about anyone with the userID and password for the app are able to get into the app. SaaS platforms have tried to improve the security around this access by multi-factor authentication, monitoring the client system and prompting activation mails if access is seen from new devices etc. Each platform has its own way of providing additional layers of security, and in more cases than not, there really aren’t any options available. So long as someone has the app userID and password, chances are they can login and access the application.
The increasing use of SaaS applications means that more and more business critical information is getting posted out on platforms outside the purview of corporate IT. That is just the nature of things, and something that we can either fight (which will get us nowhere – because SaaS apps aren’t going away) or embrace by adding the required measure of control. Consider examples of data collaboration sites, cloud drives for storage, or even apps with sensitive company data – which in the wrong hands, could really hurt the competitive effectiveness of organizations. One could try and build processes – such that a user’s termination/ separation from the organization has a tightly coupled sequence of steps to identify all the external applications the user had access to, and having the owners of those apps disable the user accounts. The process can also mandate that this has to happen within a certain time interval – and to close the loop, the application admins have to confirm that accounts have been disabled. One can imagine the efficacy of such a process when multiple people are involved, multiple apps are being used, and users are constantly entering and leaving the organization. Even with the operations teams’ best intentions – external account de-provisioning gets delayed – so there’s this window of 1-2 weeks from the time the person has left their previous organization, to the point where all their ex-employer application access gets turned off. I can see several heads nodding in agreement out there – especially our well-loved friends from competitive intelligence.
Now consider this – what if the users accessing external applications never knew what their passwords on those applications were – and all account management was done by OpenCloud Access. If the application supported SAML, then OpenCloud Access only issues the one-time SAML assertion for users to login to the application – only after validating themselves using their directory credentials, enterprise issued 2nd factor etc. The application doesn’t support SAML? – No problem, OpenCloud Access will work just as well with password based apps too. This type of aggregated application access provides organizations the single switch, required to disable all application access – internal and external, simply by throwing that switch and disabling the root identity. When the user’s directory account gets disabled, OpenCloud Access immediately connects into the long list of applications that the person had access to, and disables user accounts within those applications. Imagine being able to sleep peacefully at night – knowing that an employee left the organization at 4pm today, and as of 15:59:59, all of their application access was blocked.
The skeptics of this approach will obviously call attention to the fact that someone who is intent on compromising confidential data can do so in any number of ways – from copying items onto personal storage, leaking out information, printscreen keys, cell phone cameras – the list goes on. The idea with OpenCloud Access and centralized de-provisioning is to block the most obvious open holes that we see today. For layers of additional security, on top of simple account disabling, we have other tools and technologies – which is where solutions like XenApp and XenDesktop come in