Why Higher Education Institutions Need Virtual Identity Providers

By Dan Dagnall, Chief Technology Strategist

Federation is definitely a hot topic these days, with NSTIC attempting to create an identity ecosystem, InCommon continuing to build its federation of service providers, and state-level initiatives gearing up (some are already active) to provide federated identity services to 4-year schools, community colleges, K-12, and every entity in between. But I’ve found that many schools and institutions are not prepared to commit to the rigorous list of technical requirements to enter into such federations. This is primarily because of a lack talent, lack of budget to obtain the talent, and resource utilization constraints.

There are other potential roadblocks facing institutions that choose to walk the federated identity path. The standard model of requiring a unique Shibboleth installation (which by default would provide a localized IdP login screen including a custom URL for the login screen) is simply not appropriate for smaller colleges and universities that can’t afford to hire more technical talent. It’s also not feasible for K-12 as it would require technical resources to be located at each school.

A virtual identity provider (vIdP) model is the best option for institutions that don’t currently have any SSO capabilities as it eliminates 90% of the technical federation hurdles placed on entities. This model will resonate well with smaller colleges and universities, K-12, and any other entity that lacks the key components to enter the secure world of federated identity management. The only difference between a virtual IdP and a localized one is you will spend half the money and spend 90% less time to deploy a virtual IdP. There is no reason why entities falling behind in the federated world should not consider deploying a virtualized IdP.

The virtual IdP model provides economies of scale to reduce costs by securely sharing resources among multiple institutions. In contrast to local IdPs that require one or more instances of Shibboleth software to be installed for each institution, each with its own set of metadata to be configured, and each of these with its own maintenance by technical specialists, all of which add to costs, the virtual IdP model is far simpler for institutions. A virtual IdP needs only a single installation of the Shibboleth software and a single set of metadata to accommodate multiple institutions, which dramatically reduces the on-going support of distinct IdPs per entity. It is also important to note that the Shibboleth software does not reside on campus, thereby eliminating the need for each individual campus to have any [technical] federation knowledge at all. Institutions that lack talent, time or both are no longer locked out of the federated world in the virtual model. In fact, if success looks like massive uptake of federation, then using virtual IdPs is the best chance for success.
However, every new technology has its critics: Some people believe that the federation identity provider (IdP) should always be local (i.e., on campus) as opposed to leveraging the cloud for IdP services. Maybe this is because some in the industry are not yet comfortable with a virtual approach out of a lack of understanding regarding security and risk for a virtual versus an on-campus IdP. I’ll address their concerns one by one.

Some critics claim that a vIdP is not secure, but security issues for a virtual IdP are no different than for a localized IdP deployment. The same underlying protocol, SAML, is used; therefore the same security mechanisms are in place, the same configuration is in place, the same platforms are leveraged, the same application set is accessible. And service providers hosting vIdPs are often more secure and provide higher availability than many institutions can achieve locally.

Some critics argue that a virtualized IdP is never feasible because they believe there is a lack of branding. But, virtualized IdPs can be branded the same as local IdPs, and the user experience for the virtualized login process is just the same as the fully-branded and customized local IdP model.
Some federations do not want to allow virtual IdPs into their trust models, presumably because they don’t believe that virtual IdPs are as trustworthy, or possibly the federations don’t understand the implications that vIdPs have (or don’t have) on their business trust models. In reality virtual IdPs are often more trustworthy from a technical perspective than a local IdP model: The data center is more secure, access to the data is more secure, I could go on. And from a business perspective, although the technical aspects of a vIdP are outsourced, business agreements are not outsourced, and the business trust model remains unchanged and between the same parties.

Some critics advocate for localized IdPs while at the same time supporting internal deployments of dirSynch or Google’s synch process to provide cloud-based email services to their user populations, which stores user data in the cloud. So if the issue is related to where the data is stored, then their logic is flawed as they are advocating both sides of the same coin and are essentially cutting off their noses to spite their faces. Maybe their real issue is that reporting actual IdP installations looks better to some people than adding the same number of institutions on virtualized IdPs? Maybe their issue is simply attempting to undermine commercial solutions in the name of their own pet open source initiatives?

Truth be told, virtual identity providers scale much better than localized IdP / federated infrastructures. Virtual IdPs are just as secure and trustworthy, and are more cost effective for the institution tasked with federating their users to access service providers.

My advice to you would be not to discount a virtualized approach. A virtual IdP can be up and running quickly, it can be configured easily, and your users will be federated in a fraction of the time it takes to stand up your own infrastructure.

Cloud-Based Identity Management: Best Practices for Rapid End-User Adoption

By Glenn Choquette, Director of Product Management.

Executive Summary
Identity Management (IdM) is not new. Yet after all this time on the market, organizations still have mixed results for end-user adoption, as many organizations that rolled-out IdM years ago still haven’t achieved their goals: end users keep calling the help desk to reset passwords, to request accounts and to perform other tasks instead of using the self-service identity solution. While most organizations have diligently assessed vendor offerings, fewer have adequately planned how to achieve their utilization objectives. Many organizations assume that end users will automatically start using their IdM solution without any planning or incentives, but that’s proven to be false. With user acceptance rates ranging from under 5% to nearly 100%, it’s clear that successful IdM rollouts don’t just happen:  They involve executive sponsorship, planning, education, setting measurable objectives, metrics, and a variety of “incentives” for achieving the goals. Fortunately, these activities will improve user adoption when launching, or even when “re-launching” IdM.

Introduction
Best practices for your organization depend on a variety of factors such as its size, culture, geographic distribution, which applications are in the cloud or on-premise, types and diversity of users, previous rollout experiences, the chosen IdM solution, etc. A combination of planning, education, metrics and incentives has proven to maximize both the quality of the end user experience and financial benefits of IdM. Like all projects that involve significant change, executive sponsorship and active executive participation are critical to success.

Planning
The first step to planning for rapid user adoption is to understand the capabilities of the chosen solution. Plan to automate as much of the setup as possible to avoid end user inertia. If your solution supports it, plan a transition acceptable to your corporate culture that requires the use of the new solution.  If automation isn’t possible with your solution, simplify the registration process as much as possible and increase your use of incentives. Your end-user adoption plan should consider your organization’s IdM objectives as well as the potential costs and risks of each aspect of the plan.

User Awareness
In most organizations, users tend to delay change until they are absolutely convinced of the benefits for themselves; fortunately, IdM has a lot to offer end users: single password to remember, no more waiting in the help desk queue for password resets, no forms to fill out to request access to resources, etc.  So, don’t keep it a secret. Market the benefits of IdM before launch. Make users aware of how their lives will be easier.

Metrics and Incentives
Metrics and incentives are pivotal to success and provide ongoing leverage for continued attainment of objectives. They can become your best friends in achieving rapid user adoption. Just as it’s important to “sell” the expected benefits to the user base prior to launch, it can be even more important to keep the momentum going by communicating the observed benefits after launch. If non-IT leaders haven’t already been sold, you’ll want to reach out to them to help carry the torch, as it’s in their own best interest to do so.

Fortunately, compared to legacy IdM solutions, modern IdM solutions achieve faster user adoption with fewer end-user incentives as users face fewer obstacles and are able to clearly see the benefits of using the solutions. Setup activities occur naturally during friendly IdM processes such as receiving new accounts and changing passwords. As more people in the organization become aware of the success of IdM and what it means, both to themselves and to the bottom line, your user base will begin to sell the solution for you. Soon, your modern solution will become the organization’s norm and the unbelievers will be viewed as laggards, under peer pressure to join the team.

Conclusion
Identity Management solutions and implementation methods have improved over the last several years. Whether your organization is new to Identity Management or implemented a solution years ago but is experiencing inadequate utilization, proper planning and execution of solution launch (or re-launch) activities can improve utilization rates.

Identity Management: Faces in the Cloud

Fischer solutions discussed in Campus Technology article “Identity Management: Faces in the Cloud.” Coppin State University CIO discusses why they moved from an on-campus solution to identity management in the cloud: speed, simplicity, security, cost savings, etc.

The Cloud is a Great Answer for Identity Management at Small and Medium-Sized Organizations

By Dan Dagnall, Chief Technology Strategist

Small and medium-sized organizations (SMBs) face many of the same challenges and complexities as larger organizations, but they don't have the same resources to pursue solutions to their challenges. Identity management is a case in point as it can be very expensive, and the more custom the solution the higher the cost to deploy and maintain it.

SMBs are forced to get the biggest bang for the buck with strategic purchases primarily because revenue generation is not as predictable as it may be for larger, "more stable" companies in the Fortune 500. Given that there are many more SMBs than huge organizations, it is essential that SMBs are able to use an off-the-shelf approach to identity management, as building custom solutions is like trying to repeatedly reinvent the wheel for each SMB.

