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.
>
>
> ----------------------------------------------------------------------
>
|