"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Identity and linking against it for Authorization

Currently all the users information is stored against the Identity Provider (IdP).

For Auscope to have fine grain access control with shibboleth authentication, we need a way of keeping the unique id of user, and then add attributes against this id. Once they have been stored, we would 'require' certain attributes to get access to certain services.

The AAF group have specified that the only unique way to identify a user is via the targetID and the IdP. When these two parts of information are used together, we have a universal identity which is totally unique. We will call this is called a scoped ID.

This means that if a user trys to access a service, with the scopedID and service request as the lookup, we can either grant or deny the service.

NOTE targetID is a hash and cant be humanly read.

Imagine this as a database table:
targetID provider service1 service2 service3
aaaaaaa curtin.edu.au no no yes
bbbbbb murdoch.edu.au yes yes no

Provided the query is designed specifically for that service, ie we know that the field service1 is for service1, we should have the ability to deny or grant access.

The trick is getting the targetID and the provider from the user. They don't know this! Yes its sent, and even appears in the logs, but how is that helpful the first time a user contacts you and asks for access?

We came up with the registerMe idea


Its a simple dynamic page, that is shibboleth protected and the shibboleth attributes are passed into the environment so the page can use them.

You would simply do the following
  1. http://our.main.portal.to.services/register (which is shibboleth protected)
  2. Forwarded to WAYF server.
  3. Log in at your institution.
  4. Allow your identity out (via targetID and provider)
  5. The dynamic page would read those variables, and hold them
  6. Fill in a "I want access to ..." form.
  7. Hit submit.

We would now have your unique identifier, and anything else you let us have, and a way of linking your UUID against what you get approved to use.

Now its the responsibility of the server protecting the service to make sure you (UUID) are allowed (attributes we store)

Thats it - now for the implementation. Anyone like python?

-- TerryRankine - 15 Nov 2007
Topic revision: r2 - 15 Oct 2010, UnknownUser

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).