Building e-Infrastructures with AARC

This is a little bit of a pre-case-study as the AARC project hasn't even started at the time of writing.

Nevertheless, many projects are starting up and attempt to solve or work around the types of problems that AARC aims to address - either by building on existing work, or by reinventing the wheel and "solving" the problem again.

This article therefore looks at the AAI problems arising in a project building a new infrastructure, how they were traditionally addressed, and how they'd be addressed with the AARC project. As a case study, we look at how the NGS solved the problem and how a new project using AARC will solve the problem.

By "e-Infrastructure", we shall understand a service or services provided by geographically distributed participants (organisations) to also geographically distributed user communities, with a common management framework for managing user accounts, login, services provisioning, support, accounting, groups and roles and rights, etc.

Basic Requirements

Traditionally, such infrastructures would have a set of requirements for user management:

• Each user should have a single account
• The user identity should be persistent (it's the same user every time)
• Users should have roles which authorise them to perform actions or access resources.
• It should be possible for administrators to assign usage quotas to users, and for both admins and users to check their usage.
• Users should have sufficient training (and motivation) to ensure that they use the security technology securely.

These are just the basics; more complicated requiremetns could arise out of the need for non-repudiation for example, where users are billed for their usage or commit to specific actions, or requirements on levels of assurance to perform different types of actions on the infrastructure.

Case study 1: user management in the NGS

When the National Grid Service was set up, it built on a history of forerunner pilots developed within the UK e-Science programme. User authentication was done with the UK e-Science CA, a CA which provides certificates to a globally accepted (high) level of assurance using its own identity management processes. This enabled sharing users with other e-Infrastructures such as (then) TeraGrid or (then) EGEE. Nevertheless, many users from less technical research areas found certificates hard to manage. Once users had their authentication token they could sign up and submit a proposal, and an entry would be created in the UAS (user accounting system). Upon review of their proposals, managers would assign a CPU quota to each user (typically 10,000 CPU hours, but the amount would be reviewed annually or when it was running low). Users would map (by the certificate distinguished name) to a local account which could be a different one at each site - the account mapping was assigned from a pool of local accounts and kept fixed once the assignment had been made (so users could keep their local data in the account). If necessary, access to restricted software was done with Unix groups, so the local account was assigned membership to this group by administrators.

Case study 2: the Glorious Future of AARC

AARC aims to support new e-Infrastructures in four basic objectives:

1. It develops an integrated framework for AAI build on production infrastructures such as national identity management federations and eduGAIN.
2. As mentioned, some perhaps less technical research communities find certificates impossible to use, and an infrastructure built for/by them will use basic username/password which in turn meant users using weak passwords, share passwords with each other, forgetting passwords, writing them down, plus forgetting to update their account details. AARC aims to improve the uptake in these communities, to foster a culture where modern identity management is the default in a new infrastructure.
3. AARC will develop and "pilot" critical components for this infrastructure where existing work doesn't meet all the requirements. The classic example is authorisation: federated identity management will usually solve a new infrastructure's identity management problem but leave them lost at sea when it comes to managing authorisation and quotas.
4. Validate the results with research communities. Requirements have been gathered from a range of user communties - e.g. in the FIM4R working group - and feedback from the user communities will help guide the future work of AARC.

Thus, if the NGS were set up in the World of the Glorious Future of AARC, it could (likely) have:

• Connected identity management to the existing national federations for identity management via an IdP discovery process (WAYF or similar). Thus, interoperation with other e-Infrastructures could have been preserved provided users retain the same identity within each e-Infrastructure.
• Used AARC to engage with the certificate-hating communities, to help move them away from using (and expecting) usernames and passwords. NGS could also have benefited from the training offered by AARC, either training users directly or training the trainers.
• The basic idea of authorisation in AARC (as well in the work which will be built upon in AARC) is that communities manage their own authorisations, but those roles and rights are honoured insofar as possible within the e-Infrastructure. NGS had only a fairly coarse-grained authorisation, so would not have neeeded management of authorisation in the communities -
• NGS had a strong need for accounting services and, while AARC doesn't provide these directly, it aims to provide ways to implement them (probably in a circuitous way building on the current versions of those that were used in the NGS originally).

Conclusion

This case study is a bit odd as it builds on a project which finished years ago and imagines how it would have used the outcome of another (AARC) which will deliver services only in the years to come. The idea is to show that there is a need for the services which will be delivered by AARC, and that a new infrastructure, instead of using inappropriate technologies like username/password or reinventing the wheel, will instead build on services delivered by AARC. Today they can already build on what is provided by national IdM federations and eduGAIN but there are gaps, primarily in accounting and authorisations, and it is hoped that AARC will enable its customer infrastructures to plug those gaps in an interoperable way which requires little or no work on the customer infrastructure.