15:34
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.
ContextThe 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.
ChallengeThe 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.
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
- 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 dragdrop functionality of the web interface.
The 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.
SummaryThe 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