Explore the pros and cons of identity federation management
Identity federation is a relatively new technology in mobile, but it comes with challenges. Understand how to make deployment painless before adopting it.
As the scope of identity management evolves, consider implementing federation -- but be aware of its complications first.
At one time, IT teams that undertook identity management only controlled access to the resources within a single security domain. But, in recent years, internal users have begun accessing external resources, and external users have begun accessing internal resources, making the traditional approaches to identity management more complex and difficult to maintain.
In response to this growing trend, many organizations are turning to identity federation management to make it easier for users to work across multiple systems, while also reducing the administrative overhead that results from supporting access to these systems.
An introduction to identity federation
Identity federation links a user's identity across multiple security domains, each supporting its own identity management system. When two domains are federated, the user can authenticate to one domain, and then access resources in the other domain without having to log in a second time.
For example, a group of organizations that work on a project together might want to form an identity federation so users from each organization can more easily access and share resources among participating members. With identity federation, users only need to be authenticated once in order to access resources across all the domains, while administrators can still control the level of access in their own domains.
An important component of identity federation is single sign-on (SSO), a mechanism that authenticates users so they only need to provide one set of login credentials to access multiple systems or applications. Identity federation and SSO are sometimes considered to be one and the same, but they're distinctly different systems. At the same time, identity federation relies heavily on SSO technologies to authenticate users across domains.
Identity federation seeks to remove roadblocks that prevent users from easily accessing the resources they need when they need them. Users don't have to create new accounts or remember credentials for each domain, and they don't have to re-enter their credentials as they move from one domain to the next. The goal is to create a process that is as seamless as possible, while also providing end users with access to the resources that they use.
The role of identity federation management
With identity federation, administrators don't have to contend with many of the issues that come with balancing multi-domain access. For example, a team doesn't have to develop a specialized system to facilitate access to an outside organization's resources.
Identity federation can also benefit applications that need access to resources in multiple security domains.
To realize these benefits, IT teams must implement comprehensive identity federation management. Identity federation management is an umbrella term that describes the process of managing all the pieces that go into a comprehensive identity federation platform. This includes not only the technologies that make federation possible, but also the agreements, policies, standards and other elements that define how the service is implemented.
To make federation work, all the members must agree on these elements. They should decide which identifying attributes to include, such as email, name and job title; how to represent those attributes internally; and which standard to use for exchanging authentication and authorization data. For example, the Security Assertion Markup Language standard is commonly used for identity federation, so all the members would need to adhere to this standard if that's what they agree upon.
IAM incorporates many related components
Reaching an agreement on all these elements can be the most difficult part of implementing identity federation unless an organization is simply signing on to an existing federation platform, such as those established by companies like Microsoft and Facebook. If that's the case, the hosting organization has already made those decisions.
Organizations coming together to create their own federation have a more difficult time because the participating members must agree on all the components, a process complicated by local identity management systems, regional laws and regulations, and participants that are members of multiple federations. In addition, one of the organizations will need to serve as the central authority, which is a significant undertaking.
Identity federation management can also apply to a single organization that manages multiple security domains to better control the federation process. It is a relatively young technology, and its exact meaning is still evolving, so specifics can vary from source to source.
How to deploy identity federation
Despite the challenges that come with identity federation management, many organizations believe it's worth the effort and plan to move forward with their own identity federation projects. Before they do, they should take into account several important considerations, starting with the need for a clear and concise outline of the project's goals so everyone involved understands exactly what they're trying to achieve.
Participants also need to learn as much as they can about the federation's co-members and what to expect from those members. If an organization is joining an existing federation, then the IT team must understand the rules they're agreeing to, which standards they must conform to and what information they must share. For organizations starting from scratch, IT teams must learn whatever they can about the other members, including details such as what information they might share with their partners and which laws govern their operations.
Despite the challenges that come with identity federation management, many organizations believe it's worth the effort and plan to move forward with their own identity federation projects.
After IT teams have gathered the necessary information, it's time to start the planning process. Unless they're joining an existing federation, they must come to a consensus on how to implement identity federation. They will have to agree on the software and hardware requirements, configuration policies, attribute types and standards, joining and termination policies, and countless other considerations. Each IT team must also plan its own deployment, taking into account the federation's standards and agreements.
The most important aspect of the planning process is to properly address all the security-related issues. Participants must come up with minimum security standards that all the members can agree upon. The standards should include details about how to audit and data log systems while also protecting privacy. Members should also determine which security-related technologies they will use and how to secure data.
Throughout this process, teams should consider their end users' needs. Identity federation should enhance their experiences, not further complicate their lives.
IT teams should provide users with clear instructions about how to set up their accounts, as well as details on privacy and how their credentials will be used. Teams should also ensure that error, warning and informational messages are concise and useful.
If federated and local login capabilities are going to exist side by side, the options should be clear, and the procedures should be intuitive and easy to understand.
