Shibboleth

Presented by Alan Robiette from JISC

Presentation as pdf

We’ll get on to exactly what Shibboleth is later, but lets just start by saying it is a method for authentication/authorisation.

Currently the closest we have to a nationwide authentication/authorisation system is Athens. This has been developed and recently seen Single Sign On and Devolved Authentication. Also done proof of concept on alternative ways of authentication/authorisation – e.g. digital certificates.

However, now facing new challenges. Need to look at not just institutions to publisher authentication, but also cross-institutional working, ‘virtual organisations’ with complex authorisation needs (driven by growth in e-research, GRID etc.)

Also external developments – emergence of new standards e.g. SAML

So – next generation AAA infrastrucutre must support scenarios such as:

Internal (intra-institutional) applications
Management of access to 3rd party digital library-type resources
Inter-institutional use – e.g. shared e-learning scenarios
Inter-institutional use – ad hoc sharing of resources

We are now seeing Virtual Organisations emerging – where people distributed across the world want to work together and share resources.

There is also a link-up with UKERNA location-independent networking project – authenticated guest access to a network. Being called ‘eduroam’ – implications of running a RADIUS infrastructure on participating campuses.

Finally, there is work going on with Internet2 and the NMI-EDIT programme – this is run by the US National Science Foundation, and is looking at development of middleware, and is taking a joint approach with JISC with some of the work in this area.

Some Principles:
Authentication is the responsibility of the user’s home site
Authorisation is the responsibility of the resource owner

So – what is Shibboleth?
An architecture developed by the Internet2 middleware community.
It is NOT an authentication scheme – expects the home institution to do this
It is NOT an authorisation scheme – expects this to be done by the resource owners
It is an architecture, and open source implementation

How does it work? Need a diagram for this, and still isn’t incredibly clear, but some key points:
WAYF – Where Are You From? This is a key part of the architecture – it is only by this that you can tell where they are going to authenticate (home institution).
ARP – attribute release policy – only gives out the information needed at any point for authorisation – for example, don’t need to give out your name if all the resource needs to know that you come from a specific campus.

Shibboleth is getting good international acceptance (US, Australia, Finland, Switzerland, France – and UK of course)
Basic software now well tested – around 30 US universities working with it seriously, plus several content vendors – Swiss national HE system deployment
Satisfies the main requirements ‘out of the box’ – digital library, shared e-learning and internal use scenarios – doesn’t yet do the VO stuff very well.

However – still not very user friendly, lacks management tools, demanding to installa nd run, might require outsourced or packaged service for smaller institutions. Also still a relatively unsophisticated authorisation model – single attribute authority (who manage the ARP mentioned above), decision engine not very sophisticated – this is currently being addresses in JISC development projects.

So – what needs to be done?
Implement Shibboleth on JISC services – provide critical mass of shibboleth-enabled resources
Gain experience on campuses – in a variety of institutions
Build the national components – which are relatively few
‘Charm offensive’ with publishers

JISC is providing an ‘assisted take-up service’ – contract announcement is imminent, and expected to be available this month (March 2005). This should provide documentation, tools and support.

Some projects are being funded to get institutions to trial Shibboleth on their campuses. JISC are looking for outcomes by Summer 2006 – this coincides with a break in the Eduserve/Athens service contract.

In the short-term, Athens and Shibboleth will coexist – no current plan to remove Athens. In fact Athens is being developed to work in a Shibboleth environment. A two way gateway is being developed so that Athens campuses can reach Shibboleth resources and vice versa.

Campuses will need to review strategy – Shibboleth, Athens DA and EduRoam all pose similar questions. Need to have robust Identity Management solution which sits at the heart of any of these technologies.

In the longer term – currently speculate that:
Some institutions (perhaps especially smaller ones) may want to stay with Athens. As may small publishers.
OR – if Shibboleth becomes pervasive, support or tailoring for particular situations may be the answer
JISC will need to keep national service requirements under review
No question of forcing institutions to migrate on any specific timescale

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Shibboleth

