« Business continuity with real-time data integration | Main | Six guiding principles to Consolidate your IT »

May 31, 2010

Scalable federated security with Kerberos

In my last post, I outlined considerations that need to be taken into account when choosing between a centralized and federated security model. So, how do we implement the chosen model? Based on a real-world case study, I will outline a Kerberos architecture that enables cutting-edge collaborative research through federated sharing of resources. This is an extract from the full article which can be downloaded here.

Context

The IT infrastructures of two Institutions are heterogeneous to one another and contain different assets that are shared to facilitate ground-breaking research:
  • Storage Institution - hosts a 5PB storage array that serves as a shared storage resource for users from both institutions. Additionally, Storage Institution hosts a petabyte digital library of research papers and technical books.
  • Compute Institution hosts a large compute cluster that serves as a shared computing resource for both institutions.

Each institution has its own user management system. This means that for a user to access a resource requires them to use its specific access credentials. Whenever one institution wants to share a resource with a user at the other institution, a new user account at the owning institution has to be created. This cumbersome resource sharing model is not effective, requires a lot of paper work and users suffer from the extensive number of account details (non-uniform resource access) that they must remember. Moreover, with the lack of a common user access management tool, administrators have difficulty in keeping tabs on resource access lists and conforming to security requirements.

Challenge

The institutions have decided that a new approach is required that provides secure, simple and rapid sharing of resources. Users who own the resources should be free to decide who can access them to enable intuitive collaboration removed from administrative hurdles. 

The differing levels of IT skills at the two institutions means that the management tool for resource sharing should be simple and intuitive. GridwiseTech's AdHoc encapsulates these core values and is one of the presented solutions.

The challenge is to create an IT Infrastructure that securely shares distributed resources. Access  granting and revoking must be intuitive and quick. The system should provide the following functionality:

  • No single-point of failure - If the IT infrastructure of one Institute goes down, the other should remain unaffected.
  • SSO – users should be able to access resources from both Institutions using their single access credentials.
  • Access management – resource owners should be able able to grant access to their resources quickly and intuitively.

Rationale: Federated security

The federated paradigm can be conceptualized as: passports – one country issues a passports and others accept it as valid identification. You are only issued one passport, but it works everywhere because there is trust between countries. Without this trust, then a country cannot participate.

Such a model enables multiple institutions to grant external user access to their sensitive resources, whilst maintaining full access control over them. No user accounts need to be created at the resource side and users benefit from single sign-on (SSO) to resources.

Designing a federated security system which connects multiple institutions is common. However, there is no single solution for such a challenge. A number of technologies exist that can be used to implement federated security, Shibboleth, Oracle IdM, OpenSSO, among others. Important aspects that require validation are:
  • Security system concept and implementation - the system has to be verified that the security protocol is secure
  • Number of applications to be supported by the system and their license models - integration of applications with security frameworks can be non-trivial and require custom development
  • System management utilities – should provide ease of use, ideally through the use of graphical tools that can visualize who has access to which resources
  • Cost and support – weigh up the costs associated with open source solutions, which are free but offer minimal support compared to the proprietary solutions

Architecture: Keberos, LDAP and AdHoc

It is recommended to implement federated security using the Internet standards based LDAP and Kerberos. Both solutions provide free use licenses and have a proud heritage of implementing secure IT infrastructures. The strong point of LDAP and Kerberos  integration is their extensive support for pre-existing software. Many network related applications are fully supported  to use Kerberos authentication, web applications, network file systems (such as NFS, OpenAFS) and other remote and local services.
Kerberos and LDAP have some pre-existing management tools but they are not intuitive for non-skilled users. AdHoc can provide intuitive resource access management. The responsibilities of each are outlined below:
  • LDAP – manage user authorization to resources.  Each institution will have its own LDAP server. To maintain federation, the stored information will be synchronized between the Institutions. Each institution will only be able to modify its own entities.
  • Kerberos – manage user authentication using SSO. The federated security provided by Kerberos means user passwords are stored at their own institution.
  • AdHoc – responsible for managing access policies to  resources. It will allow resource owners to manage access to their assets in a simple and secure way using a graphical web interface. Users will be granted access to resources using the simple drag&drop functionality of the web interface.

Keberos_architectureThe two institutions are connected using Kerberos and LDAP. Green indicates services related to the security system and blue  AdHoc management services. The key assumption is the existence of mutual trust between the Kerberos servers installed at both institutions. This is important because whenever a user logs into Kerberos at their institution they will be able to access those resources at the second institution to which they have access.

AdHoc is divided into two distinct modules. (1) AdHoc web application provides a graphical web interface where users and administrators manage access to their resources. Kerberos provides authentication to the AdHoc web application. (2) AdHoc policy manager is responsible for modifying the user access policies of the underlying resources.  Four example services are shown; NFS or OpenAFS can be used  for shared file storage between the institutions. Access to the compute cluster can be provided using SSH or Web portal.

Summary

The presented architecture implements a federated security model to allow the secure and intuitive sharing of resources. It provides the following benefits:
  • Single point of access policy management,
  • Easy to use graphical interface for managing access policies,
  • Single-Sign On, users provide their password only once
  • Standards based with many services able to work out-of-the-box

Bookmark and Share

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a01156f69dc6b970c01348288dd3d970c

Listed below are links to weblogs that reference Scalable federated security with Kerberos:

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

It is recommended to implement federated security using the Internet standards based LDAP and Kerberos.

The single point of access is convenient to say the least. These features are what make the program so valuable and unique. I'd gladly switch software programs for convenience like that.

Tony
braun corporation

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment