|
Phil, (and MATU@Eduserv),
LSE is in the process of redirecting our users from the 'classic Athens' (CA) route of access to Shibboleth access to resources. Some resources will be directly Shib-enabled (such as those in the SDSS Federation) and the majority, at present, will be via the Athens Gateway.
In most cases our users will follow links we give them in our Library e-resources management system (Endeavor's ENCompass), so it's possible for us to use long complex URLs with information embedded (such as the LSE IdP) to achieve things like minimum user interaction with WAYF, etc. For users who find/guess their own links to LSE-licensed resources, it's clearly our problem as a library to sort out whatever access problems they bring to our helpdesks - which we'll do by recommending that they use the links we provide for them.
Not all resources of significance to LSE users are yet available via the Gateway. (We are making contact with Westlaw and other vendors to educate them about modern access management, and we'll encourage our peer institutions in the UK and abroad to do likewise.) Therefore the transition will be gradual, and some of our users will be using combinations of resources via different access methods in a session, including CA and the Gateway. It's important to us that such use cases are supported.
You've said previously that much of the support you provide is not so much technical as in the form of advice to institutions about how best to present interfaces to users. I'm therefore seeking your advice about how best we should overcome the problem caused by the ath_da cookie - by changes that you, us or both of us can make to our respective ends of the process.
I'm asking you via the jisc-shibboleth list because I think your advice may be useful to any other institutions trying to use the Gateway; and I'd be interested to hear about their experiences or solutions too (or just which institutions are in a similar situation to us).
As a requirement by Eduserv of our registration process to use the Gateway, we've issued you with personal credentials to impersonate a LSE user, entitled to access our licensed resources. We're running a test instance of ENCompass, publicly accessible but not advertised to our users, and we're using that to test access to resources, one by one, before we put new URLs for them in our live instance of ENCompass. I'll send you the entry-point URL to that, off-list, so that you can see for yourself what the front end of our user interface looks like. For purposes of testing solutions to "the ath_da cookie problem", I'll get someone to include some CA resources (such as Westlaw) in it too.
We'd love to be able to report to the JISC Core Middleware Advisory Board that the Gateway is useful!
TIA for your help!
John
LSE Library
________________________________
From: Phil Leahy [mailto:[log in to unmask]]
Sent: Thu 22/09/05 14:12
To: [log in to unmask]
Subject: Re: [JISC-SHIBBOLETH] Athens DA / Shibboleth gateway and classic Athens
Simon
The ath_da cookie denotes that the user is not a classic Athens user. This
is because some error handling returns classic Athens users to an Athens
authentication point (AP) with an appropriate error message, which would not
be intuitive for Gateway users. One tangible effect of this is if an Athens
session times out for a Gateway user, they are given a route back to their
organisation's login point. This is consistent with a single sign on (SSO)
environment, and it is inevitable that in attempting to logging on twice to
the same SSO, the user will be required to log out of one and then into the
second.
We are prepared to review the behaviour of this cookie, but the question has
to be asked: is this simply a transitional issue? Early adopter
institutions should be expecting these kinds of issues to arise, and the
project was created so that they could be addressed by the time the wider
community start using the Gateway. We welcome this type of feedback as it
will help determine where the service needs to be improved.
The scenarios that Simon mentions are either in the hands of the LSE
(deciding whether to send the eduPersonTargetedID) or the service provider.
Taking Simon's second example, Westlaw have decided to delay implementing
Gateway compliance. This is not something that Eduserv has any influence
over. Perhaps subscribing institutions can raise this with Westlaw directly
if they have similar concerns? Eduserv is also prepared raise this but we
need to be able to demonstrate to the service provider that a significant
number of users are effected by their non-compliance.
On the general issue of Gateway compliance, although there are a few high
profile services that are not yet Gateway-compliant, the majority of Athens
services are, and we have assurances from most of the rest that they have
scheduled the necessary work. Those that have not yet committed to the work
are being persuaded that there is a business case for doing so, via requests
from their own customers and from Eduserv.
As for Simon's last point, I can only assume that there has been no response
to the query on the AthensDA list because all Athens-protected resources are
DA-compliant, and so there is no need to login via an AP.
Regards
Phil Leahy
Service Desk Team Leader
Eduserv Athens
access management
_____
[log in to unmask]
tel: +44 (0)1225 474333
fax: +44 (0)1225 474332
http://www.eduserv.org.uk/athens/
On Fri, 16 Sep 2005 17:15:15 +0100, Simon McLeish <[log in to unmask]> wrote:
>Hi,
>
>We're currently in the process of joining the Athens Shibboleth gateway
>with our Shibboleth 1.2 (soon to be 1.3) IdP, and our plan for doing
>this is to gradually move our Athens-protected resources from classic
>Athens to access via the gateway, starting with the lower use resources
>to ensure that everything is properly tested and to minimise the risks
>if something goes wrong.
>
>The use case where things don't work is for a user who first accesses a
>resource through the gateway, and then in the same browser session
>access a second resource using classic Athens (e.g. Westlaw, which is
>not currently gateway compliant). The second access fails, and it is
>impossible to get to the classic Athens login page.
>
>Access to a resource via the gateway sets four cookies for the session
>(i.e. until closing the browser), one of which (named ath_da, with the
>value 1) seems to then prevent access to other resources using classic
>Athens. The behaviour exhibited is to direct the users to the Shibboleth
>gateway, rather than to a classic Athens login. This happens both with
>resources on the list of Shibboleth compliant resources which don't work
>for the LSE (because we're not currently sending the gateway the
>eduPersonTargetedID or for other reasons; this includes Lexis-Nexis) and
>classic Athens resources listed as non-compliant (such as Westlaw UK).
>The result is that access to these resources is not possible through the
>route we want to direct our users to take, or not possible at all (in a
>browser session where the user has already visited a Shibboleth
>compliant list). If you block cookies from athensams.net, the gateway
>just delivers the user to the classic Athens login page for every
>resource.
>
>We feel that without a simple fix, this makes it much more difficult for
>us to move to using the gateway for our general users until all the
>resources protected by Athens which we subscribe to are compliant, or
>until the gateway ceases to set the cookie. We can't think of a simple
>enough work around to make it a service that our users will be willing
>to access, and so we are effectively back to the position that we have
>to use classic Athens until something changes - not at all what we wish
>to be the case, as an early Shibboleth adopter.
>
>This issue has already been raised on the Athens DA list by, with no
>response (the question was whether this was an issue for DA users as
>well), and I have taken it up with the Athens helpdesk. Hopefully there
>will be a resolution soon, as until that time any institution which
>wishes to move to gateway use will have serious difficulties in doing
>so.
>
>Simon McLeish
>Projects Technical Officer,
>London School of Economics
|
