Open-Measured-Data-Management-WG/UserAuthenticationAndRights/Minutes Kickoff Meeting

Minutes of Kickoff Meeting 2.11.2016

== Participants:

• Stefan Wartini
• Gert Sablon
• Gerd Hillebrand
• Hendrik Ebbers

Authentication

Requirements

The requirement list given in Section 3.1 (Objectives - User Authentication) of the Offer was confirmed, except for the last requirement that for each openMDM object, its creator needs to be stored along with the object. This would require the introduction of a new relationship "creator" from any openMDM entity type to the "User" entity type, and hence a model change. Instead, we will investigate during the design phase whether the existing relationship "responsiblePerson" between the "Test" and "User" entity types suffices. Using this relationship, ownership can be expressed at the test level and could conceivably be inherited by the object hierarchy underneath a Test instance.

Solution approach

The solution approach proposed in Section 4.1 (Solution - User Authentication) of the Offer, namely to delegate authentication to the application container, relying on the standard authentication modules supplied along with each major application container, was accepted. During the design phase, we will check which application containers and authentication mechanisms are currently in use or planned to be used by each OEM and whether suitable authentication modules exist to cover each case. If the analysis shows that there is a need to support authentication by delegation to the ODS server (so that the ODS server checks the supplied username and password), we will implement a corresponding custom authentication module that can be plugged into an application container.

Retrieval of identity and role information shall happen via the standard JEE APIs (such as HttpServletRequest.getRemoteUser(), HttpServletRequest.isUserInRole() or EJBContext.getCallerPrincipal()), unless the upcoming OEM interviews (and a corresponding decision by the openMDM Architecture Committee) demonstrate that openMDM 5 must support platforms other than JEE. In this case, a wrapper API will be defined so that openMDM components can obtain the user identity and user roles in a platform-neutral way.

Authorization

Requirements

The requirement list given in Section 3.2 (Objectives - User Authorization) of the Offer was confirmed, subject to the following amendments and clarifications:

• It must be possible to define at the individual test level which roles are permitted to access that test (and all objects below it). This is an extension of the role-to-pool mapping described in the table on pages 2 and 3 of the Request for Quotation, which only foresees an assignment of users to roles at the data pool level, but no variation of access rights within a data pool.

• Access rights should _only_ be assigned to roles. The phrase "In exceptional cases, access rights may be assigned to individual users" should be removed from the requirements unless an OEM insists that assignment to individual users be possible.

• The kickoff participants acknowledge that role scoping, i.e., the limitation of a role assignment to a particular data pool, typically requires the creation of a separate physical LDAP role for each combination of "logical role" and data pool.

• The requirement regarding selection of a view role during login will probably have to be abandoned for the time being, because this is not supported by ODS servers.

• Dynamic assignment of roles during the data processing workflow will not be implemented initially.

• Specific requirements regarding protection against accidental or malicious object deletion (such as a mandatory approval by the object's creator) are to be obtained from OEMs (particularly BMW) during the design phase.

• The term data pool used in the Request for Quotations and the Offer is not to be treated as a synonym for the Pool entity defined in the openMDM API. A data pool is a logical data container that may span multiple data servers, whereas the Pool entity is a specific application element in the ODS sense whose instances must of necessity be confined to a single ODS server each. The openMDM Architecture committee will look into this terminological discrepancy and will decide whether the Pool entity will be redefined to cover the notion of data pool or whether data pools will be represented by new, distinct object type.

Solution approach

Of the three possible solution approaches proposed in Section 4.2 (Solution - User Authorization) of the Offer, approach #2 (API within openMDM, implementation delegated to data servers) is to be pursued. Compared to approach #3, which was suggested in the Offer, this means that an openMDM-specific API for the interrogation and manipulation of roles and access rights needs to be defined and that each data server adapter needs to map the operations defined in the common API to corresponding operations on the underlying data server. The design of the common openMDM Roles and Rights API should be guided by the ODS security model, but with the following simplifications:

• ACLs can only be defined at the instance level (i.e., no ACLs at the application element or application attribute/relation level) and moreover only for instances of type "data pool", Project, Test, Test Step or Measurement.

• ACL entries need not contain specific actions, because the permitted actions are implied by the role (user group) to which the ACL entry pertains and do not depend on the specific application instance to which the ACL entry is attached.

• ACL inheritance and templating can probably be simplified as well, but OEM requirements regarding this functionality must be clarified during the design phase.

In addition to the ODS security model, there needs to be a mechanism to define the set of actions permitted for each role. These sets are defined globally at the installation level and do not vary between data pools or finer entities. At a minimum, the five basic actions defined by the ODS security model (Insert, Read, Update, Delete, and Grant) must be supported; but ideally installation-specific actions should be supported as well.

The new API must be mappable to the ODS security model. In addition, the mappability to anticipated future openMDM backends should be investigated.

Next Steps

Stefan Wartini and Gert Sablon will approach Audi, BMW and Daimler regarding suitable contacts for OEM interviews. The interview contacts need to be able to provide details on:

• the authentication mechanisms, user identity and role management systems in use (or anticipated) at the respective OEM
• the application servers in use and their configuration regarding authentication and enterprise directory access
• relevant in-house standards and guidelines regarding authentication and authorization
• current setup of ODS servers with respect to authentication and authorization
• existing or anticipated communication protocols between openMDM components/applications
• any requirements pertaining to openMDM roles and rights management not yet mentioned in the Offer or in this document