Tutorial #1 - Understanding Federated Identity

Tutorial #1 - Understanding Federated Identity

1 Overview

This tutorial sets out to provide an explanation of basic federated identity concepts. We will show how federated identity works, and how it can be of benefit to an organization or to a group of organizations. We will also explain what the Symlabs Federated Identity Suite consists of and how it can be used to implement federated identity support.

2 What is Federated Identity?

In a nutshell, federated identity is a standardized methodology of sharing identity information between different parties with different privileges, so that identity information does not need to be stored in multiple repositories. Of course, that doesn't sound very helpful. To really understand what federated identity is, we need to look at the background and the kind of problems that federated identity attempts to resolve.

2.1 Understanding Identity and the Problems with Distributed Identity

Every person has an identity, consisting of particular traits, attributes and preferences. From the moment a person is born, an identity begins to evolve. It starts with a name on a birth certificate, and eventually consists of hundreds of different components including Social Security number, Driving license details, Employee data, Bank account details etc etc. Over time, a person's identity becomes increasingly fragmented. Data is stored in multiple places, and there is little or no co-ordination between the entities responsible for storing and maintaining data. As people have increasingly started using the Internet to perform business and social interactions, it has become more obvious that this distribution of identity data comes with a number of problems.

Fig-1: Identity is distributed across multiple sites and redundant data is stored adding complexity

The first, and most obvious problem with distributed identity data is that it needs to be maintained in multiple places. This means that if you change your address, you have to notify and update your details for any organization that may store data for you. Often, organizations may have multiple repositories within themselves and changes need to be synchronized across all repositories. A single change of identity data, can generate a lot of work for the person concerned, as well as for the companies storing that data.

Another problem with distributed identity data arises with regard to authentication. People are increasingly required to authenticate in order to make use of a myriad of services both on the Internet and within the workplace. As a result, people have to keep track of a massive list of credentials used to authenticate themselves in different places. This has a large number of repercussions. The most severe of which is that it actually increases the opportunity for identity theft and fraud. Once a password combination has been stolen, it is almost impossible for someone to update credentials at all of the places where they may make use of the same combination. Less serious, but certainly annoying for everyone, is the simple requirement to keep logging in to make use of services provided by different organizations (many of which may be closely related). Certainly, I have differing login procedures and credentials to access my credit card account online than I use to access my current account.

Finally, a major problem with distributed identity data is the issue of trust and privacy. Each organization that wishes to interact with an individual will store identity data. Frequently, we are not certain to what level we can trust an organization with our data, and often access to this data is abused and we find ourselves faced with an increasing flood of unsolicited email and we find that our data is being shared with third parties. There seems to be no way that an individual can control who has access to data and for how long.

2.2 How Federated Identity Standards Seek to Provide Solutions to the Problems

Federated Identity standards have emerged in an effort to solve many of the problems associated with distributed identity data. Primarily, the goal of all federated identity systems is to allow users to seamlessly and securely access and make use of systems across domains, without the need to maintain redundant identity data. In order to facilitate this federated identity framework, a circle of trust is established between participants. Participants can set up any number of Identity Providers within the circle of trust. An individual is then able to choose which Identity Provider to make use of in order to access services provided by all of the members of the federation. Personal data for the user can be stored in multiple places within the federation, but reduces redundancy by ensuring that pieces of personal data can be linked together and potentially be used throughout the federation.

Fig-2: In a federation, Identity data may be stored in more than one place, but is not redundant. A single entity can be responsible for authenticating users, while another may be responsible for storing certain personal profile details.

This concept is not as alien as it may seem at first. Consider how you are able to use your bank card at a variety of ATMs provided by different banks. In order to facilitate this, your bank card issuer will act as your Identity Provider. When you make a transaction at an ATM provided by an alternate bank, your bank card issuer will authenticate you and will provide enough detail to the issuing bank to allow them to process the transaction. In this way, your bank has vouched for your authenticity and provisions the ATM system with enough information to know whether it is able to issue you with cash. In a manner of speaking, banks have evolved their own federated network which allows users to make use of their services as long as one of the members of the federation will vouch for the user.

There are many use-case examples that adequately illustrate how a federated identity can work to solve the problems associated with distributed identity. Below, we will provide some sample instances and explain how they have solved a variety of problems that would usually arise outside of a federated identity framework.

2.1.1 A bank and credit card company would like to provide Single Sign-On services to their websites

