Cuckoo (Graham Mason, Ed Beddows)

VIRTUAL ORGANISATIONAL TOOLS

BY

GRAHAM MASON&

ED BEDDOWS

[email protected]

Cuckoo ProjectCardiff University & Kidderminster College

Introduction

What will be covered in this presentation

Special thanks to Brown University (USA), Bristol University and Newcastle University.

Project history and collaboration

Overview of the aims of the CUCKOO Project

Understanding VO’s

Project Research

Technical aspects of VO Tools and their use

Project history and

collaboration

Cardiff University Lead Partner in the CUCKOO Project

Kidderminster KC-ROLO Project Team

VLE Middleware

Cardiff University and Kidderminster College have been very active over the past 4/5 years in Shibboleth development and research:

ASMIMA project

Identity Project

KC-ROLO Project

VLE Middleware Shibboleth IdP & SP installations, Single Sign-on and JANET (UK) Training

Aims of the CUCKOO Project

Shibboleth 2

VO Tools

Collaboration with other institutions

Review VO tools and concepts

investigate good privacy protection for users

Investigate potential problems & the benefits

Investigate permission and access control in HE-FE

Highlight the difficult problems of tool selection, identity management and access control in both Shibboleth 1.3 and Shibboleth 2.0

Approach

Two phased project

Kept it simple

More hands-on

Reviewing existing developments

Two year project ending April 2009 Phase 1: consolidate and review existing national and

international tools for the establishment and developments of Virtual Organisations (VO’s)

Review of current VO Tools and their effect in the HE-FE communities

Phase 2: Shibboleth 2 and the potential new capabilities within Virtual Organisations

Installation of Shibboleth 2 Idp and SP Test and reporting on how the current VO tool work with Shibboleth 2 Report on Signet and Grouper combination and the components with

Shibboleth 2

Project Research

What are Virtual Organisations?

What are VO Toolkit Tools and management?

Shibb 2 install fest in June/July 2008, mainly for technical developers

What are Virtual Organisations?

Collaboration process between institutions/communities that share real resources

Computing resources, Scientific instruments, Bandwidth, Shared data (medical/research/museum materials), content.

Members normally have a common interest, size or cluster

VO’s defined by their permission or access rights

Underlying commonality between VO’s is the Core Middleware platform that gives the authorisation and access to the resources, which in our case is Shibboleth

Project Research

What are Virtual Organisations?

What are VO Toolkit Tools and management?

Shibb 2 install fest in June/July 2008, mainly for technical developers

Research highlighted the lack of use of the Signet privilege tool throughout the in academic community.

Grouper within FE is more appealing to institutions that have lots of resources

The benefits were seen when a larger institution could group/manage resources such as: VLE’s (Moodle in most cases), WIKI’s, Library Systems, Repositories and other bespoke web applications.

Smaller institutions expressed they couldn’t see the use of this tool. Most institutions viewed the tools as a LDAP provisioning tool and felt

that their ICT Services would manage resources via their Active Directory or the resources itself directly (such as Moodle). Although this approach would lose the group delegation functionally that is found in grouper.

Managing these resources and ownership was also seen as an issue, as the collaboration between LRC, ICT Services and ILT is not evident in FE.

In small institutions (or institutions with few resources) view that managing resources at a single point of access can be seen as an overhead and would opt to directly manager the resource.

Grouper/Signet/COmanage

OUR PROGRESS SO FAR

So what’s the problem?

How many web apps do you have? The more apps the more administrative overhead!

How many groups are you part of? The more groups the more administrative overhead!

How many permissions need to be setup for each app? The more permission rules the more administrative

overhead!

How do you delegate access management? Delegate management of access to resources to those who

need it, and in a friendly way.

How do you control how external users get access to your resources? Resource owners should be in charge of access

Our Goals

Provide a way to centrally administer groups

Provide a way to centrally administer privileges

Give delegation to the people who actually run the resource

Provide a mechanism to allow resource management to external users

The tools we’re looking at

GrouperSignetGrouper+Signet=COmanage

What is Grouper?

Group management tool Central consolidation for management of

groups/roles

Grouper itself can be provisioned by multiple sources

Provisions existing group data for applications Via LDAP, Web Services, command line, Java

interfaces, RDMS on the way

Delegate control back to those in the know No more overworked angry network managers!!

Customisable web interface

What is Signet?

Privilege management tool Central consolidation for management of

privileges

Signet itself can be provisioned by multiple sources

Provisions privilege data for applications Via LDAP, command line, Java interfaces

Delegate control back to those in the know No more overworked angry network

managers!!

Customisable web interface

Grouper+Signet = Comanage – enabling VO’sSourced from http://middleware.internet2.edu/co

Grouper+Signet = Comanage – enabling VO’s

Making use of both tools and scripts to create accounts for external users on your local system

Overview

Diagram sourced from https://wiki.internet2.edu/confluence/display/i2miCommon/Ldappc+v1.0

Our setup

Our applications 5 Moodle’s – Shib enabled – authN & authZ 1 Repository – Shib enabled - authN & authZ 2 Wiki’s – Shib enabled – authN & authZ

8 separate apps to administer

On the plus side Users are put in course groups at start of term Entitlement data is updated each day Apps already use a central source for authZ (Shib via

LDAP)

On the down side Adhoc role assignments are still made in each

separate app Only IT staff and automated scripts can assign these

values

Our setup - Grouper

Test platform CentOS 5, Java 1.5, Tomcat 5.5, Apache 2.2, MySQL

5

Active Directory as source In the real world this would also include MIS

systems etc

Created 10 groups, each representing a real course Done through the Grouper UI, in production this

would be provisioned by MIS or other user identity databases

Used LDAPPC to provision Active Directory with group information

Application implementation- Grouper

Moodle has built in LDAP enrolment capabilities via groups, but it’s weak! Just like shibboleth enabling web apps, some will be

harder to “grouper” enable than others

Grouper more useful in this case not for making simple access decisions, but to use as groupings for privilege data

Wiki and repository is easy to do with .htaccess, but doesn’t scale very well Just ask Cal!

Application implementation- Grouper

Cardiff intend to use Grouper as part of their Identity Management

However, the following weaknesses exist: No real time provisioning from eDirectory to Grouper No real time provisioning from Grouper to eDirectory No ability to override automatic provisioning – e.g.

flag a user so they don’t get overridden by a source update

Thoughts so far - Grouper

The hardest part of implementing Grouper effectively is ensuring the applications can use the data correctly

Moodle (or any complex app) requires development time Either in Moodle, or the provisioning process

Is it really going to be useful? We think Moodle can do just fine without it! Signet may be

another story though We already have groups in AD based on MIS, so only becomes

useful with adhoc groups

Non intuitive web user interface

Our setup - SignetTest platform

CentOS 5, Java 1.5, Tomcat 5.5, Apache 2.2, MySQL 5

Active Directory as source

Used LDAPPC to provision Active Directory with eduPersonEntitlement

Application implementation - Signet

Moodle can do Shibboleth enrolment We use this already, so no app changes required!

Tested delegation by allowing VLE champion to assign roles through Signet interface

Wiki and repository, again, only done with .htaccess so far

Thoughts so far - Signet

It’s not used as much as Grouper, so less support and documentation is available Luckily it does use a lot of the Grouper

prerequisites, e.g. Java, Tomcat, LDAPPC,

Like Grouper, the Signet interface could be better

For apps that are able to read ldap or shib attributes this is a great way to add central control and delegation

Thoughts so far - COmanage

Work ongoing in this area

Still duplicates users account in your LDAP store

Simple to get going (only once you have Grouper and Signet installed!)

Conclusions

Both require good identity management in the first place Grouper & Signet do not create users

Federated access is also important

The more apps you have the more useful it is What if you have few apps?

Is it worth the development time For both Grouper/Signet and all your apps

Lack of real time synchronisation can be a problem for some

Some may prefer just Grouper, others Signet, or maybe both

Further work needs to be made on the UI’s of both tools

Rolling the two apps together would reduce setup time

Questions?

More info:

CUCKOO Project: http://www.kidderminster.ac.uk/cuckoo

Grouper:http://grouper.internet2.edu

Signet:http://middleware.internet2.edu/signet

COmanage:http://middleware.internet2.edu/co

Thank-you