Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  1. There should be a process for verifying service providers and registering official service provider administrators for each provider in EdUnify. These verified service providers with one or more vetted service provider administrators will appear as "verified" with both visual and data indicators in the PESC EdUnify web applications. Service providers who are not verified will appear as "unverified." (1)
  2. These service provider administrators will identify service managers for their organization who are authorized to register and manage services on behalf of the service provider.  Ideally, service provider administrators can specify service managers proactively from the EdUnify user base or approve submitters of web services as service managers for their organization at the time of web service submission (or not, the submitter may not qualify to be a service manager).  These features will facilitate collaboration and participation for new EdUnify users. (1)
  3. Unverified service providers and services will still be permitted, but the EdUnify application should offer links and buttons to encourage users to start and complete the verification process. (1)
  4. EdUnify should support both internal and web user based Security Assertion Markup Language (SAML) authentication when making authorization decisions for users with privileges, including service providers and service provider administrators.  Once federated authentication is implemented, EdUnify may implement other features around service provider administration and service managers. (2) This will not interfere with non-privileged user's access.
  5. Should we define what privileged and non-privileged user's are allowed to do here?
  6. Should we define what attributes are required for different levels of authorization here? Or perhaps simply state that we intend to do so later?There will be a definition of the various attributes a user must possess to qualify for specific roles as defined by the Business group.

Service Registration and Annotation


  1. The EdUnify Demonstration Registry leverages the experiences the BioCatalgue experience experiences in creating and searching a registry of web services. However, it is unlikely that all search scenarios can be predicted. Therefore the EdUnify registry will include a issue tracking mechanism that will collect requests for specialized features that may be specific to the target audience.


  1. SAML will be used to provide authentication tokens to the EdUnify portalweb application. (see Security and Authenticity above). The assertions provided by SAML carry rich details about the users. These assertions will be used for Authentication to various portions of the portal web application as described. These assertions also provide the tools for a detailed accounting mechanism.
  2. EdUnify will build or install a mechanism for storing parsed SAML, and account for usage based upon predetermined attributes. These accounting files will be leveraged to support the business use cases as they are published. In this manner, the portal web application will be positioned to support changes in the business model as they happen, increasing the flexibility of the portal and its value.