Building blocks
This is not to say that SMBs all need the same solution, but that the fundamentals of deploying such services do not change across industries, and SMBs can configure building blocks that already exist to handle the solution rather than creating custom solutions.

Traditional identity management has long been thought of as non-predictable in terms of scope of effort for deployment and maintenance, which doesn't scale well for limited budget, fixed-price constraints attributed to the SMB market space. Unlike some larger organizations, SMBs do not have the luxury of doing "whatever it takes" to provide the solution needed. SMBs need best practices with predictability, finite projects timelines with clear goals, and a finish line that doesn't move.

Typical identity management deployments cannot provide this level of predictability, specifically deployment models that start with a blank canvas and provide little direction other than which programming language you should use. These types of deployment models don't scale for the SMB space. The message for these types of models is, "you can do whatever you want when you write your own code." Sure, this is true, but only if you have a rather large budget for deployment consultants and even larger staff budget to support and upgrade the solution.

Cloud-based identity management
SMBs should consider cloud-based identity management as it can deliver required capabilities without the high costs of traditional script-based on-premise solutions. A cloud-based solution can accommodate the primary SMB drivers for procuring identity management: increase security, increase productivity and decrease cost.
 
"The cloud," as it has been coined, is definitely more than a potential cost-saving option at this point. It is the most impactful method to lower your operating costs while maintaining or improving service levels to your user community.
 
First, cloud-based services include the entire software stack, which may include automated provisioning, role management, self-service portals, self-service [automated] password reset, as well as audit/ compliance and governance controls.

Second, because it's a service, SMBs can subscribe to needed services, rather than licensing an entire product suite when requiring only a fraction of it to address specific needs. Simply outsourcing the administration around such a large stack of services can save significant staff (including help desk, as well as server administrators like DBAs, etc).

When you also consider the laundry list of infrastructure required to support the identity management stack as well as the operational hours associated with managing and supporting the infrastructure, the cost savings are clear. And let's not forget the expensive staffing to maintain any "glue code" that is required to actually provide value to your organization. All of it goes away in a cloud-based solution that provides customizable off-the shelf components needing no scripting.

In closing, identity management must be scalable for SMBs, but that doesn't just mean providing the ability to select required capabilities, but also scaling implementation and maintenance to be cost-effective for SMBs. Using a cloud-based solution that doesn't require any scripting or maintenance of 'glue code' is a best-practice approach for SMBs to achieve effective identity management.

Best Practices to Secure the Cloud with Identity Management

By Dan Dagnall, Chief Technology Strategist

What is the “cloud identity?” The “cloud identity” begins at the birth of the user’s “digital identity” and includes the attributes to define “who you are.” “Cloud Identity” is not a new term to those in the industry, but one that has definitely taken hold as the way to define “you” in the cloud. Much focus has been on how to “enable” a secure authentication event (through mechanisms like ADFS or Shibboleth), which is a key component of securing the transaction between Identity Providers (“IdP”) and Service Providers (“SP”). However, too little focus has been placed on the fundamental component required to “ensure” the integrity of the transaction; and by “integrity,” I mean that the person is right, the attributes are right, and the values are right The integrity of a “cloud identity” transaction can only be secured by sound identity management practices, with a razor-sharp focus on attribute management and policy enforcement.

Competent attribute management is the foundation of securing the “cloud identity.” It is the attribute and its corresponding value that ultimately determine the digital identity of an individual (or entity). When you consider the level of accuracy required (if your true goal is the validity of the transaction) in a cloud-centric world, you will concede the importance of properly representing the user in the cloud. When you consider attributes within this context, it becomes clear why identity management (IdM\) is the epicenter for securing the cloud identity.

Attribute management is much more than “just a middleware component;” it is identity management at a fundamental level. This fundamental level must not be overlooked as our industry begins discussing the large scale initiatives to create a common “ecosystem” through which cloud identities will travel.

There are a few key components of the IdM stack that provide for the integrity I’m describing; automation and policy management/enforcement.

Best Practice #1: Automation
Sound identity management practices must include automation, which includes event detection and downstream provisioning (i.e. the system automatically detects when a user, along with data associated to the user, is added/modified within the system of record, followed by automatically provisioning the user and the required attributes to downstream systems). Detection of changes to key attributes specific to the user’s identity [ideally, in real time] ensures the validity of the attribute value, i.e. making sure the value is correct and placed in the proper location and that placement was/is authorized.

