John
The problems you refer to are all associated with non-gateway compliant
services, so these do not diminish the usefulness of the gateway. With
90% of Athens resources being gateway-compliant, we are working with the
suppliers of the remaining services to get them to use a feature we
released over two years ago! :o)
In the meantime we can see that there are usability issues associated
with using multiple authentication services, and we will be happy to
explore these with the LSE. As you say, we have already registered for
a set of LSE credentials; if you can confirm that these credentials have
access to the test instance of ENCompass, please send the URL to Eduserv
Athens Local Authentication Support and we will take a look.
Regards
Phil Leahy
Service Desk Team Leader
Eduserv Athens
access management
_____
[log in to unmask]
tel: +44 (0)1225 474302
fax: +44 (0)1225 474332
http://www.eduserv.org.uk/athens/
_____
Eduserv Athens is a service of Eduserv Technologies Limited
-----Original Message-----
From: Discussion list for Shibboleth developments
[mailto:[log in to unmask]] On Behalf Of Paschoud,J
Sent: 27 October 2005 10:21
To: [log in to unmask]
Subject: Re: Athens DA / Shibboleth gateway and classic Athens
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
|