Many of our customers are implementing or considering the implementation of hosted application services (aka SaaS). The benefits are obvious because your support burden is reduced whether that be due to increased resource utilization, hardware savings, software savings or otherwise.
For the sake of this article, let's use the example of implementing hosted email services by Google. Google Apps is a great solution for commercial, non-profit and public organizations. The Google infrastructure is better than most organizations could provide themselves. Your internal customers have 24/7 access to their email, calendar, docs and other services provided by the Google Apps offering. As an IT department, you no longer maintain your email infrastructure. You no longer have to keep internal resources trained on your email system and you can now take back those resources that were dedicated to supporting email and reassign them to other projects. All of this is great and seems like a no-brainer for many organizations.
The truth is, you do still have some management burden. Even though you don't support a local email system, you still are responsible for setting up and managing your user accounts for Google Apps. You will still get the call when users can't access Google Apps because they don't have an account, they are disabled or they don't recall their password. Many IT departments are disappointed to see the lack of tools available to automate this process. Google does provide a directory synchronization tool but it isn't perfect. Password management is an all together different issue. Although this isn't the basis for this article, it is worth noting that Identity Automation has a Google Adapter for DSS the can fully automate the management of users and groups in Google. This solution absolutely deals with much of the pain associated with managing Google Apps accounts, but I digress. The point of this article is to specifically discuss passwords regarding hosted services.
Back to our Google Apps example, our adapter is capable of taking passwords from your internal directory service and synchronizing those to the matching Google Apps account. This is a great solution but it can raise security concerns. Google hosts their Google Apps in a high security facility. Their employees are well vetted. That doesn't mean every hosted services provider goes through the same pains regarding security. The alternative? SAML!
Many hosted services providers support SAML for authentication. Google Apps, Salesforce.com, Zendesk and Zoho to name a few. A system that supports SAML as a means for authentication is referred to as a Service Provider (SP). An SP requires the availability of an Identity Provider (IdP). When a user accesses Google Apps (with SAML configured), they will not authenticate directly against the Google servers. Instead the SP (Google in this case) will refer the user's browser to the IdP. Our ARMS and/or DSS products both act as an IdP. The IdP is configured to authenticate users against your internal directory service such as Active Directory. That means when a user accesses Google, to a redirected to your ARMS (or DSS) appliance where they will log in with their network credentials. The same credentials they use to log into their office workstations. Once authenticated, the IdP passes a secure token that tells the SP that you successfully authenticated and informs the SP who you are in its system.
SAML is important to your organization as you move more towards relying on hosted services. Without SAML you are storing credentials in an untrusted environment. You don't always know how those credentials are stored and secured. A user's credentials in these systems likely match the same credentials used for in internal systems. If the passwords in the hosted system are stored in an insecure fashion you've basically exposed access to internal systems as well. With SAML, there is no credential stored in the hosted service providers facility. There is zero risk of credentials being exposed and stolen.
By combining our Google Apps Adapter for DSS and ARMS with the SAML IdP service, you now have a viable option fully automating the management of accounts and providing secure SSO without the risk of storing user credentials "in the cloud".
Comments