Manual modification of users (on downstream target systems) including manual entry of attribute/value pairs is not a secure approach unless identity management has authorized these actions and the user performing them. Manual approaches can undermine data integrity and leave the user (whose identity and sensitive information will be floating around the cloud) at a major disadvantage and lead to improper representation of their identity in the cloud, not to mention the inherent risk for the user and the organization as a whole. This represents a scary reality for some, unless of course IdM has been properly deployed to ensure that malicious events are either immediately detected or thwarted before-hand.

Automated event detection eliminates the need for manual interactions with the user’s attribute set, which as I’ve discussed is the single-most important aspect of securing one’s identity in the cloud. Automated event detection when coupled with attribute management enables the proper enforcement of organizational policies put in place to protect the user.

Best Practice #2: Policy Management & Enforcement
Once automation is introduced, securing the remaining aspects of the cloud identity shifts to policy management and enforcement. Policy management is the layer of IdM which defines who is authorized and what level of access will be granted to downstream target systems. Whether bound by regulation (which is most often the case) or the requirement to comply with a set of standards and/or practices to participate in global federations (i.e. attribute management processes that meet a certain criteria), policy definition is the key to successfully securing the cloud identity.

Securing this layer cannot be accomplished by allowing unchecked “human” decisions to overrule the policy because it can have a direct effect on how that user is represented in the cloud. As a user, I’d sleep much better knowing that automated policy enforcement is managing my cloud identity, and abiding by organizational or regulatory guidelines like CSA and others to keep my identity safe and properly represented in the cloud.

In conclusion, someone with direct access to my data (because there is no automation), who can manipulate my attribute values without authorization (because there is no policy definition and enforcement), could compromise the representation of my “cloud identity” and call into question the integrity of the entire transaction.

So before you consider cloud-based transactions, specifically those where identity data is required, it is in your best interest to solidify your IdM practices and introduce the components I’ve outlined. Only then can you truly secure the cloud for your users and your organization.

The High Costs of Securing Identities: How to Fix the Problem Using the Cloud

By Dan Dagnall, Chief Technology Strategist

Identity Management is well down the path of a mature market space. But I believe there is still one final, fundamental disconnect which is driving up your cost of deploying and maintaining an identity management solution, and that is programming and customization.

For example, one can appreciate the need to tailor your user’s experience within your organization to be the way that you want it, but the question begs to be asked, to what end? Do you believe that identity management solutions should require your staff to write programming code in order to connect to your systems or for the purposes of maintaining custom user interfaces? Should your IdM solution require a strategy for maintaining a code base, or simply a strategy to secure user access and their identifiers while increasing efficiencies across your organization? These questions are important, because when we get down to brass tacks, these questions represent the primary drivers that can lead to insurmountable costs associated with maintaining and supporting your IdM solution.

