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
|