In a federated identity framework, my bank and credit card company are able to join forces to allow me to seamlessly access my accounts on either website, once I have logged in once at either website. Once these two entities have established that they belong to the same circle of trust, they will be able to share an Identity Provider that is responsible for authenticating my access to either website. When I login at either website, the Identity Provider will be able to vouch that I have already been authenticated. If I try to access the other site, the Identity Provider can provide sufficient detail to the site for it to be able to determine that I have been authenticated and for it to provision me with my account details. In this scenario, we have only highlighted the possibility of providing a Single Sign-On environment across two domains. In a more complex scenario, it would be possible for these entities to both be able to access the same personal information about me, so that any personal data that is updated is available to both entities. This would mean that I would be able to provide a change of address to either organization and know that this will be reflected to both of them.

2.1.2 A service provider working with a 3rd Party to provision additional services

My cellular or mobile service provider may wish to allow me to purchase ringtones from a third-party website, however there is no need for the third-party to have access to any of my personal identity information, and I may not wish them to have access to any of this information. In order to facilitate this, my provider will vouch that I have been authenticated and will provide the third party with a token that represents me, but which does not contain any personal information. After having logged on at my service provider's website, I am able to connect to the third-party website and select the ring-tones that I wish to purchase. When I checkout, the third-party can invoice my service provider for the purchase providing my token information, and my service provider can charge me for the purchase. During the entire transaction, I have only had to login once at my service provider. I have not had to enter any personal information at the 3rd Party website. And I know that the 3rd Party does not have access to any of my private data.

2.1.3 Two companies wish to provide access to the same intranet applications, but do not wish to share employee data

Each company stores its own employee data. However the two companies wish to make use of a set of intranet applications that they will share. Neither company wishes to share employee data. In order for this to happen, each company sets up its own Identity Provider. The intranet application is able to use either Identity Provider to authenticate users. When a user logs into their computer at work, authentication takes place against the local Identity Provider. When the user attempts to access the shared intranet application, the application is able to determine that the user is already authenticated and does not require login. The user is then able to use the application to interact with users from the associated company. To clarify this, we could imagine that two affiliated but separate companies wish to share an addressbook, but wish to retain autonomy over authentication. In this example, we have illustrated how Single Sign-On can be achieved within a federated identity framework, but more importantly, we have shown that authentication credentials required to access a single application can be stored in two separate autonomous domains.

Fig-3: An SP can make use of multiple IdPs, granting companies autonomy over authentication data while they share applications.

2.3 Concerns about Federated Identity

While Identity Federation seems like a good idea, it is not simple to implement. To begin with, there are multiple standards that can be followed to create a federation. If all of the organizations in a federation can agree on the standards being used, it does make things easier. However, this is not a realistic goal as organizations develop their infrastructures independently of one another and often have very different requirements. The result is that organizations end up implementing systems that can take part in one or another federation type, but getting these systems to talk to each other can be tricky. The complexity of setting up a federated infrastructure can discourage organizations from implementation.

Another stumbling block is related to managing Circles of Trust within a federation. While the many legal issues, related to determining what data can be shared and how, need to be ironed out between participants, it is clear that these agreements may change over time. Control over the relationships that systems can have within a federation is paramount. However, management of these relationships may seem to be difficult to configure and keep track of.

There is also a problem with regard to perceptions about security. Some people think that unified identity information and standardized systems are more likely to be insecure and open to abuse. This perception is probably misguided in many cases. Most of the federated identity standards seek to address security issues and have been around to gain enough maturity to have already dealt with many problem areas. Certainly those standards that center around concepts such as a circle of trust massively reduce the possibility that data will be misused.

Furthermore, in a federated framework, security specialists are more likely to be responsible for implementing and maintaining the technology responsible for handling identity information. Part of the thinking behind federated identities is that if there is less redundant information about an individual stored in different systems, it reduces the number of systems that could be compromised to reveal personal information. Dispelling myths about security with regard to the technology is difficult and it is only through ease of management and clear auditing that people will begin to see the benefits of the architecture.

Finally, as with all new technology, the cost of developing this sort of infrastructure is often a key deciding factor. Many companies are uncertain as to how future technologies will develop and prudently avoid spending money on development that may not integrate with systems in the future. By adhering to a standards-based architecture and making use of functionality that has already been developed to integrate systems across competing standards, companies can overcome these obstacles, massively reducing the cost of development and ensuring that new systems will integrate in the future.

3 What is Symlabs Federated Identity Suite?

Symlabs has developed a product that helps to ease some of the implementation problems with regard to setting up a federated identity environment. The Symlabs Federated Identity Suite (SFIS) supports all of the major standards used to implement a federated architecture. As a result, the SFIS can be easily integrated with systems that make use of different standards. The product includes the various components that make up the federated architecture, as well as the toolkit to help integrate these components with existing infrastructure. All of the components can be managed and configured within a web-based GUI environment, so that an Identity Provider can be created at the click of a button, and configured within a matter of minutes.

