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