Hyrax Admin Interface: Difference between revisions
Line 42: | Line 42: | ||
# Hyrax user authentication and authorization service | # Hyrax user authentication and authorization service | ||
## View/set roles and their mapping to URLs - this is the basis for categorizing authorization. | ## View/set roles and their mapping to URLs - this is the basis for categorizing authorization. | ||
## View/set user <del>data</del> authorization<del>, attributes, thresholds, and priority</del> I think this should be done at the URL level - we authorize users to access specific sets of URLs. I thin the distinction between ''service'' and ''data'' is only making more work at this stage. At some point we will likely want to classify services as ''expensive'' and so on, but that's just too much to bite off for now. jhrg | ## View/set user <del>data</del> authorization<del>, attributes, thresholds, and priority</del> I think this should be done at the URL level - we authorize users to access specific sets of URLs. I thin the distinction between ''service'' and ''data'' is only making more work at this stage. At some point we will likely want to classify services as ''expensive'' and so on, but that's just too much to bite off for now. jhrg | ||
Line 65: | Line 64: | ||
## View/set OLFS and BES data catalog service settings | ## View/set OLFS and BES data catalog service settings | ||
# User Managment | # User Managment | ||
## <del>View user service access history and data requests</del> I think this will require too much information be retained about users and their past actions. You could implement this with log analysis, but given that the logs' content can be changed and the logs are logs and thus likely not complete (truncated, rotated, etc.) I think it's just too much to bite off now. jhrg | |||
## <del>Manage user access rights to data</del> | ## <del>Manage user access rights to data</del> | ||
## <del>Manage user and service access rights, quotas, thresholds, and priorities</del> I think these two are really being covered by 2-4. | ## <del>Manage user and service access rights, quotas, thresholds, and priorities</del> I think these two are really being covered by 2-4. | ||
# Debugging Tools | # Debugging Tools | ||
## <del>[[HAI Use Case: Compare Server output with debugging associated with the request|Compare Server output with debugging associated with the request]]</del> I think to be really useful this will have to be very involved - we'll need to compare lots of different kinds of outputs and many of them will need some kind of 'filter' (eg binary to ascii). jhrg | ## <del>[[HAI Use Case: Compare Server output with debugging associated with the request|Compare Server output with debugging associated with the request]]</del> I think to be really useful this will have to be very involved - we'll need to compare lots of different kinds of outputs and many of them will need some kind of 'filter' (eg binary to ascii). jhrg |
Revision as of 20:36, 8 November 2010
This is a place to start discussing peoples desires/needs for a Hyrax Administrators Interface (HAI).
Background
Members of the Hyrax users community are developing robust, highly available data services in operational settings, and have asked for an administrators interface that will allow them to monitor, control, reconfigure, and debug the Hyrax frontend and backend servers from a single console.
Additionally, to support external services integration with the Hyrax data catalog and service, Hyrax needs to provide an administration interface for service configuration and data catalog changes (e.g. adding new data sets to a catalog). Example of an external service integration with Hyrax is an organisation's digital library service for registering and maintaining access to data products. Once the user registers a new data set including data location and data access rights, the user may select an access service and protocol such as Hyrax OPeNDAP or WMS. This external service will connect to a Hyrax service using the Hyrax Administrators Interface to add a new data set to the catalog.
This page is the starting point for organizing the design work for the Hyrax Administrators Interface (HAI).
Definitions
- Administrator
- The administrator is the human that operates the HAI.
- User
- The user is a human that uses client software such as Kepler, Matlab OPeNDAP Ocean Toolbox, a web browser, and others to make requests (HTTP, SOAP, etc.) of the Hyrax server.
- Operator Console
- The 24x7 operator's console to monitor and control the data services as well as the user data requests, and receive service notifications.
- Administrator Console
- The system administrator's console to monitor, control, reconfigure, and debug the Hyrax frontend and backend servers, and receive service notifications.
Use Cases
Basic Features
The administrator uses the HAI to:
- Administrator Logs into the Hyrax Admin Interface
- Control BES connections
Examine BES processes/connectionsI removed this because I think it's going to require two levels of modifications on the BES and because I don't think it's nearly as useful as the next use case. jhrg- Terminate specific BES processes/connections
- Hyrax OLFS and BES logging service
Advanced Features
I think that these features - which are the Authentication and Authorization features (Ac/Az) - should be kept very simple because of the likelihood that the underlying mechanism for providing the credentials is almost certain to change and become a set of mechanisms. Thus we will want something that can be used with a variety of ac/az approaches. Later we can add things like quotas, priorities. I also think that we need to base all of this on roles and URLs. jhrg
- Hyrax user authentication and authorization service
- View/set roles and their mapping to URLs - this is the basis for categorizing authorization.
- View/set user
dataauthorization, attributes, thresholds, and priorityI think this should be done at the URL level - we authorize users to access specific sets of URLs. I thin the distinction between service and data is only making more work at this stage. At some point we will likely want to classify services as expensive and so on, but that's just too much to bite off for now. jhrg - Control service access, user authentication and data authorization
Other Features That Would Be Nice But Need Funding
- Hyrax OLFS and BES's data access service
- View list of OLFS and BES's services
- View service's data requests, request status, and statistics
- Control (e.g. Start/stop) OLFS and BES's data access services
- Notification of OLFS and BES service status
- Notification of OLFS and BES service status when thresholds are exceeded
- Notification of OLFS and BES heartbeat signal (e.g. traffic lights)
- View/set OLFS service configuration settings
- View/set BES service configuration setting
- Modify service notification features and thresholds.
- Hyrax data catalog service
- View data catalog and statistics
- Control data catalog service
- Send copy of data catalog and output level of attribute information
- View/set OLFS and BES data catalog service settings
- User Managment
View user service access history and data requestsI think this will require too much information be retained about users and their past actions. You could implement this with log analysis, but given that the logs' content can be changed and the logs are logs and thus likely not complete (truncated, rotated, etc.) I think it's just too much to bite off now. jhrgManage user access rights to dataManage user and service access rights, quotas, thresholds, and prioritiesI think these two are really being covered by 2-4.
- Debugging Tools
Compare Server output with debugging associated with the requestI think to be really useful this will have to be very involved - we'll need to compare lots of different kinds of outputs and many of them will need some kind of 'filter' (eg binary to ascii). jhrgView/set OLFS and BES's log settingsI think this is essentially redundant functionality - the first three have this covered. jhrg
Design
Required features
- Secure (SSL, grid certificates?) login and sessions.
- Data request and transaction log viewing.
- control and view debugging information.
- control and view service settings.
- control and view data catalog settings
- control and view service statistics information
- control and view service state information
Desired features
- control and view user access management
- control and view service notification features and thresholds
Deliverables
Period of use
The API features are to be permanent features in the Hyrax data service for use in building administrator and operator console applications to support an operational data service. The operational Hyrax data service is to support various service level access (SLA) requirements and provide timely, reliable data delivery with transaction logging.