Jon Warbrick wrote:
> The problem that I'm seeing is that some suppliers appear to be enabling
> Shib access (at least for their current customers) based on ePSA of
> member@<inst>.ac.uk, and perhaps release of an ePTID, despite the fact
> that the 'authorised users' clauses in the relevant contracts may not
> match either the UK federation definition of member@... or that of the
> institution.
>
> For example I believe that one service, currently restricted to staff,
> will shortly grant access via Shib based on member@<inst>.ac.uk.
The way I'd want to look at this (wishful thinking, perhaps) is that in
this situation, you're authenticating and making an attribute statement;
the service provider is the one authorising access on the basis of your
statement.
> This obviously worries the people who sign the contracts - if
> unauthorised access comes to light as a result, who will be held
> responsible?
If the service provider has read the (admittedly vague) eduPerson and UK
TRP definitions of member@x and chooses to regard your assertion of
member@x as sufficient for them to authorise access to their resource,
I'm frankly a little bewildered that your contracts people would think
that would be your responsibility.
Accepting member@x as adequate information for authorisation seems to me
to be an implicit acceptance by that SP that the definition of member@x
is close enough to what they want. If they aren't happy with that
definition, they shouldn't accept member@x and should come to you
looking for something more specific. They haven't done so in your case,
as I understand it.
> There is also a danger that it will influences the
> allocation of member@... ePSA values, perhaps only to that subset of
> people who fall within the 'authorised users' clauses of _all_ an
> institution's electronic resources. This is clearly wrong and overly
> restrictive, and will really come home to haunt us if/when Shib access
> takes off further - perhaps into the e-science arena.
Yes, this would clearly be wrong. Let's not do that.
-- Ian
|