SFIS seeks to reduce the complexity and knowledge required to implement a fully standards compliant federated identity architecture. By providing a GUI facility to rapidly build a framework that will handle authentication requests and provision web services across a federation, SFIS can be used to quickly develop an environment into which existing applications can be integrated. By using SFIS, companies can be sure that the core infrastructure will integrate with all other standards based applications in the future, helping to prevent unnecessary expenditure on development and integration.

The SFIS Web Admin GUI also provides all of the tools to manage Circles of Trust and provides control over how systems within a federation are able to interact. This removes any concern over future management of the Circle of Trust and over the relationships between systems.

The SFIS allows administrators to specify different backend databases for a wide range of storage requirements, including separate directories for session data, authentication credentials, federation details, Circles of Trust, and an independent assertion database that can be used to track and audit all assertions within the federation. This helps to add granularity to the entire architecture, so that it is easier to separate out information that you require, and to distribute your various storage requirements in the manner best suited to your requirements.

SFIS builds strongly on the Liberty Alliance (ID-FF 1.2 & ID-WSF 2.0) and OASIS (SAML 2.0) standards to provide a range of identity services and facilities, and to ensure interoperability. Please have a look at the Interoperable Products pages at Liberty Alliance for more information about interoperability. Through the rest of this tutorial, we will discuss the major federation components supported by SFIS and explain how they can be used within a federated architecture.

3.1 Identity Provider (IdP)

Any federated identity architecture will require at least one Identity Provider. The Identity Provider is responsible for handling the authentication of users within the federation, and for maintaining federation information. The Identity Provider also maintains federation details and provides Single Sign-On (SSO) capabilities in the federation. This means that individuals making use of services within the federation can login once, select which service providers, within the circle of trust, may join in the federation, and access all of these service providers without having to login again. Equally, the Identity Provider can allow the user to de-federate service providers that should no longer allow for SSO; and the Identity Provider also ensures that when a user logs off, that the user is logged out for all Service Providers within the federation and the Identity Provider itself, should the user choose Single Logout as the logout mechanism.

Within the SFIS Web Admin GUI, adding and configuring an Identity Provider is relatively simple. You are able to specify which standards are supported by the Identity Provider, whether the user is able to control federation and which IdPs and Service Providers belong to the Circle of Trust. The Identity Provider can be configured to make use of LDAP Backend Servers, including Active Directory, as the datastore for identity credentials and to store other data. The GUI also provides a facility to edit and provision user access within the federation.

Fig-4: Configuring and Identity Provider within the SFIS Web Admin GUI

Once the IdP has been created and enabled, it is fully customizable by editing the IdP HTML and CSS files within the SFIS installation path. This allows customers to entirely create their own look-and-feel and localize the IdP service.

3.2 Service Provider (SP)

Service Providers consist of any system within the federation that will provision services to users. These systems are frequently web-based applications that require authentication. If creating a Service Provider application from scratch, the easiest method is to create the Service Provider within the SFIS Web Admin GUI. This automatically creates a self-contained web server instance capable of running the application and of interfacing properly with the rest of the federation. A configuration folder holding all of the immediate pieces of code required to begin working on your application is created automatically. Instantly, a web site is created that is capable of interacting with an IdP supporting a variety of standards and protocols. From here, it is possible to modify the template code to present your own look and feel, and to begin coding your application. SFIS generated SP code makes use of Symlabs own native language called Directory Script. This language will facilitate the business logic that you may require to construct your application.

Fig-5: A Service Provider provisions web services to users authenticated by an IdP

Naturally, it is rare that you are likely to be building your application from scratch and it is quite likely that you may want the development of your web application to be coded in a more widely used language. In order to facilitate this, there are a number of options available to integrate external applications with the SFIS:

1. Proxy Mode: the SP-base will act as a web proxy server that sits in front of the web application. All requests for the application are intercepted by the SP-base, which determines whether or not the client has been authenticated. If the client has not been authenticated, the SP-base will redirect the user to the IdP for authentication. If the client has been authenticated, the SP-base will serve pages to the user that it has proxied from the original application.

    

2. Redirect Mode: the original application is accessed directly, but for authentication the client is redirected to the SP-base. This approach is complicated, as it requires that the SP-base is configured in such a way that it can write session data that the original application can access. As a result, it does not work out-of-the-box, but requires additional configuration on both sides.

    

3. Client Kit: the application is modified in such a way as to function as an SP without making use of the default SP-base at all. In order to do this, Symlabs provides a Client Kit that provides a set of libraries against which developers can code all of the SP functionality directly into the original application. This is the most popular approach and is discussed a little further below.

3.3 Client Kit

As discussed above, the majority of applications that you wish to integrate into your federated architecture are likely to already have been developed, however few of these applications will have been built to integrate into a federated environment and take advantage of the benefits of federated identity management. You may find that you would like to modify an existing application so that it can act as a proper SP in and of itself. In order to assist developers and to ensure that federation standards are adhered to, Symlabs provides a Client Kit, which provides a set of libraries and an API against which developers can build SP functionality directly into an application. The Client Kit provides support for many of the major web development languages used today, including: .Net, C, Perl, Java, PHP and Ruby. The Client Kit also includes an Apache Module that can be used to develop against.

In any instance, all internal authentication handling within an application would need to be stripped out and replaced with the functionality provided through the Client Kit. Symlabs can offer support and assist developers with any of the work that needs to be done to integrate the SFIS functionality into an application.

Naturally, once the application has been SP enabled, it does not need to be created within the Symlabs Web Admin GUI, but can simply be added to the IdP's Circle of Trust in order to be used within the federation immediately.

Finally, the Client Kit provides everything needed to make use of the full ID-WSF 2.0 standard to build further functionality into an application, such as the ability to make use of a Personal Profile server or a People Service Server. These other ID-WSF 2.0 facilities are discussed in more detail below.

3.4 Personal Profile (PP)

The ID-WSF 2.0 standard as defined by Liberty Alliance, sets out how applications should interact in order to securely make use of personal data within a federated environment. ID-WSF 2.0 clients are able to interact with a Discovery server that will report which services are available and which servers will be able to service requests. Once the client is able to determine where it can obtain the information it requires, it is able to interact with an ID-WSF 2.0 server to share data. The ID-WSF standard provides a foundation against which it is possible to build additional interoperable identity services such as registration services, contact books, calendar services, geo-location services, presence services, notification or alert services, etc. The standard ensures that applications do this in a secure manner and adhere to standard protocols to interact fluidly within any environment.

One of the most established and frequently used services is the Personal Profile service. This enables a Personal Profile client on one SP to access specific identity data stored within a Personal Profile server. This means that an application or SP does not actually need to store personal identity data within its own database, but instead can request for this information to be provisioned by a Personal Profile server. This helps to achieve the goal of reducing the amount of redundant personal data stored in different systems, the benefits of which are numerous.

Fig-6: An SP with the Personal Profile client enabled can obtain data from a PP server.

The SFIS Web Admin GUI can be used to instantly create a Personal Profile server by automatically enabling this functionality within an SP. The Personal Profile server will be able to service requests coming from clients and provision them with data over a SOAP connection. This is illustrated very well by the demo environment that is bundled with the application.

3.5 Other ID-WSF 2.0 Services

The SFIS has support for the many other ID-WSF services, however most of these will require additional configuration outside of the Web Admin GUI and will almost certainly require development work on the SP side. Nonetheless, it is possible to implement any of these services within a federated environment, making use of the various components of the SFIS. The following list provides a breakdown of the other services available and what they do:

1. People Service: this service enables secure, cross-principal, online interactions between users and friends in a social context or between users and job roles in a professional context. It can be used as a powerful component within applications to allow users to share information with each other securely.

    

2. ID-DAP: this service allows existing LDAP Directories to service requests within an ID-WSF framework in a secure manner across the web. ID-DAP clients can invoke this web service to remotely perform LDAP operations with no requirement to reveal a user's actual private identity information

    

3. Geolocation: this service helps to share geolocation information securely by adding identity-based invocations and addressing to the mobile location protocol (MLP) used by mobile network operators to offer services to users. This is a powerful tool in that sensitive information identifying a user's location is shared safely because it can be limited to authorized applications and even with varying degrees of granularity, all according to permissions granted by the user.

    

4. ID-Messaging: much like the geolocation service, this service helps to facilitate mobile messaging without having to share sensitive data like a mobile telephone number. The service adds identity-based invocations and addressing to the MM7 protocols used for messaging.

Fig-7: The People Service can be used to allow users to share access to applications such as an online calendar, and forms a fundamental component that could be used for social networking.

4 Summary

Identity Federation clearly provides numerous benefits both with regard to security and privacy. It also reduces the amount of redundant data stored about individuals, facilitating better management and updateability. Finally, it offers an exceptional method of handling Single Sign-On (SSO) and Single Log-Off (SLO), that is both secure and helps to protect an individual's identity.

On top of these basic fundamental advantages, there are a range of services available through the ID-WSF standard provided by Liberty Alliance, that define how applications can become interoperable within the federated framework. By developing applications within a standardized environment, you help to ensure future interoperability with other applications, and reduce total cost of development in the long run.

The Symlabs Federated Identity Suite (SFIS) provides all of the tools required to set up a standards compliant federated environment capable of integrating with existing architecture. The package provides an easy to use Web based Administration GUI and a Client Kit that can be used to modify existing applications to integrate with the Identity Federation framework.