It’s hard enough to think through all the security and compliance issues of a cloud move at the macro level during...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
the planning phases of a complex deployment, but the details of the technical “plumbing” can lend their own complexities to the process. One area of particular challenge to organizations from an architectural standpoint is authentication, but add cloud authentication issues like single sign-on (SSO) to the mix, and it becomes even more challenging.
Firms invested in SSO that are considering moving to the cloud -- or firms that may wish to invest in SSO in the future -- need to consider a few key architectural questions ahead of time to make sure they don't save money in one area or gain flexibility by moving to the cloud only to offset these gains as it relates to their SSO investments.
The drive to reduce passwords
Even if an organization hasn’t invested in a large, expensive SSO system, chances are still good that they have an economic stake in SSO. This comes about through incremental investments made over time to narrow the password base. Since passwords cost money by increasing support calls, offset security investment by encouraging password reuse, and decrease user satisfaction,, there’s an industry-wide desire to reduce the number of passwords. This pressure translates to consistent, incremental decisions to integrate new technology into the existing authentication infrastructure.
For example, consider a hospital looking to deploy a system that provides physicians access to patient test results via a Web interface (a fairly common use case in the health care sector). One of the products it evaluates uses Windows Domain authentication (i.e., Active Directory); it allows physicians to authenticate using domain credentials. The other product supports proprietary credentials, putting into play a new password the physician will need to remember. Obviously, the first model (using AD) has advantages: provisioning costs are lower, help desk support is reduced and users are less irritated. Even if the hospital picks the second system, it may choose to invest resources in customization to leverage credentials they already have. Either way, the focus is on reducing the sign-on footprint.
Now what happens when the server supporting that product is virtualized and put into the cloud? Will authentication still function the same way? Depending on the cloud model in use and your planning, authentication might not tie together as seamlessly after the move as it did before. For example, a straight “physical to virtual” replacement of an existing device (a scenario fairly common in an IaaS deployment) might preserve the authentication model without interruption, but other scenarios such as movement of the application into a PaaS cloud might not.. The point is, authentication is technically important and must be specifically addressed as part of the planning process. There are key architectural decisions that need to be made to make sure service continues uninterrupted.
Technical preplanning: cloud authentication
Just like you would address the high-level compliance and security requirements of a cloud move before you start the move, so also is it imperative to address authentication as part of that pre-planning.. There are so many different possible variations of cloud technology (IaaS, PaaS, SaaS in public, private or hybrid models) that the specifics will vary greatly according to use case, and planning can change mid-stream. However, no matter what model you choose to employ, systematic analysis of the current authentication “ecosystem” is critical to understand what could be impacted..
Like most things, this planning starts with an inventory. You’ll need to have an accurate accounting of what’s in place now and how pieces tie together in order to make sure your planning accounts for each and every application that’s slotted to move to the cloud infrastructure. There should be no surprises when the time comes to actually make the move. In particular, organizations should take note of:
- Authentication principals -- Who are the users? Are they only internal employees or are there external entities as well that need to be authenticated? Internal employees are probably a given, but also consider external vendors or partners that may need access.
- Authentication providers -- What is the source of user account information? Active Directory is a common one, but are there other user data repositories as well? This could include Web-based SSO systems (OpenSSO, CA Technologies), in-house developed authentication systems, as well as cloud-based authentication providers.
- Authentication consumers -- What is being authenticated to? What will need to make use of authentication providers? This could include everything from applications, servers, databases and individual application subcomponents.
- Authentication methods -- How are users authenticating? Where is two-factor required and how is it currently implemented? What specific technology is deployed to enable authentication? This might include RADIUS servers, other authentication technologies like servers supporting two-factor authentication, certificates (for example, for inter-component authentication) or even AD credentials.
- Provisioning flow -- How is access provisioned? How do authentication credentials get created?
Obviously, this is a lot of data to collect, but thoroughness is key. As far as how to collect the data, technical conversations with application and system SME’s is one way, but that can be overly time-intensive given aggressive cloud implementation timelines. Other documentation can be leveraged to round that data out, such as application inventories or artifacts generated from the business impact analysis (BIA) phase of BCP/DR planning..
Once you have this data collected, technical dialog with your cloud provider about how it will support your particular use cases is in order. Depending on what technologies are in scope, discussions with your provider can help steer your toward (or away from) service offerings they provide. For example, if you need two-factor authentication and your current architecture doesn’t support that easily given what (and how) you plan to move, your vendor may offer technical service offerings that may help fill the need.
Finally, once you’ve compiled the inventory and made sure you’re leveraging (or at least evaluated) any technical service your provider may offer, next begins the harder work of the technical heavy-lifting. Compare the list of applications that are moving to authentication providers and provisioning flows to make sure authentication can continue uninterrupted (ideally without breaking current integration). This may sound like extra legwork, but it’s better to find out before a move that an application’s authentication model will break than finding out afterwards.
About the author:
Ed Moyle is a senior security strategist with Savvis as well as a founding partner of Security Curve.