Date   
Re: [Edgex-tsc-core] RPi -> 64-bit OS

Brad Kemp
 

If 32 bit is a problem, gentoo has a 64 bit distribution. You also can build a 64 bit from yocto.
Brad

Brad Kemp
brad@...
123 North Washington St, 3rd Floor, Boston. MA 02114
(o) 617-963-8104
(c) 617-291-9233
(f) 617-742-0242

On Jan 17, 2018, at 8:46 AM, Drasko DRASKOVIC <drasko@...> wrote:

Hi all,
one thing to keep in mind is that official flavor od Debain that runs
on RPi, called Raspbian, is 32 bit. This might be problematic for some
apps, and in particular Docker (although this should be enabled via
Hypriot project:
https://www.raspberrypi.org/blog/docker-comes-to-raspberry-pi/).

This is something to keep in mind.

Tony,
does Ubuntu Core support RPi in 64-bit mode
(https://developer.ubuntu.com/core/get-started)?

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

_______________________________________________
EdgeX-TSC-Core mailing list
EdgeX-TSC-Core@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-core

Re: RPi -> 64-bit OS

espy
 

On 01/17/2018 11:46 AM, Drasko DRASKOVIC wrote:
Hi all,
one thing to keep in mind is that official flavor od Debain that runs
on RPi, called Raspbian, is 32 bit. This might be problematic for some
apps, and in particular Docker (although this should be enabled via
Hypriot project:
https://www.raspberrypi.org/blog/docker-comes-to-raspberry-pi/).
This is something to keep in mind.
Tony,
does Ubuntu Core support RPi in 64-bit mode
(https://developer.ubuntu.com/core/get-started)?
Yes, we have std Ubuntu Core images for rpi3. There are no std classic Ubuntu Server images for rpi3. We only have 32-bit server images for rpi2.

/t


Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor
www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France
LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Re: [Edgex-tsc-core] RPi -> 64-bit OS

espy
 

On 01/17/2018 11:53 AM, Brad Kemp wrote:
If 32 bit is a problem, gentoo has a 64 bit distribution. You also can build a 64 bit from yocto.
FYI, according to Jim, there is a 64-bit version of Raspbian, however one of my co-workers has mentioned that the Pi foundation doesn't recommend running 64-bit on the Pis, due to memory starvation and the fact that you'll quickly run into OOM problems. From what I've been told, running 64-bit on anything with less than 4GB of RAM isn't advised.

Regards,
/tony

Brad
Brad Kemp
brad@...
123 North Washington St, 3rd Floor, Boston. MA 02114
(o) 617-963-8104
(c) 617-291-9233
(f) 617-742-0242

On Jan 17, 2018, at 8:46 AM, Drasko DRASKOVIC <drasko@...> wrote:

Hi all,
one thing to keep in mind is that official flavor od Debain that runs
on RPi, called Raspbian, is 32 bit. This might be problematic for some
apps, and in particular Docker (although this should be enabled via
Hypriot project:
https://www.raspberrypi.org/blog/docker-comes-to-raspberry-pi/).

This is something to keep in mind.

Tony,
does Ubuntu Core support RPi in 64-bit mode
(https://developer.ubuntu.com/core/get-started)?

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

_______________________________________________
EdgeX-TSC-Core mailing list
EdgeX-TSC-Core@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-core

Re: [Edgex-tsc-core] RPi -> 64-bit OS

Bryan Gartner
 

FYI,

SUSE has an aarch64 image for RPi3 -
https://www.suse.com/products/arm/raspberry-pi/ (I've been running one
of mine this way for more than a year now).

Llikewise you can find openSUSE 64bit variants as well -
https://en.opensuse.org/HCL:Raspberry_Pi3

On Wed, Jan 17, 2018 at 9:46 AM, Drasko DRASKOVIC <drasko@...> wrote:
Hi all,
one thing to keep in mind is that official flavor od Debain that runs
on RPi, called Raspbian, is 32 bit. This might be problematic for some
apps, and in particular Docker (although this should be enabled via
Hypriot project:
https://www.raspberrypi.org/blog/docker-comes-to-raspberry-pi/).

This is something to keep in mind.

Tony,
does Ubuntu Core support RPi in 64-bit mode
(https://developer.ubuntu.com/core/get-started)?

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

_______________________________________________
EdgeX-TSC-Core mailing list
EdgeX-TSC-Core@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-core

Re: [Edgex-golang] [Edgex-tsc] Auth Service

Smith, Nick A <nick.a.smith@...>
 

Hi,

 

My 2 cents. Whilst in totality specifications like OAuth2 are complex it is perfectly possible and sensible from a security perspective to use subsets of their functionality. To that end whilst JWTs are far from perfect they have at least been studied to ascertain their attack surface and they have widespread support. Securing JWTs can be achieved by reducing the scope of their configuration i.e. disallowing insecure algorithms (RSA PKCS1.5, None) and making some of the optional headers mandatory (key ID etc).

 

I’d encourage the use of something like OpenID Connect Code Flow for authenticating humans whilst going for something simple for services like an OAuth2 Client Credentials Grant. Both result in the authenticating entity receiving a token that can be used in authorization later on, both have widespread adoption, both have had at least some security analysis and are relatively simple to integrate. Additionally the use of existing protocols enables existing identity federation services to be re-used. Creating more identity and credential repositories is more likely to reduce security than to help it.

 

None of this takes away from Drasko’s work as it’s possible to use his API in both an OAuth2 and OpenID Connect context (as identity verification is open to implementation; it could be via a shared key, username/password or some sort of 2FA) but those standards do enable better integration into existing infrastructures.

 

Nick

 

From: edgex-golang-bounces@... [mailto:edgex-golang-bounces@...] On Behalf Of Vlado Handziski
Sent: 17 January 2018 15:26
To: Domenico Rotondi
Cc: Drasko DRASKOVIC; edgex-tsc-core@...; edgex-golang@...; manuel@...; edgex-tsc-security@...; edgex-tsc@...; Nikola Marcetic; Dejan Mijic; edgex-devel@...; Leonardo Straniero; Diego Pedone
Subject: Re: [Edgex-golang] [Edgex-tsc] [Edgex-tsc-security] Auth Service

 

Hi all,

 

I also think that this approach of using JWT as short-term, single-use authorization tokens has benefits vs. using JWT as a pseudo session mechanism. I am not a security expert, but there seems to be a lot of general debate in the community over the usability of JWT in this context, i.e.:

 

 

I definitely see value in having a lightweight AAA, as proposed by Drasko, so one option to reduce the attack / error surface would be to use something like PAST instead: https://github.com/ericchiang/go-past

 

--Vlado

 

 

 

On Wed, 17 Jan 2018 at 16:02 Domenico Rotondi <domenico.rotondi@...> wrote:

On 17 Jan 2018 at 6:53, Drasko DRASKOVIC wrote:
Hi all,
if of interest, in FINCONS SpA, we have developed, in the context of EU R&D
projects, a set of libraries (JavaScript and Java) and backend to manage login and
AuthZ using JWT tokens and other security features to increase the overall system
reliability. Everything is provided with the Apache V2 license.

From an architectural point of view our scenario envisages clients, an Authorization
Service and one or more "operational services" (in our case for example a document
store and a policy store).
As in token based systems, any request to any service has to include an explicit
authorization token that must be requested to the Authorization Service before
submitting the service request (this is managed internally by our libraries). Therefore,
on the service side there is no need to check user ID, access rights, etc.; the only
check is related to the correctness of the presented token.

Of course, the client needs initially to authenticate itself, but, in order to avoid having
to manage sensitive info like password on the backend, we actually use a
proof-of-ownership of the presented identity.
If the proof is successful then the client and the Authorization Service create a shared
secret which is used afterwards to manage token's requests from the client to the
Authorization Service.

If of interest we'll be happy to provide the SW. Of course no problem in providing
further details.
Ciao
   Domenico

Hi all,
I started writing a small Auth service that would live behind the
proxy and have 3 goals:
1) To create (register) a user (i.e. create a user account in MongoDB)
2) Login user (i.e. issue JWT token upon correct username + password)
3) Expose /auth API call so that all other API calls to other services
can be first redirected first to this service for Auth check

Basically - whole API of the service is here:
https://github.com/drasko/edgex-auth/blob/master/auth/server.go#L21-L27

This service would solve gateway protection on production level
(encrypted user credentials are kept in MongoDB, can be also written
in Vault in later versions), and I guess that first version can be
finished in a couple of days.

Would something like this be of interest?

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com   |  Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division |   Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

_______________________________________________
EdgeX-TSC-Security mailing list
EdgeX-TSC-Security@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-security
----------------------------------------------------------------------
PERSONALE E CONFIDENZIALE
Questa mail potrebbe includere materiale confidenziale, proprietario o
altrimenti privato per l'uso esclusivo del destinatario.
Se l'avete ricevuto per errore, siete pregati di contattare chi ha inviato il
messaggio e di cancellarne tutte le copie.
Ogni altro uso da parte vostra del messaggio è proibito.
Se non ti è necessario, non stampare questo documento. Grazie

PERSONAL AND CONFIDENTIAL
This message is for the designated recipient only and may contain privileged,
proprietary, or otherwise private information. If you have received it in error,
please notify the sender immediately and delete all the copies.
Any other use of the email by you is prohibited.
Please consider the environment before printing this email


---
This email has been checked for viruses by AVG.
http://www.avg.com

_______________________________________________
EdgeX-TSC mailing list
EdgeX-TSC@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc

Reverse proxy footprint

Dellabianca, Alberto
 

Hi all,

 

I would like to share some comments related to the ongoing discussion about the footprint of some proposed Reverse Proxy. I saw on slide #9 form the last meeting that “Size of proposed containers are large”.

Please look at the below.

 

 

EdgeX Mongo is 20x times bigger than nginx.

The container size of both options does not look bad unless for some reason we cannot use the alpine version.

 

I’d like to know your thoughts about this.

 

Thanks

Alberto

New Device Services & SDK Requirements document (v4)

espy
 

-------- Forwarded Message --------
Subject: New Device Services & SDK Requirements document (v4)
Date: Wed, 14 Feb 2018 20:48:50 -0500
From: espy <espy@...>
To: edgex-devel@... <edgex-devel@...>, edgex-tsc-device-services@..., edgex-tsc-core@...

Attached please find the latest Device Services & SDK Requirements document (v4) for the California release of EdgeX Foundry.

Please note, there are few open issues noted in the document, but we decided that getting this out to the community as early as possible was important.

Please review and send my comments my way.

Regards,
/tony

Authentication Specification uploaded to google docs

David Ferriera
 

Hi All,


   I added some information and cleaned up some wording.  Google docs conversion had some hiccups, but should be okay now for the most part.  

   I opened the comments pane.  Feel free to add comments.

   Here is the direct link to the document.

Thanks,
-David

--
David Ferriera | Forgerock
Senior Director, Cloud Technology | Office of the CTO
t +1 408.454.8189 | w forgerock.com

Re: Authentication Specification uploaded to google docs

White2, James
 

Dell - Internal Use - Confidential

Thanks for this David.  Good work on this effort!

 

From: edgex-tsc-security-bounces@... [mailto:edgex-tsc-security-bounces@...] On Behalf Of David Ferriera
Sent: Thursday, February 22, 2018 8:18 PM
To: edgex-tsc-security@...
Subject: [Edgex-tsc-security] Authentication Specification uploaded to google docs

 

Hi All,

 

 

   I added some information and cleaned up some wording.  Google docs conversion had some hiccups, but should be okay now for the most part.  

 

   I opened the comments pane.  Feel free to add comments.

 

   Here is the direct link to the document.

 

Thanks,

-David

 

--

David Ferriera | Forgerock

Senior Director, Cloud Technology | Office of the CTO

t +1 408.454.8189 | w forgerock.com

Re: Authentication Specification uploaded to google docs

David Ferriera
 



Can we make sure everybody has access?  I have received quite a few "request for access" emails. 

On Thu, Feb 22, 2018 at 9:28 PM, <James.White2@...> wrote:

Dell - Internal Use - Confidential

Thanks for this David.  Good work on this effort!

 

From: edgex-tsc-security-bounces@lists.edgexfoundry.org [mailto:edgex-tsc-security-bounces@...] On Behalf Of David Ferriera
Sent: Thursday, February 22, 2018 8:18 PM
To: edgex-tsc-security@lists.edgexfoundry.org
Subject: [Edgex-tsc-security] Authentication Specification uploaded to google docs

 

Hi All,

 

 

   I added some information and cleaned up some wording.  Google docs conversion had some hiccups, but should be okay now for the most part.  

 

   I opened the comments pane.  Feel free to add comments.

 

   Here is the direct link to the document.

 

Thanks,

-David

 

--

David Ferriera | Forgerock

Senior Director, Cloud Technology | Office of the CTO




--
David Ferriera | Forgerock
Senior Director, Cloud Technology | Office of the CTO
t +1 408.454.8189 | w forgerock.com

New Device Services & SDK Requirements document (v5)

espy
 

Attached please find the latest Device Services & SDK Requirements document (v5) for the California release of EdgeX Foundry.

Thanks for those of you that provided feedback on the previous version!

The following areas of the document have been clarified or updated:

* Query commands:
- mention that readings are triggered whenever a successful query command is processed
- clarify which Query GET handlers are required

* Data transformation - new section

* Actuation commands - clarified how command arguments are passed

* operatingState - clarified how device operatingStates are handled

* Security - new section

* Appendix A - Settings: minor cleanup

There still is some remaining work to flesh out the logging, scheduling, and metadata updates sections.

Please review and send my comments my way.

Regards,
/tony

Re: New Device Services & SDK Requirements document (v5)

Drasko DRASKOVIC
 

Hi Tony,
in your doc I can see that query commands sometime return strings:
{"AnalogValue_40":"183.92999267578125"}

This is simple, and of course make sense, just that ints, floats and
bools are all represented by strings and I guess that make messages
longer. It's not an issue now, but in the future, we might think about
constrained and battery-powered devices which send messages over
LPWAN, potentially aggregate several sensor readings and then send
them all at once (this is typical mode of operation).

IETF is trying to define semantics for sensor network JSON and CBOR
mesages through SenML standard:
https://tools.ietf.org/html/draft-ietf-core-senml-13

SenML is describing the type of the value, and can shorten the
aggregated messages. I think it is worth looking at.

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

On Tue, Mar 6, 2018 at 2:01 AM, espy <espy@...> wrote:
Attached please find the latest Device Services & SDK Requirements document
(v5) for the California release of EdgeX Foundry.

Thanks for those of you that provided feedback on the previous version!

The following areas of the document have been clarified or updated:

* Query commands:
- mention that readings are triggered whenever a successful query command
is processed
- clarify which Query GET handlers are required

* Data transformation - new section

* Actuation commands - clarified how command arguments are passed

* operatingState - clarified how device operatingStates are handled

* Security - new section

* Appendix A - Settings: minor cleanup

There still is some remaining work to flesh out the logging, scheduling, and
metadata updates sections.

Please review and send my comments my way.

Regards,
/tony

_______________________________________________
EdgeX-TSC-Security mailing list
EdgeX-TSC-Security@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-security

Re: New Device Services & SDK Requirements document (v5)

Steve Osselton
 

Hi Drasco,

Agree that this is the sort of representation that we should be looking at using.

Cheers Steve

On 6 March 2018 at 11:17, Drasko DRASKOVIC <drasko@...> wrote:
Hi Tony,
in your doc I can see that query commands sometime return strings:
{"AnalogValue_40":"183.92999267578125"}

This is simple, and of course make sense, just that ints, floats and
bools are all represented by strings and I guess that make messages
longer. It's not an issue now, but in the future, we might think about
constrained and battery-powered devices which send messages over
LPWAN, potentially aggregate several sensor readings and then send
them all at once (this is typical mode of operation).

IETF is trying to define semantics for sensor network JSON and CBOR
mesages through SenML standard:
https://tools.ietf.org/html/draft-ietf-core-senml-13

SenML is describing the type of the value, and can shorten the
aggregated messages. I think it is worth looking at.

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com   |  Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division |   Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

On Tue, Mar 6, 2018 at 2:01 AM, espy <espy@...> wrote:
> Attached please find the latest Device Services & SDK Requirements document
> (v5) for the California release of EdgeX Foundry.
>
> Thanks for those of you that provided feedback on the previous version!
>
> The following areas of the document have been clarified or updated:
>
>  * Query commands:
>    - mention that readings are triggered whenever a successful query command
> is processed
>    - clarify which Query GET handlers are required
>
>  * Data transformation - new section
>
>  * Actuation commands - clarified how command arguments are passed
>
>  * operatingState - clarified how device operatingStates are handled
>
>  * Security - new section
>
>  * Appendix A - Settings: minor cleanup
>
> There still is some remaining work to flesh out the logging, scheduling, and
> metadata updates sections.
>
> Please review and send my comments my way.
>
> Regards,
> /tony
>
> _______________________________________________
> EdgeX-TSC-Security mailing list
> EdgeX-TSC-Security@lists.edgexfoundry.org
> https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-security
>

_______________________________________________
EdgeX-TSC-Security mailing list
EdgeX-TSC-Security@lists.edgexfoundry.org
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-security



--
Technical Director
IOTech Systems Ltd.

Re: [EXTERNAL] Re: New Device Services & SDK Requirements document (v5)

Dellabianca, Alberto
 

+1

 

 

 

From: edgex-tsc-security-bounces@... [mailto:edgex-tsc-security-bounces@...] On Behalf Of Steve Osselton
Sent: Tuesday, March 6, 2018 6:03 AM
To: Drasko DRASKOVIC <drasko@...>
Cc: edgex-devel@...; edgex-tsc-core@...; edgex-tsc-device-services@...; edgex-tsc-security@...
Subject: [EXTERNAL] Re: [Edgex-tsc-security] New Device Services & SDK Requirements document (v5)

 

Hi Drasco,

 

Agree that this is the sort of representation that we should be looking at using.

 

Cheers Steve

 

On 6 March 2018 at 11:17, Drasko DRASKOVIC <drasko@...> wrote:

Hi Tony,
in your doc I can see that query commands sometime return strings:
{"AnalogValue_40":"183.92999267578125"}

This is simple, and of course make sense, just that ints, floats and
bools are all represented by strings and I guess that make messages
longer. It's not an issue now, but in the future, we might think about
constrained and battery-powered devices which send messages over
LPWAN, potentially aggregate several sensor readings and then send
them all at once (this is typical mode of operation).

IETF is trying to define semantics for sensor network JSON and CBOR
mesages through SenML standard:
https://tools.ietf.org/html/draft-ietf-core-senml-13

SenML is describing the type of the value, and can shorten the
aggregated messages. I think it is worth looking at.

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com   |  Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division |   Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

On Tue, Mar 6, 2018 at 2:01 AM, espy <espy@...> wrote:
> Attached please find the latest Device Services & SDK Requirements document
> (v5) for the California release of EdgeX Foundry.
>
> Thanks for those of you that provided feedback on the previous version!
>
> The following areas of the document have been clarified or updated:
>
>  * Query commands:
>    - mention that readings are triggered whenever a successful query command
> is processed
>    - clarify which Query GET handlers are required
>
>  * Data transformation - new section
>
>  * Actuation commands - clarified how command arguments are passed
>
>  * operatingState - clarified how device operatingStates are handled
>
>  * Security - new section
>
>  * Appendix A - Settings: minor cleanup
>
> There still is some remaining work to flesh out the logging, scheduling, and
> metadata updates sections.
>
> Please review and send my comments my way.
>
> Regards,
> /tony
>
> _______________________________________________
> EdgeX-TSC-Security mailing list
> EdgeX-TSC-Security@...
> https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-security
>

_______________________________________________
EdgeX-TSC-Security mailing list
EdgeX-TSC-Security@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-security



 

--

Technical Director

IOTech Systems Ltd.

Re: New Device Services & SDK Requirements document (v5)

espy
 

On 03/06/2018 06:17 AM, Drasko DRASKOVIC wrote:
Hi Tony,
in your doc I can see that query commands sometime return strings:
{"AnalogValue_40":"183.92999267578125"}
Yes, that's correct.

This is simple, and of course make sense, just that ints, floats and
bools are all represented by strings and I guess that make messages
longer. It's not an issue now, but in the future, we might think about
constrained and battery-powered devices which send messages over
LPWAN, potentially aggregate several sensor readings and then send
them all at once (this is typical mode of operation).
IETF is trying to define semantics for sensor network JSON and CBOR
mesages through SenML standard:
https://tools.ietf.org/html/draft-ietf-core-senml-13
SenML is describing the type of the value, and can shorten the
aggregated messages. I think it is worth looking at.
Thanks for the suggestion! It looks like this is still a draft, so we should keep any eye on it as it progresses.

Some observations:

- the readings embed the device name, making it possible to combine readings from different devices in the same result array. EdgeX currently adds the device name to the event, which contains readings.

- the format allows custom attributes to be defined, which would allow us to add EdgeX specific attributes

- I don't think there's a big difference in size between our current messages and the JSON SenML format, in fact the latter messages might even be a bit larger than our current messages. That said, on constrained devices using CBOR would be an advantage.

Implementing this would require pretty invasive re-work across all of our services, so this is something we should put on our post-California architecture list.

Regards,
/tony



Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor
www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France
LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic
On Tue, Mar 6, 2018 at 2:01 AM, espy <espy@...> wrote:
Attached please find the latest Device Services & SDK Requirements document
(v5) for the California release of EdgeX Foundry.

Thanks for those of you that provided feedback on the previous version!

The following areas of the document have been clarified or updated:

* Query commands:
- mention that readings are triggered whenever a successful query command
is processed
- clarify which Query GET handlers are required

* Data transformation - new section

* Actuation commands - clarified how command arguments are passed

* operatingState - clarified how device operatingStates are handled

* Security - new section

* Appendix A - Settings: minor cleanup

There still is some remaining work to flesh out the logging, scheduling, and
metadata updates sections.

Please review and send my comments my way.

Regards,
/tony

_______________________________________________
EdgeX-TSC-Security mailing list
EdgeX-TSC-Security@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc-security

Re: New Device Services & SDK Requirements document (v5)

Drasko DRASKOVIC
 

On Tue, Mar 6, 2018 at 7:19 PM, espy <espy@...> wrote:

Thanks for the suggestion! It looks like this is still a draft, so we
should keep any eye on it as it progresses.
Yes, it's still a draft, but it's 13th release - it has been crafted
over a number of years now and is pretty mature. When it comes to
standards, this is the probably the best I know (not ideal, but at
least it is IETF standard draft).


Some observations:

- the readings embed the device name, making it possible to combine
readings from different devices in the same result array. EdgeX currently
adds the device name to the event, which contains readings.

- the format allows custom attributes to be defined, which would allow us
to add EdgeX specific attributes
Sure, this is all good. My only remark is that it is EdgeX specific,
and I think it is good to align on some more generic standard, if
possible.


- I don't think there's a big difference in size between our current
messages and the JSON SenML format, in fact the latter messages might even
be a bit larger than our current messages. That said, on constrained
devices using CBOR would be an advantage.
I think that difference comes from aggregated sensor measurements.
I.e. one sensor that reads for example temperature every hour, but it
does not send the reading immediately, but rather keeps the readings
in internal flash, then sends all in one message once a day. SenML is
good at packing these kind of messages in the array of readings,
removing redundancy and making messages as small as possible. For
cellular IoT sensors it is very important, as bandwidth is expensive.
And for battery powered devices radio Tx/Rx is the biggest enemy of
battery budget.


Implementing this would require pretty invasive re-work across all of our
services, so this is something we should put on our post-California
architecture list.
I totally agree. I am not even sure that this is the best idea for
EdgeX, I was just pointing out SenML as a potentially good candidate
for standardized message semantics. We can do some research and
evaluation in later phases, post California MVP.

BR,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Re: New Device Services & SDK Requirements document (v5)

espy
 

On 03/06/2018 06:24 PM, Drasko DRASKOVIC wrote:
On Tue, Mar 6, 2018 at 7:19 PM, espy <espy@...> wrote:

Thanks for the suggestion! It looks like this is still a draft, so we
should keep any eye on it as it progresses.
Yes, it's still a draft, but it's 13th release - it has been crafted
over a number of years now and is pretty mature. When it comes to
standards, this is the probably the best I know (not ideal, but at
least it is IETF standard draft).


Some observations:

- the readings embed the device name, making it possible to combine
readings from different devices in the same result array. EdgeX currently
adds the device name to the event, which contains readings.

- the format allows custom attributes to be defined, which would allow us
to add EdgeX specific attributes
Sure, this is all good. My only remark is that it is EdgeX specific,
and I think it is good to align on some more generic standard, if
possible.
Sure, I was just pointing out that if needed, the standard supports extra fields, so if we need the extensibility, it's already builtin.

- I don't think there's a big difference in size between our current
messages and the JSON SenML format, in fact the latter messages might even
be a bit larger than our current messages. That said, on constrained
devices using CBOR would be an advantage.
I think that difference comes from aggregated sensor measurements.
I.e. one sensor that reads for example temperature every hour, but it
does not send the reading immediately, but rather keeps the readings
in internal flash, then sends all in one message once a day. SenML is
good at packing these kind of messages in the array of readings,
removing redundancy and making messages as small as possible. For
cellular IoT sensors it is very important, as bandwidth is expensive.
And for battery powered devices radio Tx/Rx is the biggest enemy of
battery budget.
All good points.

Implementing this would require pretty invasive re-work across all of our
services, so this is something we should put on our post-California
architecture list.
I totally agree. I am not even sure that this is the best idea for
EdgeX, I was just pointing out SenML as a potentially good candidate
for standardized message semantics. We can do some research and
evaluation in later phases, post California MVP.
+1

Thanks!
/tony

Question on reverse proxy's usage

하지훈 <jihun.ha@...>
 

Hi. All,

 

As far as I know, there was a discussion on reverse proxy employment to EdgeX foundry for several security reasons. For that, it is hard for me to know how to apply the reverse proxy to a real edge device, so please let me know the details if anyone is looking on to this.

 

Questions

<Example topology>

Edge device (IP: 10.0.0.2)

 - core service (port: 48080)

 - export-distro service (port: 48070)

 

1. Is it the plan to run a reverse proxy service on every single Edge device? Or, a reverse proxy service is a single entity in a network and is responsible to receive and forward all requests destined to actual services of edge devices inside the network?

 

2. As Nginx and Traefik explained, I understand that services to be proxifed should have different domain names. For example, core.example.com and export.example.com domain names should be used for core service and export service, respectively. Then, should we force to define and use a domain name to a service rather than IP address?

  - Originally, if you want to get data from core service of edge device, you could use "10.0.0.2:48080" address.

  - Releated to Question 1, I think that if reverse proxy service is running on each edge device and we should use domain name to utilize reverse proxy, it sounds impratical. (because Every edge device has to have its own domain name unique in a network)

 

I'd appreciate if you can let me know how to employ a reverse proxy to the above edge device with core and export services?

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

Edge Platform Development | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

Re: Question on reverse proxy's usage

Zeng, Tingyu
 

Hey Jihun,

IMO “reverse proxy” refers to an abstract layer, which will be running every single edge device. It might be sitting within each micro service or be part of the process for core data/command/metadata.  The decision hasn’t been finalized.

Nginx and Traefk are using the subdomain as the method to filter and forward to request for proxy. For EdgeX this is just one of the options. Another option is to hook up the http request and intercept the calls within the existing core services.

The reverse proxy needs a way to identify the source of the caller and do authentication/authorization, which needs to be implemented within an Authorization Service.  This was discussed in the current proposal as well.

 

Hope it help.

Tingyu

 

From: edgex-tsc-security-bounces@... [mailto:edgex-tsc-security-bounces@...] On Behalf Of ???
Sent: Tuesday, March 13, 2018 3:40 AM
To: edgex-tsc-security@...
Subject: [Edgex-tsc-security] Question on reverse proxy's usage

 

Hi. All,

 

As far as I know, there was a discussion on reverse proxy employment to EdgeX foundry for several security reasons. For that, it is hard for me to know how to apply the reverse proxy to a real edge device, so please let me know the details if anyone is looking on to this.

 

Questions

<Example topology>

Edge device (IP: 10.0.0.2)

 - core service (port: 48080)

 - export-distro service (port: 48070)

 

1. Is it the plan to run a reverse proxy service on every single Edge device? Or, a reverse proxy service is a single entity in a network and is responsible to receive and forward all requests destined to actual services of edge devices inside the network?

 

2. As Nginx and Traefik explained, I understand that services to be proxifed should have different domain names. For example, core.example.com and export.example.com domain names should be used for core service and export service, respectively. Then, should we force to define and use a domain name to a service rather than IP address?

  - Originally, if you want to get data from core service of edge device, you could use "10.0.0.2:48080" address.

  - Releated to Question 1, I think that if reverse proxy service is running on each edge device and we should use domain name to utilize reverse proxy, it sounds impratical. (because Every edge device has to have its own domain name unique in a network)

 

I'd appreciate if you can let me know how to employ a reverse proxy to the above edge device with core and export services?

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

Edge Platform Development | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

 

[SECURITY] EdgeX Auth Service in Go

Drasko DRASKOVIC
 

Hi all,
I have advanced with my Auth service: https://github.com/drasko/edgex-auth

Currently:
- HTTPS (TLS v1.2) is working
- NginX is forwarding all requests to Auth service via standard
feature `auth_request`:
http://nginx.org/en/docs/http/ngx_http_auth_request_module.html

In progress:
- Consul auto-discovery support (NginX can read Consul)
- Traefik support (Traefik also has `auth_request` forwarding feature)

At this point I think that code has basic functionality and can be
contributed to EdgeX official codebase.

It will bring:
- User creation and management
- User login via JWT token
- Authorization (access control) to all API endpoints if user is not logged in
- TLS encryption

If you are interested I can present the service on one of the
following TSC meetings.

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic