Published: 28 Apr 2005
POLICY & PROCESS
It doesn't come easy when you federate identity management.
|Living in a Federated World|
Federation promises seamless access to users across domains, and helps organizations realize the potential of online business without the burdens of setting up and administering unwieldy one-off relationships with partners, suppliers and customers.
Every organization faces the challenge of managing user accounts that exist in different departments and outside service providers. These accounts are often owned by different entities, but need to be integrated to allow seamless use and consistent management. For purely internal applications and services, it's possible to merge the domains, manage a single set of identities, streamline the user experience and minimize the management--but even that's difficult.
Federation addresses the challenge of offering single sign-on and identity management for multiple domains. With XML-based standards, enterprises can map the identities of their users and customers to identities stored on directories belonging to federated departments and partners. Users can transparently pass from one domain to another without entering multiple credentials.
Standards such as SAML, The Liberty Alliance's ID-Web Services Framework (ID-WSF) and WS-Security provide the technical mechanisms for passing credentials between domains. But true federation is contingent upon the establishment of out-of-band trusted relationships. When federating, organizations need to decide how much information about their users and customers they wants to share with partners, how users will be involved in deciding what is shared, what risks are being taken by sharing customer data, and what legal agreements need to be in place for when things go wrong.
The challenge for enterprises building federated, cross-domain networks is managing these trusted relationships, and ensuring that they and their partners are living up to the security requirements that make federation work.
Federation is based on the concept that domains are autonomous entities that have their own identity and privilege systems. Federation doesn't subsume the need for creating, provisioning and maintaining user accounts; it's more of a cross-domain simplified sign-on mechanism.
In a typical federated scheme, one enterprise agrees to trust another enterprise's users' access assertions and to grant access to applications and other resources. Credentials are stored at both enterprises; the user only must assert his credentials once and only needs a single set of credentials to access one or multiple domains. In many cases, the user experience is akin to single sign-on.
An example of federation is an airline and rental car partnership. A frequent flier earns points for special rewards programs, and, since the airline partners with a car rental company, a federated relationship enables the airline to assert the user's identity to the car rental company to authenticate the user for reservations and discounts. Federation allows the customer to log in once and move seamlessly between domains, having a more integrated and simplified experience.
Sounds wonderful, but the process can be fraught with risk. If an organization places no limits on the users from other domains, and even one of the partners is compromised, it affects the entire federated group.
Federated partners can use three methods to protect themselves: place specific limits on what federated users can do, implement technical and procedural checks and balances to monitor the security of partners' domains, and establish legal agreements that make partners liable for damages resulting from a compromise.
Establishing boundaries and controls for federated relationships will guard your enterprise against being affected by problems in other domains. The basic rule of thumb should be to provide only access to resources that are commensurate with the value of the relationship. For example, if an organization federates with a customer's domain, it's reasonable to only provide access to resources owned by the customer. (See "Living in a Federated World," opposite.)
|Making Federation Work|
Establishing and Maintaining Trust
Federation requires that an organization trusts another organization to authenticate its users and ensure that those users have rights to access data and resources. The more sensitive or valuable the applications or data, the more difficult it is to extend trust.
Enterprises shouldn't just open access through federation without first conducting a thorough risk assessment, looking into both the security protections of all parties involved and the value of the information and data being accessed.
Access control and authentication mechanisms must also be mutually acceptable. Enterprises with high-value assets should require their users to employ multifactor authentication, such as tokens and passwords, and won't want to access assertions from enterprises using a simple user name/password. The access granted to federated users should be commensurate with the level of trust associated with their authentication mechanisms and points of origin. For example, you could grant limited access to noncritical resources using only a password, but require multifactor authentication for restricted, sensitive applications.
The federated agreement should specify change control requirements. Employees constantly join and depart organizations; you must provide mechanisms that ensure former employees are removed from a host enterprise's identity directory, thus preventing illicit access to all linked federated accounts. Likewise, federating enterprises should conduct periodic audits of their identity stores to look for inactive accounts.
The security and integrity of the federation is largely dependent on the assertion keys. Consequently, federation partners need to agree on the processes for acquiring and managing digital certificates, and the group needs to agree on the certification authorities, key storage standards and revocation mechanisms.
To cover what is an acceptable level of security, many enterprises are requiring federated partners to adhere to third-party security audits and assessments based on ISO 17799 or COBIT. Whether the relationship is based on one of these standards or a homegrown requirement, the federation agreement should provide for periodic auditing of one another's security procedures and posture, and include requirements for reporting procedural lapses and security incidents.
All federations require legal agreements that establish the partners' responsibilities in authenticating parties, maintaining the security and integrity of their infrastructures and paying damages when a party doesn't fulfill its requirements. Federation partners need to establish the technical mechanisms to judge whether a party is complying with the practices laid out in the agreement. For example, organizations must be able to prove that authentication practices are followed, audit records are accurate, encryption keys are protected and the security infrastructure is maintained according to agreed upon standards.
Monitoring federated transactions will help ensure that service-level and trust agreements are being met by all federated parties. The best arrangement is when federated partners decide to establish a degree of transparency in their security operations. In addition, the partners should share audit records regarding events like logins, cross-site authentication assertions and privilege changes that affect each other. The participants can help each other ensure that the federation mechanisms are working correctly by comparing audit records.
Finally, federating enterprises must establish procedures for reconciling disagreements over policy implementation, access restrictions and denials, service outages, and incident response and procedural gaffs. No system is perfect, and incidents will happen. Establishing strict rules for notification of partners in the event of a suspected compromise, and documentation of incidents, the organizations' response, the suspected cause and the remedy should help preserve the federated relationship in the face of mishaps.
Before committing to a federation, organizations should understand and control the risks by limiting the services offered to a reasonable set. Also, they should establish the necessary legal protections in the partnership and recognize the effort it will take to maintain a long-term federated relationship.