Federated identity in practice

By Wouter Meijers, Principal Consultant at Everett

How ICTU has been able to build a federation around the Dutch government web-authentication facility and introduced “government single sign-on” in the process.

DigiD, the Dutch government authentication facility.

Until a couple of years ago, any citizen who wanted to conduct business with the Dutch government on the Internet required an electronic keychain filled with different usernames and passwords. Just like any other merchant, each government organisation established it's own website and introduced its own authentication facility. Dozens of government organisations thus required an equal number of digital identities. Until, back in 2003, the Dutch government introduced a new centralised authentication facility, DigiD (as in Digital iDentity). Among the first government organisations that offered support for DigiD were the tax office and the social security organisations. Everett together with the public employment service (UWV Werkbedrijf) have been on the forefront of DigiD implementations by developing one of the very first DigiD connectors for the Oracle portal implementation of UWV Werkbedrijf. This facilitated citizens who wanted to register for social security to authenticate using their DigiD account.

The main purpose of DigiD is to provide one single authentication mechanism for all citizens when conducting e-business with government organisations or affiliations. In order to use DigiD, one first has to request an account by registering at the DigiD site, specifying ones Citizen Service Number and post address. After performing a check against the associated municipal registries, the DigiD organisation ships an access code through the post to the prospective user, which she needs to subsequently activate the account. When selecting the "DigiD login" at a DigiD enabled web site, the user is redirected to the actual login page residing on the DigiD site. This redirect option has been chosen deliberately to increase awareness and trust of the DigiD "brand" and to offer a consistent look and feel for the login screens. Authentication is performed by DigiD, after which the user is redirected back to the originating website. The figure on the right depicts this process.

The user has the intention to access a Government Web Site that supports DigiD (1). On login, the user is redirected to the DigiD login page (2). After being authenticated, the user is redirected back to the originating web site (3). A Web Services based "back channel" is utilised to exchange entitlement details (4).

DigiD supports a number of authentication levels; from "Low" (unverified, temporary account), to "Basic" (username / password) and "Middle" (username / password with SMS confirmation). This set might be extended in the future to support even stronger authentication mechanisms.

Although the DigiD mechanism might suggest some sort of "government-wide single sign-on", this is not the case. DigiD is completely stateless and does not remember login sessions. This implies that a user visiting multiple government sites will have to re-authenticate at each and every site.

Since it is the intention of the Dutch government to position DigiD as a reliable and sufficiently secure authentication mechanism, the DigiD hosting organisation GBO.Overheid (an organisation responsible for the management and ongoing development of a number of ICT services for all government agencies), has issued an extensive set of requirements that sites, wishing to support DigiD, are forced to adhere to. These requirements cover the exact method and protocol required to communicate with DigiD, but also the look and feel of login buttons and the use of the DigiD trademark.

Implementing a DigiD federation

Over the last four years, the Stichting ICTU (a Dutch government IT research and implementation organisation) has been working on the creation of a web site that should consolidate all interactions between citizen and government. The result of these efforts is now slowly materializing as a new government web site: "www.mijnoverheid.nl".

Mijnoverheid.nl will eventually provide access to information from many other government organisations and obviously utilises the DigiD authentication mechanism. Not satisfied with the type of service provided by DigiD, ICTU has performed an extensive market research and after consulting other government organisations, decided that a federative authentication mechanism using the SAML 2.0 protocol in combination with DigiD would be a considerable improvement. This federation would facilitate a proper "government single sign-on" based on open standards, while at the same time utilizing the proven and trusted DigiD authentication mechanism.

The DigiD authentication protocol is a proprietary protocol. Parties with the intention to use DigiD thus have to undertake development efforts in order to integrate their local authentication facilities with this proprietary protocol. ICTU intends to improve on this situation by utilizing secure, open, standards, hiding the DigiD protocol behind the implementation of what ICTU has named the "SSO Federation".

The figure on the right shows the resulting infrastructure. Parties can connect with the federation using the SAML 2.0 protocol. Government-issued certificates are used to implement a two-way encrypted connection between the requesting government web site (Service Provider or SP) and the federated authentication facility of the SSO Federation (Identity Provider or IDP).

In case a user wants to access a DigiD protected web page on a government web site that is member of this federation, the authentication procedure works as follows:

1. The SP's local authentication facility checks whether the user has a valid security session. If not, the required authentication mechanism is selected based on the web page that the user attempts to access;
2. Assuming that the page is protected by DigiD and there is no valid security session, the user is now redirected to the IDP of the SSO Federation;
3. The IDP checks whether a valid security session exists with the federation. If so, this information is returned to the SP;
4. If no valid session exists with the federation, the user is redirected to the DigiD login page. The user now has to authenticate with DigiD;
5. Assuming that the authentication succeeds, a security session is established at the IDP and the appropriate user authentication attributes are returned to the SP;
6. The SP uses the information returned from the IDP to create a local security session and grants the user access to the requested page;

