User Authentication

From Metadata-Registry
Revision as of 11:15, 18 October 2005 by Diane (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Informal definition of terms

Primarily defines access control and ability to receive and/or grant access privileges. This a combination of the gForge concepts of workspace/system role and individual functional permissions. In our context "Registered User" and "Feed Manager" are roles.
Primarily an organizational property defining membership in an organizational Group. This is analogous to the gForge concept of Workspace.

Some Collection, Metadata Provider, and Recommendation Services Use Cases Organized loosely by Roles. What's missing from these informal use cases is definitions of all of the terms, formal scope definitions, etc. but you may be able to get the idea...

Registered Users (Recommenders)

  1. Resource Recommendation. Registered Users will have the ability to recommend resources for review for inclusion in the Collection. A 'Managing' Editor wishes to be able to select certain Registered Users to include in named groups of Selectors. Members of Selector Groups will have special attributes in the system, although they won't have more privileges than Registered Users. Trusted Users and Editors will be granted the special ability to 'Approve' Recommended Resources for inclusion in the Collection. The 'Managing' Editor would also like to be able to select certain Selectors to be Trusted Selectors in order to expand the number of people able to Approve Recommended Resources. Trusted Selectors would be able to add/remove Selectors from the Selector Groups of which they are a member.
  2. Trusted Selectors and Selectors would be asked to select Focus Areas (subjects and grade levels for instance) for which they would accept some responsibility for recommending resources. This will allow the 'Managing' Editor to monitor over time how well they're covering the areas for which they're responsible. Trusted Selectors would be able to receive notifications of newly recommended resources in their selected Focus Areas, as well as any other Focus Area. These notifications could be in the form of emails, email digests, or RSS feeds. Each notification would contain a link to an edit/approval page that would allow the Trusted Selector to Approve as is, edit the Recommendation metadata and then Approve, or flag a Recommendation as 'Reviewed and Not Approved.'
  3. Editors would be able to select to receive a notification that a Recommended Resource had been Approved by a Trusted User and will be presented with a link to the same edit/approval page.

Feed Managers (oaiAdmin) and Editors

  1. Collection Registration: An Editor or oaiAdmin Registers a Collection of Resources by providing a URL for a collectionResource that represents the Collection, and metadata describing in aggregate the Resources that are members of the Collection. Either an existing metadataRecord describing a Recommended Resource, an existing metadataRecord from the Repository, or a metadataRecord created by a DC-DOT/iVia crawl may be used as the basis for the metadata. The metadata describing the collectionResource is submitted to the NSDL MR as a metadataRecord that is a member of the NSDL Collections Aggregation. If the Editor that submitted the metadataRecord is not the Selector for the NSDL Collections (Managing Editor), the Managing Editor is notified of the submission and may review and edit the metadataRecord.
  2. dataProvider Registration: An Editor or oaiAdmin Registers a dataProvider (OAI Server) by providing a baseURL for the dataProvider, validating that the dataProvider at that baseURL passes a set of functional unit tests, and providing a metadataRecord describing the Services producing the data being provided. The metadataRecord describing the dataProvider is submitted to the Repository as a metadataRecord that is a member of the Services Aggregation.
  3. dataFeed Registration: An Editor or oaiAdmin Registers a dataFeed (aka 'Creates a Harvest Request) by first selecting a Collection. An oaiAdmin must select a Collection that they have Registered (see case 2 above). An Editor may select any Collection. The Editor or oaiAdmin must then select a dataProvider. An oaiAdmin may select only dataProviders which they, or an oaiAdmin that they have authorized, have Registered. An Editor may select any Registered dataProvider. The Editor or oaiAdmin can then set the parameters that will be sent to the dataProvider to create a dataFeed, send a harvestRequest to the Harvest/Ingest? Service, and define a repeating schedule to resend the harvestRequest.

Grant of oaiAdmin status

  1. An oaiAdmin may self-register and be granted immediate oaiAdmin status if:
    • they provide a baseURL with their registration or registration update and
    • the email used to verify registration matches one of the admin email addresses supplied by the 'Identify' response of the server.
  2. A Registered oaiAdmin can delegate the oaiAdmin role for the dataProviders for which they are Registered to any other Registered User.
  3. An Editor may grant oaiAdmin status for one or more dataProviders to any Registered User.

Definition of Roles

  1. guest
    • no privileges
    • view only
  2. Registered user
    • add/edit/delete recommended resources
  3. Trusted user
    • all registered user privileges
    • can accept-as-collection resources s/he has recommended
    • can use complex metadata editor
    • can request services (like iVia crawl) for resources s/he has recommended
  4. Group manager
    • all trusted user privileges
    • can edit group properties
    • can add/remove registered users from group
    • can pre-register and invite group members
    • can accept-as-collection resources anyone in the group has recommended
    • can request services for resources anyone in the group has recommended
    • may manage more than one group
    • can authorize other group managers for groups she manages
  5. Feed manager (this corresponds to some extent to OAI Admin)
    • all group manager privileges
    • if registered with the same email as the admin of a feed, can register that feed without further authorization
    • can associate data feeds with accepted collections that she, or a member of a group she manages, have recommended
    • can manage harvest requests and scheduling
    • can manage harvest notifications
    • can authorize other feed managers for a datafeed she manages
    • can manage more than one feed
  6. Feed associate/editor
    • basically a registered user that has been added to a dataFeed group
    • can manage harvest notifications
  7. CRS editor
    • all of the privileges above
    • may create organizational groups
    • may assign any feed to any collection
    • may request services for any collection
    • authorizes group managers
    • authorizes feed manages that must be authorized manually
  8. MMS admin
    • all of the privileges above
    • may manage system-level data

Some Group Requirements/Definitions

  1. Groups can be anything a CRS Editor says they are
  2. Groups currently only have ID, title, description attributes.
    • Examples are "NSF program managers", "Exhibitors"
  3. Any registered user and above may be a member of one or more Groups
  4. A Group may be managed by more than one Group Manager
  5. All data feeds may have 0 or more Feed Managers
  6. All data feeds have an associated Group
  7. The feed manager is automatically the Group Manager for the feed Group

Some User Authentication Process flow scenarios

It seems to me that each individual system should either make use of a single central registration/login service that's capable of sending a user back to the original system entry point (the page they asked for that needed authorization), or each system needs to supply their own registration/login and share that with the rest of the NSDL.

Scenario I (and some questions):

  • User has registered with and has an identity
  • User logs in to
  • User comes to MMS, which checks/verifies the user's identity
  • MMS sees that user is new to MMS and asks user for more information which it stores -- locally?
  • Does the MMS share some of this info? and with whom?


  • User comes to MMS, which checks the user's identity
  • MMS sees that user is new to MMS
  • MMS asks user for basic registration information which it stores -- where?
  • or does the MMS send the user to basic registration 'elsewhere' and then ask 'elsewhere' to send the user back to the MMS
  • MMS then asks user for more info
  • At what point is the user's identity authenticated (via email I assume)? Is it by 'elsewhere' or by the MMS?
  • who shares what with who and when?

An alternative scenario:

  • MMS handles its own user registration and authentication
  • User must register with MMS even if registered elsewhere
  • User may login to MMS, MMS will authenticate and at some point in the future share this authentication with other systems
  • User may login to any other associated system, come to the MMS, and if registered with the MMS be logged into the MMS as well.