“Fun factor” (and personal preference) aside, there is no reason why multiple industries should not be able to adopt similar identity management practices. I’m able to validate that personally, as I’ve worked with multiple customers, in multiple industries, and all of them have many requirements in common. Your identity management requirements are not as unique or “custom” as you might think. Specifically, you need password management, you need user provisioning, you need approvals, etc. The fundamentals of deploying such services do not change across industries (or IdM vendors). It is the mechanics that change. And certain mechanisms that enable IdM just simply cost more (i.e., programming your way to a solution costs much more than simply configuring the solution without requiring a single programmer (yes, it’s possible, and available right now).

The cloud serves as that mechanism to enable configuring as opposed to programmer-driven customization to provide each and every industry with a predictable cost, a predictable path (with a real light at the end of the tunnel!) and a predictable result for solving identity management problems. In order to justify how a cloud service model can drastically reduce your overhead associated with identity management, I must first define what identity management IS and what it IS NOT.

What is Identity Management?

Identity management (IdM) describes the management of individual identifiers, their authentication, authorization, and privileges/permissions within or across system and enterprise boundaries with the goal of increasing security and productivity while decreasing cost, downtime, and repetitive tasks (http://en.wikipedia.org/wiki/Identity_management). This is the definition provided by Wikipedia, and for the most part, it is accurate; however, it is the last half of the sentence that I’d like to focus on.

“…with the goal of increasing security and productivity while decreasing cost,
downtime and repetitive tasks”

Perfect. That’s exactly what everyone who ever decided they needed an identity management solution hoped to achieve. Unfortunately the reality in many cases is the exact opposite effect, specifically for on-premise deployments where consultants stand up your solution and turn over the keys when the project is complete. If you’ve procured a solution that requires constant care and feeding, that consultant may be needed again to ensure your solution continues to serve its purpose and doesn’t lag behind and eventually fall short of securing your identities into the future. Sure, all identity management solutions should “increase security” (if they don’t, then what’s the point?), they should all “increase productivity” (if repetitive processes are automated, productivity by default will increase), which on the surface appears to lead to “decreased cost.” But the cost decreases gained from efficiencies are quickly overtaken by the cost required to support the solution itself. This is a direct result of the mechanism chosen to manage your solution (i.e., holding the customer hostage to programming code, as well as the responsibility to maintain programming code post-production deployment).

What is NOT Identity Management?

First and foremost, writing programming code is NOT identity management. Frankly, from a customer perspective, it should not enter into the equation, ever. In order to call yourself an identity management provider, you must provide full-scale end-to-end identity management capabilities, provide them in a way that enables customers to input their local policy, define their workflow(s), connect to their downstream target applications, and include out-of-the-box end-user interfaces that are directly connected to those same policies and resources that are distinct to each organization, and without the requirement to write “glue code” to make it happen. And by this I mean managing users’ identities, not managing and editing programming code that then leads to managing user identities. I’m speaking of programming, and debugging, and more programming, and more waiting to leverage new functionality or new process, and more… I could go on.

As an organization, the second you have to write programming code so your “solution” can actually provide value, you’ve lit the fuse that will eventually result in an explosion in overhead; specifically, the costs associated with maintaining what essentially will become a programmer’s playground and signal the end to your “increased security,” “increased productivity,” and most importantly, the end to your “decreased cost.” When your identity management “solution” starts to take on attributes of a software company, rest assured that is NOT the intent of identity management; in fact, the result will be the exact opposite. Identity management products must enable you to focus on your policy, your data, and your business rules. They shouldn’t force you to focus on how to connect to your downstream target systems, or force you to be an expert computer programmer in order to solve your identity-related problems. Managing identities does not have to be that way. You have other options to realize “increased security,” “increased productivity,” and “decreased cost” without programming, at all. So how can “the cloud” decrease my identity-related costs and overhead?

If your primary driver for procuring identity management is to “increase security,” “increase productivity,” and “decrease cost,” the cloud should be a strong contender as you vet potential solutions. “The cloud,” as it has been coined, is definitely more than a potential cost-saving option at this point. It is THE most impactful method to lower your operating costs while maintaining or improving service levels to your user community.

First, let’s talk security…

Cloud-based identity management can be more secure than conventional, on-premise deployments. Storing sensitive user data in the cloud is the single biggest point of contention when we discuss cloud-based IdM, followed closely by questions about identity-related data being sent over the public internet to get from the customer’s network to the cloud provider. For starters, data sent across the web is protected by web-services security, including PKI, so it’s secure. Second, we must consider the unpopular truth that in many cases, a local datacenter is less secure than those of service providers. Also, most data breaches are caused by internal, often disgruntled, users. Externalizing the data center from the local premise helps address the issue of employees conspiring to remove sensitive information from the datacenter, while introducing a third party into the process directly correlates to a greater level of data storage security.

Finally, decreasing cost…

First, it’s a service, so it includes the entire software stack, which may include automated provisioning, role management, self-service portals, self-service [automated] password reset, as well as audit/compliance & governance controls. Second, because it’s a service, you only have to subscribe the services you want, as opposed to licensing an entire product suite when you only require a fraction of it to address your specific needs. Simply outsourcing the administration around such a large stack of services can save you 1 to 2 FTE (including help desk, as well as server administrators like DBAs, etc.). Once you consider the laundry list of infrastructure requirements to support the IdM stack as well as the operational hours associated with managing and supporting the platform, you can begin to realize the significant amount of cost savings your organization can achieve if you choose to secure your identities via an Identity as a Service model. And let’s never forget the expensive staffing requirements to maintain any “glue code” that is required to actually provide value to your organization. ALL OF IT goes away in the IaaS® model.

In closing, identity management is just not scalable for your organization when finances are a factor and the mechanism in use requires you and your staff to maintain extensive “glue code” in order to keep your solution afloat and growing to meet your demands.

Fischer Expert Opinions Included in Info-Tech Research Group Presentation

Info-Tech Research Group asked for Fischer’s expert opinions for their new presentation Federate IAM for and from the Cloud.  Search for Fischer to see what Dan Dagnall, our Chief Technology Strategist, said about IAM and the Cloud. Fischer provides Federated and Web Single Sign-On solutions and has a special program for qualified higher education institutions.