Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Open-Measured-Data-Management-WG/UserAuthenticationAndRights"

Line 1: Line 1:
TODO
+
== Short Description ==
  
* Describe Goal (etc)
+
The openMDM Eclipse Working Group recognizes the need to provide user authentication and user authorization as part of the openMDM 5 framework and solicits proposals for the design and implementation of suitable mechanisms to perform these functions. Specifically, the following questions are to be addressed:
* Upload Workshop results [https://openmdm.atlassian.net/browse/ORGA-98 Orga-98] and [https://openmdm.atlassian.net/browse/ORGA-158 Orga-158]
+
 
* Project Plan
+
* Which notion of user identity is used by openMDM?
** Interviews with OEMs planned
+
* How is the identity of a user authenticated during login?
* Concept (Result)
+
* How is the identity of the current user passed between different openMDM components and between openMDM components and underlying data sources (e.g., ODS servers)?
 +
* How are roles and user-role assignments managed?
 +
* How are access rights defined and managed?
 +
* Which component(s) are responsible for enforcing access control and which mechanisms are used for the enforcement?
 +
* How should openMDM components and applications react to authorization failures?
 +
An initial workshop on user authentication and authorization in openMDM was held in April 2016 and resulted in a set of observations, requirements and suggestions documented under [https://openmdm.atlassian.net/browse/ORGA-98 ORGA-98] and [https://openmdm.atlassian.net/browse/ORGA-158 Orga-158]. Based on the results of this workshop, the openMDM Eclipse Working Group now looks for a specific design and (after acceptance of the design by the Working Group) an implementation of user authentication and authorization within the openMDM framework.
 +
 
 +
== Project Steps ==
 +
 
 +
* Kick-off meeting held (2.11.2016): Summary:  TODO: upload
 +
* Interviews planned with OEMS
 +
** Interview partners defined: BMW (Michael Schwarzbach), Audi (Franz Wöhrl/Sven Wittig), Daimler (??)
 +
* Consolidated interview results:
 +
* 1. Delivery: Concept
 +
* 2. Delivery: Example Implementation

Revision as of 06:27, 11 January 2017

Short Description

The openMDM Eclipse Working Group recognizes the need to provide user authentication and user authorization as part of the openMDM 5 framework and solicits proposals for the design and implementation of suitable mechanisms to perform these functions. Specifically, the following questions are to be addressed:

  • Which notion of user identity is used by openMDM?
  • How is the identity of a user authenticated during login?
  • How is the identity of the current user passed between different openMDM components and between openMDM components and underlying data sources (e.g., ODS servers)?
  • How are roles and user-role assignments managed?
  • How are access rights defined and managed?
  • Which component(s) are responsible for enforcing access control and which mechanisms are used for the enforcement?
  • How should openMDM components and applications react to authorization failures?

An initial workshop on user authentication and authorization in openMDM was held in April 2016 and resulted in a set of observations, requirements and suggestions documented under ORGA-98 and Orga-158. Based on the results of this workshop, the openMDM Eclipse Working Group now looks for a specific design and (after acceptance of the design by the Working Group) an implementation of user authentication and authorization within the openMDM framework.

Project Steps

  • Kick-off meeting held (2.11.2016): Summary: TODO: upload
  • Interviews planned with OEMS
    • Interview partners defined: BMW (Michael Schwarzbach), Audi (Franz Wöhrl/Sven Wittig), Daimler (??)
  • Consolidated interview results:
  • 1. Delivery: Concept
  • 2. Delivery: Example Implementation

Back to the top