Because of this federated authentication, the user is now free to browse between any site that is part of the federation without having to re-authenticate. As long as the security session at the IDP exists, new sites will connect a user transparently. There is one exception: as stated before, DigiD supports different authentication levels. If the SP requests an authentication level that is stronger than the one associated with an existing IDP session, the user will be redirected to DigiD and is requested to re-authenticate with the stronger authentication level.

Challenges

As stated earlier, GBO.Overheid enforces a set of requirements upon sites that express an interest in using DigiD. From the GBO.Overheid point of view, the SSO Federation is simply a connected party and the federation thus has to adhere to the full set of requirements imposed by GBO.Overheid. Obviously, ICTU in-turn enforces these requirements upon each SP interested in becoming a member of the SSO Federation. In general, from the SP point of view, these requirements are relatively simple to adhere to since they are mostly related to the proper use of the DigiD brand (given that the complex DigiD authentication protocol is hidden by the SSO Federation). However, there are two timing requirements that have proven to cause some headaches during implementation of the federation:

1. A session that has been inactive for more then 15 minutes must be revoked;
2. A session that has a duration exceeding 120 minutes must be revoked (independent of activity);

The first requirement has forced ICTU to implement a session keep-alive timer for the centralised IDP session. Each SP has to implement a "heartbeat", by sending a SAML 2.0 "authorisation request" to the SSO Federation every 5-10 minutes as long as there is user activity at the SP. This heartbeat will keep the IDP session alive as long as the user still shows some activity "somewhere" within the federation. When the heartbeats fail to arrive for a period longer then 15 minutes, the IDP issues a SAML single log out request to all connected SP's in order to terminate all user sessions. The same will happen if the IDP session has exceeded a total duration of 120 minutes (timing requirement 2).

The UWV Werkbedrijf case

The public employment service (UWV Werkbedrijf) always has been on the forefront of implementing new ICT solutions. Being one of the first parties to utilize DigiD, they were also one of the first parties expressing an interest to connect to the SSO Federation. Oracle Corporation in close cooperation with Everett has taken the challenge to adapt the Oracle Access Manager and Oracle Identity Federation components to operate within the constraints of the requirements imposed on the SSO Federation by GBO.Overheid.

Obviously the biggest challenge proved to be the implementation of the heartbeat function. Although the federation utilises the standardised SAML 2.0 protocol, the heartbeat implementation is not something that authentication mechanisms typically provide "out of the box". In case of the Oracle Identity and Access Management components, things are further complicated by the fact that SAML is implemented in a separate component (Oracle Identity Federation), which is loosely integrated with Oracle Access Manager. The chosen implementation is depicted in this figure:

The figure shows the SSO Federation (in yellow) and the existing Oracle Portal implementation of UWV Werkbedrijf (in orange). The added components are shown in blue. Oracle Access Manager (OAM) implements policy-based access management of web pages (URL's). Depending on the policies associated with a URL, authentication might be delegated to Oracle Identity Federation (OIF). OIF utilizes the SSO Federation for the authentication process and establishes the federated security session. User credentials returned by the federation are registered in the local user directory (implemented by Oracle Internet Directory) and subsequently retrieved from the directory by the portal.

The heartbeat mechanism has been implemented by using the capabilities of a virtual directory to associate custom code with directory access requests. OAM verifies access rights on any URL accessed by the user against a directory. Oracle Virtual Directory intercepts these requests and uses the associated user identifier to trigger the heartbeat implementation code. The advantage of this approach is that there is no need to perform OAM customizations.

To date (mid August, 2009), the integration is being finalized and tested. It is the intention of UWV Werkbedrijf to implement the solution in a production environment by the end of 2009. The experiment has proven that it is technically feasible to implement additional functionality on top of the "out of the box" SAML authentication in commercial products such as Oracle Access Manager / Identity Federation. The end solution provides additional added value such as cross-federation session keep-alive compliant with third-party requirements.

Conclusion

DigiD as a centralised government authentication mechanism has proven value to citizens, since it prevents a user from having to manage multiple authentication mechanisms for as many government web sites. By "wrapping" DigiD inside a SAML federation, the added value has increased since the user now experiences real "government single sign-on" when surfing between government web sites. The SSO Federation initiative has shown that the SAML protocol offers sufficient flexibility to incorporate the specific requirements of DigiD, which has never been designed to work within a federation, while still being able to utilize commercial authentication products such as Oracle Access Manager and Oracle Identity Federation.

Oracle (NASDAQ: ORCL) is the world's largest business software company. For more information about Oracle, please visit the Oracle Web site at www.oracle.com.

Everett is an international consulting firm, systems integrator and solution support services provider, specialized in Identity & Access Management and Portal solutions – domains of expertise that are subject to major new developments on a continuous basis. Everett is located in the Netherlands, the United Kingdom, Italy and India. Visit www.everett.nl for more information.