Presented by Alan Robiette from JISC

Presentation as pdf

We’ll get on to exactly what Shibboleth is later, but lets just start by saying it is a method for authentication/authorisation.

Currently the closest we have to a nationwide authentication/authorisation system is Athens. This has been developed and recently seen Single Sign On and Devolved Authentication. Also done proof of concept on alternative ways of authentication/authorisation – e.g. digital certificates.

However, now facing new challenges. Need to look at not just institutions to publisher authentication, but also cross-institutional working, ‘virtual organisations’ with complex authorisation needs (driven by growth in e-research, GRID etc.)

Also external developments – emergence of new standards e.g. SAML

So – next generation AAA infrastrucutre must support scenarios such as:

Internal (intra-institutional) applications
Management of access to 3rd party digital library-type resources
Inter-institutional use – e.g. shared e-learning scenarios
Inter-institutional use – ad hoc sharing of resources

We are now seeing Virtual Organisations emerging – where people distributed across the world want to work together and share resources.

There is also a link-up with UKERNA location-independent networking project – authenticated guest access to a network. Being called ‘eduroam’ – implications of running a RADIUS infrastructure on participating campuses.

Finally, there is work going on with Internet2 and the NMI-EDIT programme – this is run by the US National Science Foundation, and is looking at development of middleware, and is taking a joint approach with JISC with some of the work in this area.

Some Principles:
Authentication is the responsibility of the user’s home site
Authorisation is the responsibility of the resource owner

So – what is Shibboleth?
An architecture developed by the Internet2 middleware community.
It is NOT an authentication scheme – expects the home institution to do this
It is NOT an authorisation scheme – expects this to be done by the resource owners
It is an architecture, and open source implementation

How does it work? Need a diagram for this, and still isn’t incredibly clear, but some key points:
WAYF – Where Are You From? This is a key part of the architecture – it is only by this that you can tell where they are going to authenticate (home institution).
ARP – attribute release policy – only gives out the information needed at any point for authorisation – for example, don’t need to give out your name if all the resource needs to know that you come from a specific campus.

Shibboleth is getting good international acceptance (US, Australia, Finland, Switzerland, France – and UK of course)
Basic software now well tested – around 30 US universities working with it seriously, plus several content vendors – Swiss national HE system deployment
Satisfies the main requirements ‘out of the box’ – digital library, shared e-learning and internal use scenarios – doesn’t yet do the VO stuff very well.

However – still not very user friendly, lacks management tools, demanding to installa nd run, might require outsourced or packaged service for smaller institutions. Also still a relatively unsophisticated authorisation model – single attribute authority (who manage the ARP mentioned above), decision engine not very sophisticated – this is currently being addresses in JISC development projects.

So – what needs to be done?
Implement Shibboleth on JISC services – provide critical mass of shibboleth-enabled resources
Gain experience on campuses – in a variety of institutions
Build the national components – which are relatively few
‘Charm offensive’ with publishers

JISC is providing an ‘assisted take-up service’ – contract announcement is imminent, and expected to be available this month (March 2005). This should provide documentation, tools and support.

Some projects are being funded to get institutions to trial Shibboleth on their campuses. JISC are looking for outcomes by Summer 2006 – this coincides with a break in the Eduserve/Athens service contract.

In the short-term, Athens and Shibboleth will coexist – no current plan to remove Athens. In fact Athens is being developed to work in a Shibboleth environment. A two way gateway is being developed so that Athens campuses can reach Shibboleth resources and vice versa.

Campuses will need to review strategy – Shibboleth, Athens DA and EduRoam all pose similar questions. Need to have robust Identity Management solution which sits at the heart of any of these technologies.

In the longer term – currently speculate that:
Some institutions (perhaps especially smaller ones) may want to stay with Athens. As may small publishers.
OR – if Shibboleth becomes pervasive, support or tailoring for particular situations may be the answer
JISC will need to keep national service requirements under review
No question of forcing institutions to migrate on any specific timescale

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.