Nicole,
Sorry got to dash, but just quickly...
To be clear, I am not criticising the Federations well considered rules, policies or recommendations.
I am just making the point that if SPs want/need to hold personal data they must be very clear on why and also how they obtain them - the consequences of which are different when you are passed them by an IdP, than if the SP collects them from the user.
(Hopefully we can discuss again at IdP meeting in May?)
Cheers,
Ross
> -----Original Message-----
> From: Discussion list for Shibboleth developments [mailto:JISC-
> [log in to unmask]] On Behalf Of Nicole Harris
> Sent: 11 April 2007 12:02
> To: [log in to unmask]
> Subject: Re: Athens resouces on the UK federation
>
> Hi Ross
>
> The actual rules of the Federation in relation to data protection only say
> that:
>
> - The Member must comply with any applicable legislation in relation to
> data protection and privacy, including without limitation, the Data
> Protection Act 1998.
> - The Member must use its reasonable endeavours to comply with the
> Recommendations for Use of Personal Data.
>
> The recommendations made are recommendations. If an organisation is
> currently collecting personal data and has being doing so for some time
> and
> has processes in place for managing this - I would assume that these
> processes are already compliant with the Data Protection Act which has
> been
> in place for some time.
>
> If this is not felt to be enough, combined with the terms of the license
> and
> the terms of Federation membership, then I'd be happy to start a dialogue
> around what assurances are needed and where to make this exchange
> possible.
>
>
> My reading of the Federation documents does not imply that Service
> Providers
> should not collect personal data at all...or am I missing something?
>
> N.
>
> -----Original Message-----
> From: Discussion list for Shibboleth developments
> [mailto:[log in to unmask]] On Behalf Of Ross MacIntyre
> Sent: 11 April 2007 11:27
> To: [log in to unmask]
> Subject: Re: Athens resouces on the UK federation
>
> Apologies for apparent silence thus far and for possibly now lighting the
> blue touch paper.
>
> A note of caution - MIMAS (& other SPs) would *love* to receive quality
> assured attributes for the users of our services from IdPs.
> For example, it would save us from asking the user to try and provide us
> with correctly formed email addresses, which we have to try to deal with
> when they fail - wastes so much time and the user gets irritated when
> alerts
> haven't appeared.
>
> However, the Federation's 'rules' covering the transmission of the
> attributes, where they (conceivably) constitute personal data would
> require
> us to have an agreement in place with each IdP to clarify who would be
> liable if the wrong data was associated with an individual. Their
> recommendation is effectively for no SP to hold personal data supplied
> other
> than by the user. Square one.
>
> Yourdan said something along the lines of 'the most elegant of designs are
> often bastardised by real world contraints' and here's a case in point
> IMHO.
> Ross
> --------------------------------------------
> Ross MacIntyre T: +44(0)161-275-7181
> MIMAS Service Manager F: +44(0)161-275-6071
> Manchester Computing M: +44(0)778-095-6424
> The University of Manchester
> Oxford Road
> Manchester M13 9PL U.K.
> Email: [log in to unmask]
> Skype: ross.macintyre
> --------------------------------------------
> ________________________________________
> From: Discussion list for Shibboleth developments
> [mailto:[log in to unmask]] On Behalf Of Nicole Harris
> Sent: 11 April 2007 10:40
> To: [log in to unmask]
> Subject: Re: Athens resouces on the UK federation
>
> Yes!
>
> There is a good example of MIMAS doing this here:
> http://www.mimas.ac.uk/shibboleth/dissemination/Educause2006MacIntyre.ppt.
>
>
> ________________________________________
> From: Discussion list for Shibboleth developments
> [mailto:[log in to unmask]] On Behalf Of Alistair Young
> Sent: 11 April 2007 10:34
> To: [log in to unmask]
> Subject: Re: Athens resouces on the UK federation
>
> thanks Nicole. Yes, look forward to the day the resources can be access
> natively via shibboleth.
>
> That brings me back to my original question, before I confused everyone
> and
> myself with gateways.
>
> The resources that currently require personal information to be entered
> manually. Will they make use of attributes for this purpose when they
> become
> proper citizens of the federation?
>
> Alistair
>
>
>
>
> --------------
> mov eax,1
> mov ebx,0
> int 80h
>
>
>
>
> On 11 Apr 2007, at 10:33, Nicole Harris wrote:
>
> Hi Alistair
>
> You are describing the Shibboleth - Athens Gateway, i.e. a Shibboleth
> Identity Provider accessing an Athens Resource (not the Athens -
> Shibboleth
> Gateway). The integration guide describing this is at:
> http://www.athensams.net/upload/athens/pdf/shib-athens-integration1.0.pdf.
> None of the Resource Providers will be aware of Shibboleth as they don't
> support Shib, they support Athens and JISC / Eduserv are providing the
> interoperability with the Federation.
>
> Science Direct will shortly be available for direct Shibboleth -
> Shibboleth
> access (you won't need to use the gateways). For the other resources, I
> would suggest that you should report these errors to the Eduserv helpdesk:
> [log in to unmask]
>
> The gateways only support limited attribute exchange so it will not be
> possible to pass all details via attributes whilst using this route so
> some
> data entry will be required. Direct access via the Federation will
> eventually take away this issue.
>
> N.
>
> ________________________________________
> From: Discussion list for Shibboleth developments
> [mailto:[log in to unmask]] On Behalf Of Alistair Young
> Sent: 11 April 2007 10:13
> To: [log in to unmask]
> Subject: Re: Athens resouces on the UK federation
>
> Hi Nicole,
>
> We are having problems with the following resources. They are accessed via
> the Athens Shibboleth Gateway. i.e. Go to www.athens.ac.uk, choose My
> Athens, alternative login and authenticate at your IdP.
>
> AFAIK the Athens Shibboleth Gateway only supports 2 attributes.
> eduPersonTargetedId and userRole. But the doc states 3 attributes that
> don't
> include userRole.
>
> Are we talking about the same gateway?
>
> ScienceDirect (displays login error page when connecting via the Athens
> Shibboleth Gateway, although you appear to logged in)
> RefWorks (have replied saying they do not support Shibboleth, although
> they
> are listed in the resources when you access My Athens via the shibboleth
> gateway)
> Biomedical Images (asks for personal information - no account linking
> between shibboleth and athens accounts). It's not a problem per se. Just
> that the users are asking why doesn't "know" about their "normal" athens
> account.
> European Sources Online - (access denied when access through the athens
> shibboleth gateway)
>
> Alistair
>
>
>
>
>
>
> --------------
>
> mov eax,1
> mov ebx,0
> int 80h
>
>
>
>
>
>
> On 11 Apr 2007, at 10:06, Nicole Harris wrote:
>
>
>
> Hi Alistair
>
>
> It would be helpful if you could highlight the specific service in
> question
> as I am struggling to see where you are having a problem.
>
>
> Many thanks
>
>
> Nicole
>
>
> -----Original Message-----
> From: Discussion list for Shibboleth developments
> [mailto:[log in to unmask]] On Behalf Of Alistair Young
> Sent: 10 April 2007 20:28
> To: [log in to unmask]
> Subject: Re: Athens resouces on the UK federation
>
>
> Thanks Nicole,
>
>
> The Athens Shibboleth Gateway supports the userRole attribute. This
> carries your Athens permission set.
>
>
> So this isn't propagated to providers. Ok. It's a way to "group" resource
> access links in My Athens.
>
>
> I wasn't aware the resource providers were members of the federation.
> AFAIK the gateway uses completely different metadata from the federation?
>
>
> However, there's still no way to get seamless access to a resource using
> attributes alone. You still have to provide personal information. So the
> ARP makes no real sense. It doesn't state up front the information you
> must release to an SP to get access. Once you get there, the SP asks for
> more information, outwith anything that is defined in your ARP.
>
>
> Users are finding this confusing. They have always accessed these
> resources using their Athens username/password. Now they access the same
> resource but using Shibboleth and they are treated as a new user by the
> resource provider.
>
>
> I can't see any way for providers to match up these two credentials to the
> single account. So you end up re-creating all your alerts/settings that
> you've set up with your normal athens account. You have to do it all again
> if you come in via shibboleth.
>
>
> So presumably your eduPersonTargetedId must be constant for that resource
> or your back to square one. Gives food for thought on what information at
> an IdP to use to create that attribute.
>
>
> Alistair
>
>
> --
> mov eax,1
> mov ebx,0
> int 80h
>
>
> Hi Alistair
>
>
>
>
>
>
> A couple of points of clarification - the Athens to Shibboleth Gateway
> only
> connects Athens users to Shibbolised / Federated resources that are
> members
> of the UK Federation. For more information about resources available via
> this route please see the Federation website: www.ukfederation.org.uk
> <http://www.ukfederation.org.uk/> . This may be why Service Providers who
> claim to support shibboleth are not compliant with the gateways. If there
> is a problem with any of the live resources in the Federation, please
> report
> this to the UK Federation helpdesk: [log in to unmask]
>
>
>
>
>
>
> To answer the rest of your question, the Athens to Shibboleth Gateway
> supports three attributes: eduPersonScopedAffiliation and two version of
> eduPersonTargetedID. At present, no other attributes are supported via
> the
> Athens to Shibboleth Gateway. For more information please see:
> http://www.athensams.net/upload/athens/pdf/athens-shib-integration1.0.pdf.
> *Please note this is not the case for the Shibboleth to Athens Gateway*.
>
>
>
>
>
>
> Federated access through the UK Federation with no intermediary (gateways,
> outsourced IdPs etc.) recommends that four attributes should be made
> available to Service Providers but supports other attributes being passed
> in
> the metadata. This is described in section 7.4 of the technical
> recommendations for participants.
>
>
>
>
>
>
> I hope this helps
>
>
>
>
>
>
> Nicole
>
>
>
>
>
>
> _____
>
>
> From: Discussion list for Shibboleth developments
> [mailto:[log in to unmask]] On Behalf Of Alistair Young
> Sent: 10 April 2007 15:06
> To: [log in to unmask]
> Subject: Athens resouces on the UK federation
>
>
>
>
>
>
> We're starting to see a lot of "issues" arise with resources behind the
> Athens Shibboleth Gateway, such as resource providers who claim to support
> Shibboleth but do not. Other resource providers who ask for personal
> information once you've reached them via Shibboleth and others who just
> don't know what's happening.
>
>
>
>
>
>
> It seems the gateway carries out the Authn part while the Authz is left up
> to the resource providers. However, they have no attributes on which to
> base
> authz so they ask for more information from the user. i.e. the user logs
> in
> to Athens via the gateway then fills in the blanks at the resource
> provider.
>
>
>
>
>
>
> Will this still be the case in the uk federation? Or will resource
> providers
> make more use of attributes to provide seamless access to their resources?
>
>
>
>
>
>
> To be fair, resource providers have always asked for this extra
> information
> but as our users understand Shibboleth, that shouldn't have to happen any
> more. Attributes are meant to be used to transport this information to the
> resource provider.
>
>
>
>
>
>
> Alistair
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --------------
>
>
> mov eax,1
>
>
> mov ebx,0
>
>
> int 80h
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ----------------------------------------------------------------------
> Anything in this message which does not clearly relate to the official
> work of the sender's organisation shall be understood as neither given
> nor endorsed by that organisation.
>
>
>
>
> ----------------------------------------------------------------------
>
>
>
>
> ----------------------------------------------------------------------
> Anything in this message which does not clearly relate to the official
> work of the sender's organisation shall be understood as neither given
> nor endorsed by that organisation.
>
>
>
>
> ----------------------------------------------------------------------
>
>
> ----------------------------------------------------------------------
> Anything in this message which does not clearly relate to the official
> work of the sender's organisation shall be understood as neither given
> nor endorsed by that organisation.
>
>
> ----------------------------------------------------------------------
>
>
>
> ----------------------------------------------------------------------
> Anything in this message which does not clearly relate to the official
> work of the sender's organisation shall be understood as neither given
> nor endorsed by that organisation.
>
>
> ----------------------------------------------------------------------
>
> ----------------------------------------------------------------------
> Anything in this message which does not clearly relate to the official
> work of the sender's organisation shall be understood as neither given
> nor endorsed by that organisation.
>
>
> ----------------------------------------------------------------------
|
