Using the Shibboleth to Athens Gateway: Difference between revisions

From RavenWiki
Jump to navigationJump to search
(→‎Issues: Problems caused by gateway caching)
(Assorted tweaks)
Line 1: Line 1:
{{shib-project}}
{{shib-project}}


The Shibboleth to Athens gateway allows people to authenticate using Shibboleth and then gain access to resources that are protected by Athens. The gateway is run under contract for JISC by EduServ. The University currently has 'testing' access via the gateway and this means that it doesn't work quite as it will once in production (see below).
The Shibboleth to Athens gateway allows people to authenticate using Shibboleth and then gain access to resources that are protected by Athens. The gateway is run under contract for JISC by EduServ - it appears that use of the gateway will be available at no cost to us until at least July 2011 - see [http://involve.jisc.ac.uk/wpmu/jam/ this blog entry]. The University currently (as at 2007-05-17) has 'testing' access via the gateway, but this means that it doesn't work quite as it will once in production (see below).


Note that our Shibboleth IdP, on which use of the gateway depends, is itself only a pilot and liable to service interruptions without notice.
Note that our Shibboleth IdP, on which use of the gateway depends, is itself only a pilot (as at 2007-05-17) and liable to service interruptions without notice.


==Access Control==
==Access Control==


Use of the gateway is currently controlled by membership of particular groups in ''lookup'' - in due course some people will be automatically allowed gateway access based on other information in lookup, and membership of the groups will only be required for people who can't be automatically identified. The groups are:
Use of the gateway is currently controlled entirely by membership of groups in [http://www.lookup.cam.ac.uk lookup]. In due course many people will be automatically granted gateway access based on other information in lookup, and then membership of the groups will only be required for people who can't automatically be identified as being eligible. The groups are:


; [http://www.lookup.cam.ac.uk/group/100926 Shibboleth service Athens gateway overrides]
; [http://www.lookup.cam.ac.uk/group/100926 Shibboleth service Athens gateway overrides]
: Members of this group are granted access to the majority of resources, corresponding to the cam#default0 permission set. In due course, staff and students of the University will get access automatically and membership of this group will only be required for everyone else.
: Members of this group are granted access to the majority of Athens resources, corresponding to the cam#default0 Athens permission set. In due course, staff and students of the University will get access automatically and membership of this group will only be required to grant access to users who can't otherwise be identified.


; [http://www.lookup.cam.ac.uk/group/100927 Shibboleth service medical overrides]
; [http://www.lookup.cam.ac.uk/group/100927 Shibboleth service medical overrides]
: Members of this group additionally get access to medically-restricted material, both via the gateway (corresponding to the cam#aaemo permission set) and directly via Shibboleth. In due course, at least some staff and students of the University will get this additional access automatically and membership of this group will only be required for everyone else.
: Members of this group are granted access to medically-restricted material, both via the gateway (corresponding to the cam#aaemo permission set) and directly via Shibboleth. In due course, some staff and students of the University will get this additional access automatically and membership of this group will only be required to grant access to users who can't otherwise be identified.


; [http://www.lookup.cam.ac.uk/group/100925 Shibboleth service Athens gateway blacklist]
; [http://www.lookup.cam.ac.uk/group/100925 Shibboleth service Athens gateway blacklist]
: Members of this group are administratively prohibited from accessing resources via the Shibboleth to Athens gateway. This group is provided to implement short-term blocks in response to reports of misuse, etc.
: Members of this group are administratively prohibited from accessing any resources via the Shibboleth to Athens gateway. This group is provided to implement short-term blocks in response to misuse, etc. This prohibition applies both to members of the two groups above and to anyone receiving access automatically.


It is a limitation of the current implementation that membership of these three groups has to be visible within the University to work. If visibility is suppressed, either by the group's manager or the individual member, then the corresponding rights won't be available. This will be resolved in due course.
It is a limitation of the current implementation that membership of these three groups has to be visible within the University for it to work. If visibility is suppressed, either by the group's manager or the individual member, then the corresponding rights won't be available. This will be resolved in due course.


Membership of these three lists and other details about them are managed by the members of the [http://www.lookup.cam.ac.uk/group/100924 Shibboleth service lookup group managers] group. Members of this group will find that they can go to the 'Members' tab of any of these four lists and from there either remove an existing member, or add new members by quoting their CrsID(s).
Membership of these three lists and other details about them are managed by the members of a fourth group, [http://www.lookup.cam.ac.uk/group/100924 Shibboleth service lookup group managers]. Members of this group will find that they can go to the 'Members' tab of any of these four lists and from there add or remove members.
They can also edit other details of the four groups (such as title, access controls, etc.) but in general should avoid doing so.  


Note that when you authenticate to the gateway, it seems to cache various bits of information about you including your permissions. Because of this, changes to group membership don't immediately affect access control decisions even if you quit your browser and restart. I suspect that some/most/all cache entries expire within an hour or so.
Note that when you authenticate to the gateway, it seems to cache various bits of information about you including your permissions. Because of this, changes to group membership don't immediately affect access control decisions even if you quit your browser and restart. I suspect that some/most/all cache entries expire within an hour or so.
Line 28: Line 29:
Once in production it will (I think) be possible to access any Athens-protected resource using the gateway by navigating to the resource, following links to log in via Athens, selecting the 'Alternate login' (or similar) link, and choosing 'University of Cambridge' from the resulting dialogue. However, since we are still in testing, doing this just throws up a box containing contact details.
Once in production it will (I think) be possible to access any Athens-protected resource using the gateway by navigating to the resource, following links to log in via Athens, selecting the 'Alternate login' (or similar) link, and choosing 'University of Cambridge' from the resulting dialogue. However, since we are still in testing, doing this just throws up a box containing contact details.


For the time being, you first have to authenticate to the EduServ 'My Athens' service using this URL:  
For the time being, you first have to authenticate using a manually-entered URL. The following URL will authenticate you and give you access to the EduServ 'My Athens' service:  


   https://auth.athensams.net/setsite.php?id=urn:mace:eduserv.org.uk:athens:provider:cam.ac.uk&ath_dspid=ATHENS.MY&ath_returl=%2Fmy
   https://auth.athensams.net/setsite.php?id=urn:mace:eduserv.org.uk:athens:provider:cam.ac.uk&ath_dspid=ATHENS.MY&ath_returl=%2Fmy


This will trigger a Shibboleth authentication and take you to your My Athens page. This also (I think) sets a cookie so that any subsequent access to Athens resources during your current browser session, both via links from My Athens and direct from supplier sites, will automatically use the Shibboleth route which may mean that they 'just work' without further action by you. 'Normal' behaviour will be resumed if you quit and restart your browser - note that this means that you can't use gateway access and 'Classic Athens' during the same browser session. It is my understanding that this will still happen once our use of the gateway is in production mode - once you have accessed any Athens resource via the gateway all your subsequent accesses during that session will automatically use the gateway.
I suspect that similar URL's can be constructed for a different service by replacing ATHENS.MY in the ath_dspid parameter with the internal Athens code for the service. I haven't yet worked out how to find these codes, but this may not be important since this is all largely an artefact of the current 'testing' status of our gateway access.
 
As I understand it, the gateway authentication process sets a cookie so that any subsequent access to any Athens resource during your current browser session, both via links from My Athens and direct from supplier sites, will automatically use the gateway route, which may mean that they 'just work' without further action by you. 'Normal' behaviour will be resumed if you quit and restart your browser - note that this means that you can't use gateway access and 'Classic Athens' during the same browser session. It is my understanding that this will still happen once our use of the gateway is in production mode - once you have accessed any Athens resource via the gateway all your subsequent accesses during that session will automatically use the gateway.


Note that, since many of our Athens-protected resources are available by IP address from within the University, it may be difficult to easily distinguish between access granted by address and access granted via the gateway when working from computers on the University network.
Note that, since many of our Athens-protected resources are available by IP address from within the University, it may be difficult to easily distinguish between access granted by address and access granted via the gateway when working from computers on the University network.
Line 46: Line 49:
3. Even once in production, anyone navigating to a supplier site and choosing to authenticate via Athens will see big 'Username' and 'Password' boxes, as well as a small 'Alternate login' link. It will be a documentation/training challenge to convince them to follow the alternate login link and NOT to put their Raven userid and password into the boxes provided which won't work and which will compromise the security of their Raven account.
3. Even once in production, anyone navigating to a supplier site and choosing to authenticate via Athens will see big 'Username' and 'Password' boxes, as well as a small 'Alternate login' link. It will be a documentation/training challenge to convince them to follow the alternate login link and NOT to put their Raven userid and password into the boxes provided which won't work and which will compromise the security of their Raven account.


4. The gateway effectively 'creates' an Athens ID for everyone who uses it. This is a meaningless, 20 character string starting with an underscore. Unfortunately some sites thing it's a good idea to display it, c.f Adept Scientific: "Special prices for _wplsf6omk2rfw7lfveb. As a member of Cambridge University Library you are eligible for...".
4. The gateway effectively 'creates' an Athens ID for everyone who uses it. This is a meaningless, 20 character string starting with an underscore that users will not in general recognise. Unfortunately some sites think it's a good idea to use it like a name e.g. Adept Scientific: "Special prices for _wplsf6omk2rfw7lfveb. As a member of Cambridge University Library you are eligible for...".


5. The fact that the gateway caches things like permission sets means that if someone tries and fails to gain access then, even after we add them to the relevant group, there is going to be a delay before they can access the resource that want.
5. The fact that the gateway caches things like permission sets means that if someone tries and fails to gain access then, even after we add them to the relevant group, there is going to be a delay before they can access the resource that want.

Revision as of 07:23, 17 May 2007

ShibbolethLogoColorSmall.png
WARNING: This page is retained as a historical record but is out-of-date and is not being maintained.

This was a working document belonging to the Computing Service's Shibboleth Development Project. This project is complete (Raven now supports Shibboleth) and this document only remains for historical and reference purposes. Be aware that it is not being maintained and may be misleading if read out of context.

The Shibboleth to Athens gateway allows people to authenticate using Shibboleth and then gain access to resources that are protected by Athens. The gateway is run under contract for JISC by EduServ - it appears that use of the gateway will be available at no cost to us until at least July 2011 - see this blog entry. The University currently (as at 2007-05-17) has 'testing' access via the gateway, but this means that it doesn't work quite as it will once in production (see below).

Note that our Shibboleth IdP, on which use of the gateway depends, is itself only a pilot (as at 2007-05-17) and liable to service interruptions without notice.

Access Control

Use of the gateway is currently controlled entirely by membership of groups in lookup. In due course many people will be automatically granted gateway access based on other information in lookup, and then membership of the groups will only be required for people who can't automatically be identified as being eligible. The groups are:

Shibboleth service Athens gateway overrides
Members of this group are granted access to the majority of Athens resources, corresponding to the cam#default0 Athens permission set. In due course, staff and students of the University will get access automatically and membership of this group will only be required to grant access to users who can't otherwise be identified.
Shibboleth service medical overrides
Members of this group are granted access to medically-restricted material, both via the gateway (corresponding to the cam#aaemo permission set) and directly via Shibboleth. In due course, some staff and students of the University will get this additional access automatically and membership of this group will only be required to grant access to users who can't otherwise be identified.
Shibboleth service Athens gateway blacklist
Members of this group are administratively prohibited from accessing any resources via the Shibboleth to Athens gateway. This group is provided to implement short-term blocks in response to misuse, etc. This prohibition applies both to members of the two groups above and to anyone receiving access automatically.

It is a limitation of the current implementation that membership of these three groups has to be visible within the University for it to work. If visibility is suppressed, either by the group's manager or the individual member, then the corresponding rights won't be available. This will be resolved in due course.

Membership of these three lists and other details about them are managed by the members of a fourth group, Shibboleth service lookup group managers. Members of this group will find that they can go to the 'Members' tab of any of these four lists and from there add or remove members. They can also edit other details of the four groups (such as title, access controls, etc.) but in general should avoid doing so.

Note that when you authenticate to the gateway, it seems to cache various bits of information about you including your permissions. Because of this, changes to group membership don't immediately affect access control decisions even if you quit your browser and restart. I suspect that some/most/all cache entries expire within an hour or so.

Using the Gateway

Once in production it will (I think) be possible to access any Athens-protected resource using the gateway by navigating to the resource, following links to log in via Athens, selecting the 'Alternate login' (or similar) link, and choosing 'University of Cambridge' from the resulting dialogue. However, since we are still in testing, doing this just throws up a box containing contact details.

For the time being, you first have to authenticate using a manually-entered URL. The following URL will authenticate you and give you access to the EduServ 'My Athens' service:

 https://auth.athensams.net/setsite.php?id=urn:mace:eduserv.org.uk:athens:provider:cam.ac.uk&ath_dspid=ATHENS.MY&ath_returl=%2Fmy

I suspect that similar URL's can be constructed for a different service by replacing ATHENS.MY in the ath_dspid parameter with the internal Athens code for the service. I haven't yet worked out how to find these codes, but this may not be important since this is all largely an artefact of the current 'testing' status of our gateway access.

As I understand it, the gateway authentication process sets a cookie so that any subsequent access to any Athens resource during your current browser session, both via links from My Athens and direct from supplier sites, will automatically use the gateway route, which may mean that they 'just work' without further action by you. 'Normal' behaviour will be resumed if you quit and restart your browser - note that this means that you can't use gateway access and 'Classic Athens' during the same browser session. It is my understanding that this will still happen once our use of the gateway is in production mode - once you have accessed any Athens resource via the gateway all your subsequent accesses during that session will automatically use the gateway.

Note that, since many of our Athens-protected resources are available by IP address from within the University, it may be difficult to easily distinguish between access granted by address and access granted via the gateway when working from computers on the University network.

Issues

1. For sites that support customisation and the like, note that your identity as established via the gateway is different to your identity established via 'Classic Athens' - you are in effect two different people.

2. Some sites are known not to work via the gateway. There a (depressingly long) list at http://www.athensams.net/allresources/nongatewayresources.aspx

Westlaw is one - the error message displayed (Description: Error getting sponsor based on prefix for: _wplsf6omk2rfw7lfveb - No Athens prefix found in DB.) confirms that they are still relying on the outdated practice of checking Athens ID prefixes to identify home institution, a practice that it incompatible with the gateway.

3. Even once in production, anyone navigating to a supplier site and choosing to authenticate via Athens will see big 'Username' and 'Password' boxes, as well as a small 'Alternate login' link. It will be a documentation/training challenge to convince them to follow the alternate login link and NOT to put their Raven userid and password into the boxes provided which won't work and which will compromise the security of their Raven account.

4. The gateway effectively 'creates' an Athens ID for everyone who uses it. This is a meaningless, 20 character string starting with an underscore that users will not in general recognise. Unfortunately some sites think it's a good idea to use it like a name e.g. Adept Scientific: "Special prices for _wplsf6omk2rfw7lfveb. As a member of Cambridge University Library you are eligible for...".

5. The fact that the gateway caches things like permission sets means that if someone tries and fails to gain access then, even after we add them to the relevant group, there is going to be a delay before they can access the resource that want.