2011Nov29

From FilteredPush
Jump to: navigation, search


Etherpad for meeting notes: http://firuta.huh.harvard.edu:9000/FP-2011Nov29

Agenda

Carry To Next Week

  • NSF Workshop RFP
  • Reports from iDigBio presentation
  • Pending Tech Issues
    • API for Query and for Cluster finding
    • Tech group needs to make a decision on or set a date for decision for the query language for pub-sub for Apple Pie.
    • Tech group needs to make a decision on or set a date for decision for the domain objects supported for Apple Pie.
    • Tech group needs to decide on or set a date for decision for the scope, composition, and implementation of the "global cache."

Reports

Notes

Filtered Push Team Meeting 2011 Nov 29

Present: Bertram, Bob, Maureen, Paul, Dave V. Johnathan R. (briefly)

Agenda:

Notes:

  • Tech Issues
    • FilteredPush Message, e.g. Requirement16Soln
    • Authentication/Authorization, Dave Vieglais to join us.

Bob: What do we need to do to use DataOne's authentication/authorization services? Targeting testing within next 6 months. Thoughts about oauth?

David: Delegating authentication to CIlogon (https://cilogon.org/), provides mechanism for users to login to an authenticaiton provider. Login results in a client side certificate that DataOne can use with interactions with user. Embedded in certificate is identity information for the individual, this can then be used by DataONE in evaluating authorization.

Access control done on a per-object basis (data objects or metadata objects). Evaluation of access control rules applies with each user request.

Interesting question of how FP may fit into this whole scheme.

Paul: Story about authentication/authorization - Yale undergraduates enter harvard specimen data from images in morphbank, new specimen annotations transported to harvard and identity of data entry person is used as part of criteria for automatic ingest of new specimen record.

Bob: Also common story about sensitive geolocations for species, read authorization needs credentials to see unredacted data.

David: Is there an existing authentication framework you need to work with?

Bob: I don't think so, we did some very basic testing with oauth1.

David: lots of existing systems with password/username credentials, DataONE is using certificates here, identity carried through that mechanism. Does need coding on server side to use those credentials.

Paul: Yes, client side coding needed.

David: Authentication pieces working now in test DataONE system. Hard part appears to be identity mapping (e.g. with LDAP servers). Each user needs to login through their common identity provider, then this identity needs to be mapped to local identity (e.g. LDAP) providers. Challenges related to authorization of mappings (who is able to assert/verify that a potential mapping is a valid mapping of one identity to another, doing so securely). System administration issues around, e.g. bulk mapping of identities.

Paul: Drawing on board
Whiteboard sequence diagram of authentication
- user authenticates to morphbank/cilogin, gets cert, uses cert to sent message to FP Access point. FP Access point validates user's credential, and signs message validating this. FP Access point's certificate is used by consumers of message to validate trust in the user,

David: Authentication by CILogon, identity mapping between nodes as a DataONE service. Is there a use case in DataONE to expose the identity mapping beyond the member nodes? This particular individual has this list of [services?] they are known to have access to?

David: Currently sorting out public release, identity mapping won't be there untill later release, expected within about 6 months - good time for the interaction.

Bob: Within next 6 months is a good time for the discussion on our side. Still sounds to me like we should keep moving in this direction.

Bob: Questions from Bertram, Lei?

Bertram, I'm good.

Lei, likewise.

Maureen: Any blocking issues?

Answers: No.

Quick review of FP Message work

Bob: Requirement, messages require identifiers. Put up a mockup of a message cache. Approach is nice at showing up defects in the design work so far. 5 messages, only two meet requirements of test. See: Requirement16Soln, xpath queries will need to be formulated with code, this shows that it can be done to handle a fairly complex set of queries. Thus far seeing no reason to aggregate on messages - no requirement for RDF of message.

Bertram: XPath/XQuery exercises: http://www.db-class.org/course/quiz/list?type=quiz