The Guanxi project (www.guanxi.uhi.ac.uk) has been thinking hard about
this need to establish registries for attributes. Your idea of an ADP is a
good one, so to add fuel to the fire, here is what we have been thinking
about. We fired this out to the shib lists some time ago, but not any
response…
We have a Java IdP and a Java SAML, are building a Java SP.
ADDI - Attribute Description & Discovery Interface
Shibboleth supports asking for any attribute under the sun
using SAML AttributeDesignator elements in a SAML AttributeRequest. If no
AttributeDesignators are present, the whole lot gets dumped out subject to
the ARP.
Thinking just now is that an ADDI wouldn't be dynamic (would it? -
dicuss!) - there would be no way for an IdP to map discovered attributes
to it's own set. i.e., an ADDI
registry for OrgX could say "you need to give us the UserIdentification
attribute for your users to access such and such a resource" - what is a
UserIdentification attribute? No Semantics involved, so no mapping
possible.
The only way it would work is if the ADDI only described known attributes,
such as eduPerson, eduCourse schemas, etc. and vendors, such as Novell,
published mappings from those known attribute sets to their proprietary
sets (NDS). That wouldn't scale though, so the ADDI would have to also
hold mapping files (xml) that an IdP could use.
Proposal:
1) ADDI registry at an SP has resource specific attribute sets. i.e. an
IdP queries the SP's ADDI to find out what attributes are required to
access a specific resource.
2) ADDI registry also holds vendor specific mappings. These would be URN
identified for common discovery, e.g. urn:novell:nds
This would in effect be WSDL for AAAA, i.e., an IdP would find out what
attributes are required to access the service and also how to map them to
it's own local set, all provided by the SP's ADDI service.
This now leads to a new SAML profile, in the first instance just extending
shibboleth's Browser/POST:
1) User accesses resource at SP
2) SP sends GET request to user's IdP after WAYF finds out where that is.
3) IdP authenticates user and sends AuthenticationStatement back to SP.
4) SP sends AttributeRequest to SP
5) NEW - IdP queries SP's ADDI service for required attributes and any
vendor specific mappings based on the resource the user wants to access.
6) IdP maps required attributes to local set and releases them based on ARP
7) SP makes decision based on incoming attributes from the IdP.
So, there's only one modified step (5) - the IdP queries the SP's ADDI
service, rather than relying on the presence/absence of
AttributeDesignator in the AttributeRequest. In this case the
AttributeRequest would contain the address of the SP's ADDI service.
This is an addition to SAML, but we have an implementation of SAML, called
SAMUEL (SAMl Used in ELearning) that could take this.
So, Guanxi could provide 3 things:
1) An IdP-side ADDI call instead of AttributeDesignator parsing
2) An SP-side ADDI service
3) Extended SAML AttributeRequest to publish the address of the ADDI
service. This would be done with SAMUEL, if nothing else.
If a normal AttributeRequest from a standard shibb SP came in, Guanxi
would just switch to normal shibb mode and forget about ADDI.
Over time, if successful, the new ADDI attribute is submitted to OASIS for
inclusion in SAML2.1? and the ADDI profile is submitted as a new OASIS
SAML profile.
Discuss!-)
Regards,
Sean Mehan
Guanxi Project Manager
>
>> From: "Paschoud,J" <[log in to unmask]>
>> Date: 14 April 2005 15:18:45 BST
>> To: <[log in to unmask]>, <[log in to unmask]>
Subject: RE: [JISC-SHIBBOLETH] Reed puts 300,000 at risk of online
fraud: A good argument for using Shibboleth? Attribute Demand Policies
>>
>> Ross,
>>
>> [apologies for cross(-border) posting]
>>
>>> If we'd had time during the session I'd like to have discussed where
decisions about what attributes are reasonable (?) should be made -
for the
>>> JISC community. Would it be a subtask of Federation management? Are
there existing examples? This is on the resource provider side - which
>>> attributes could/should be requested, not the institution's ARP. (Tho' I
>>> guess it is the flip side of ARP, but with 'Release' replaced by
'Request'.)
>>
>> I thought I'd try naming this thing you describe, as Attribute Demand
Policies (ADPs) applied by a ResourceProvider (ReP; or
>> ServiceProvider, if you must). Then we won't get into having to
distinguish ARPs from ARPs (if you follow me ;->).
>>
>> I BCCd my message to Steven Carmody and Ken Klingenstein as well, and
Steven has come back with a very similar issue, about a vendor
>> 'unreasonably'(?) demanding identifying attributes.
>>
>> In the JISC Info Environment context, where we record the ADP for a
particular resource would obviously(?) seem to be in extensions to the
current resources registry; go talk to Ann Apps!
>>
>> Internationally, this would indeed seem to be an important bit of
Federation policy (v2), and as it's being pondered over on both sides
of the Atlantic, should probably best happen on one of the Internet2
Shib lists.
>>
>> It also occurs to me that encouraging the establishment of (some kind
of) registry(ies) of the attributes that vendors typically demand to
allow access to each of their identifiable services/resources (via an
institutional license) would help us to establish the requirements for
eduPerson, in a very pragmatic way. I'm confident that Keith Hazelton
is on shib-users, and that he'll pick that one up ;->
>>
>> John
>>
>> -----Original Message-----
>> From: Ross MacIntyre [mailto:[log in to unmask]]
>> Sent: 14 April 2005 10:26
>> To: [log in to unmask]
>> Subject: Re: [JISC-SHIBBOLETH] Reed puts 300,000 at risk of online
fraud: A good argument for using Shibboleth?
>>
>>
>> John,
>> Yes, I noted it too! Ironic since they've been a keen early adopter.
>>
>> If we'd had time during the session I'd like to have discussed where
decisions about what attributes are reasonable (?) should be made - for
the
>> JISC community. Would it be a subtask of Federation management? Are
there existing examples? This is on the resource provider side - which
>> attributes could/should be requested, not the institution's ARP. (Tho' I
>> guess it is the flip side of ARP, but with 'Release' replaced by
'Request'.)
>>
>> I ask since we've just Shibbed Zetoc Search, which only really needs to
know
>> your institution - since it includes institutional preferences. However,
>> also having some persistent identifier makes the sessioning more
straight-forward and resilient. Add to this that we *need* a persistent
identifier for Zetoc Alert, to link to previously declared search terms
&/or
>> journal lists for notification. Is it not reasonable to say Zetoc needs
both
>> Institutional Identifier plus Persistent Individual Identifier?
>>
>> We've other examples of other info being required by the rights holder.
Typically data currently gathered via registration. Though it may also
have
>> implications for exchange of attributes to/from any intervening gateway?
>>
>> I wondered how commercial concerns have compromised between what is
required
>> for the application/service to work as intended, what the rights holder
may
>> require and what their Marketing Dept may like.
>>
>> Cheers,
>> 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]
>> --------------------------------------------------------------------
>>
>>> -----Original Message-----
>>> From: Discussion list for Shibboleth developments [mailto:JISC-
[log in to unmask]] On Behalf Of Paschoud,J
>>> Sent: 14 April 2005 08:20
>>> To: [log in to unmask]
>>> Subject: Reed puts 300,000 at risk of online fraud: A good argument for
>>> using Shibboleth?
>>>
>>> [apologies for cross-posting - but it's not at all clear who are the
intended target audiences for JISC-SHIBBOLETH and AUTHENTICATION, and
how/if they overlap]
>>>
>>> "Reed puts 300,000 at risk of online fraud" is in the print Guardian of
>>> 13-Apr-05, and at:
>>> http://www.guardian.co.uk/business/story/0,,1458121,00.html
>>> "An online security breach at Reed Elsevier has allowed access to the
personal details of hundreds of thousands of people - nearly 10 times
as
>>> many as previously thought - the company admitted yesterday.
>>> The Anglo-Dutch group said personal information on as many as 310,000
American citizens might have been accessed fraudulently in its Seisint
division, part of LexisNexis."
>>>
>>> Unfortunately I read the paper after I'd given the last of my briefing
sessions on Shibboleth at the UK Serials Group Conference yesterday -
because it would have been *such* a good way of illustrating the
end-user privacy benefits of e-resources vendors (amongst which Reed
Elsevier is globally dominant by a long chalk) moving from current
methods of access management to Shibboleth - and thereby us
>>> (libraries,
>>> universities, etc) *not* handing over to Elsevier personal information
about our students and staff (that we're trusted with by those
people),
>>> just so they can access services like LexisNexis!
>>>
>>> John
>>> --
>>> John Paschoud
>>> (Project Manager, PERSEUS: www.angel.ac.uk/PERSEUS/)
>>> (Project Manager, ShibboLEAP: www.angel.ac.uk/ShibboLEAP/)
>>> Projects Manager & InfoSystems Engineer
>>> LSE Library
>>> London School of Economics & Political Science
>>
>
--
Sean Mehan
Head of Computing Research
SMO, UHI
|
