Re: [hono-dev] [PROPOSAL] Extend Hono with Credential Management API

["Hudalla Kai (INST/ESY1)" <Kai.Hudalla@xxxxxxxxxxxx>]

Thanks for your support with this, guys :-)

I think the easiest way to get this going would be for me to create an initial
version of the API description using the Registration API description as a "blue
print". I can create a PR for it or put it on the Wiki so that we can review it
and improve it together.

-- 
Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com

Registered office: Berlin, Register court: Amtsgericht Charlottenburg,
HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn

On Thu, 2017-02-16 at 10:07 +0000, Paolo Patierno wrote:
> Hi Kai,
> 
> even on my side I think it's a good idea mostly if Vault can help us to be
> generic for supporting different types of credentials. I want to invest
> few time on Vault to verify its capabilities.
> In general we can start to design the credentials API. 
> 
> I'm with you and Dejan ;)
> 
> Paolo Patierno
> Senior Software Engineer (IoT) @ Red Hat
> Microsoft MVP on Windows Embedded & IoT
> Microsoft Azure Advisor 
> 
> Twitter : @ppatierno
> Linkedin : paolopatierno
> Blog : DevExperience
> 
> 
> From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> on behalf of
> Dejan Bosanac <dejanb@xxxxxxxxxxxx>
> Sent: Thursday, February 16, 2017 9:50 AM
> To: hono developer discussions
> Subject: Re: [hono-dev] [PROPOSAL] Extend Hono with Credential Management API
>  
> Hi Kai,
> 
> it sounds good to me and in line what we discussed at the last meeting at
> EclipseCon. Also, as we agreed then, this is one of the integration points with
> Kapua (and other systems), so it’d be good to keep the API general, so it’s
> easy to integrate. Please let me know how I can help with this effort.
> 
> On Wed, Feb 15, 2017 at 3:07 PM, Hudalla Kai (INST/ESY1) <Kai.Hudalla@bosch-si.
> com> wrote:
> > Hi list,
> > 
> > I have been thinking about device registration and the way it should/could
> > provide useful functionality helping protocol adapters with authenticating
> > devices.
> > 
> > IMHO one of the main issues that protocol adapter implementors face will be
> > the
> > secure persistence and management of the device's credentials. Depending on
> > the
> > mechanism used for authenticating the device these might be a username and
> > (hashed) password, a pre-shared key or an API key. In any case, I think it
> > would
> > be great if Hono could offer a standard way of managing these credentials for
> > the
> > protocol adapters so that they do not need to re-invent the wheel for that
> > purpose all of the time.
> > 
> > We have taken a first step in that direction by extending the registration
> > API
> > with the capability to register additional information for a device identity
> > by
> > means of specifying arbitrary key/value pairs when registering or updating a
> > device [1].
> > 
> > I would now like to propose taking this one step further by introducing a
> > dedicated API endpoint ("Credentials API") for managing devices' credentials
> > in
> > addition to the existing Registration API. IMHO this would provide for better
> > separation of concerns and would also make it easier to evolve both APIs
> > independently from another. The registration API would still be used for
> > registering the "logical" device ID and managing basic (non-confidential)
> > properties of the device, e.g. if the device is enabled. The Credentials API
> > would specifically serve the purpose of registering and finding credentials
> > for
> > authenticating a device based on the type of credentials and subject ID used
> > by
> > these credentials. As an example consider a device registered with (logical)
> > ID
> > "device-15" which connects to Hono using MQTT providing a username and
> > password
> > in its CONNECT frame. The MQTT protocol adapter can then use Credentials API
> > to
> > lookup the corresponding (hashed) password and (logical) device ID. Once the
> > password provided by the device has been verified, the protocol adapter can
> > forward the telemetry data provided by the device to Hono's Telemetry API
> > using
> > the logical device ID.
> > 
> > Separating the two APIs also would make it easier to implement persistence in
> > a
> > way sufficiently secure for the two APIs' specific purpose. In particular,
> > this
> > would allow us to e.g. persist standard properties in a simple DB whereas the
> > credentials would be kept in a more specialized component like e.g. Vault
> > [2],
> > providing for added security by means of encryption, auditing, key rotation
> > etc.
> > 
> > WDYT? Does this make sense to you guys? Do you think this would be a
> > worthwhile
> > addition to Hono? Any kind of input would be highly appreciated :-)
> > 
> > If some support for this idea emerges here, I would like to start to work on
> > a
> > proposal for the Credential API and a prototypical implementation based on
> > Vault.
> > 
> > [1] https://www.eclipse.org/hono/api/Device-Registration-API/
> > [2] https://www.vaultproject.io
> > 
> > --
> > Mit freundlichen Grüßen / Best regards
> > 
> > Kai Hudalla
> > Chief Software Architect
> > 
> > Bosch Software Innovations GmbH
> > Schöneberger Ufer 89-91
> > 10785 Berlin
> > GERMANY
> > www.bosch-si.com
> > 
> > Registered office: Berlin, Register court: Amtsgericht Charlottenburg,
> > HRB 148411 B;
> > Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
> > _______________________________________________
> > hono-dev mailing list
> > hono-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or unsubscribe from
> > this list, visit
> > https://dev.eclipse.org/mailman/listinfo/hono-dev
> > 
> 
> 
> 
> _______________________________________________
> hono-dev mailing list
> hono-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/hono-dev