Date   
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

Re: [SECURITY] EdgeX Auth Service in Go

White2, James
 

Dell - Internal Use - Confidential

Drasko,
Thanks for this work!
Because this is a security feature, if you don't mind, let's work it through the security working group first. This WG has been working on the reverse proxy as well as AA and data protection (through Vault). I'd like to make sure their work and yours is merged appropriately. I can send a note to Doug Gardner (WG chair) tomorrow and ask that he get it on the schedule. After that conversation, we can move the work into the temp repo and work it through the new contribution process.

Thanks again Drasko.
Jim

-----Original Message-----
From: Drasko DRASKOVIC [mailto:drasko@...]
Sent: Sunday, March 18, 2018 9:26 PM
To: edgex-golang@...; edgex-tsc@...; edgex-devel@...; edgex-tsc-security@...; Janko Isidorovic <janko@...>; dejan.mjc <dejan@...>; Nikola Marcetic <nikola@...>; manuel@...; White2, James <James_White2@...>
Subject: [SECURITY] EdgeX Auth Service in Go

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

Re: [SECURITY] EdgeX Auth Service in Go

Drasko DRASKOVIC
 

Hi Jim,

On Mon, Mar 19, 2018 at 4:27 AM, <James.White2@...> wrote:
Dell - Internal Use - Confidential

Drasko,
Thanks for this work!
Because this is a security feature, if you don't mind, let's work it through the security working group first.
Sure - this is why mail was sent to TSC Security ML.

This WG has been working on the reverse proxy as well as AA and data protection (through Vault). I'd like to make sure their work and yours is merged appropriately. I can send a note to Doug Gardner (WG chair) tomorrow and ask that he get it on the schedule. After that conversation, we can move the work into the temp repo and work it through the new contribution process.
It should be noted that my work is in PoC phase. It implements a
service behind the reverse proxy to which proxy sends each request for
auth. This service is practically a "replacement" for "config file"
approach - the philosophy is the same, just that NginX does not read
config file, but consults Auth service instead.

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 Auth Service Proposal - PPT

Drasko DRASKOVIC
 

Hi all,
please find attached the slides I presented for Auth Service proposal.

GitHub repo: https://github.com/drasko/edgex-auth

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 Call (Wednesday, March 28)

Brett Preston
 

Members of the EdgeX Technical Community,

The focus for this week's TSC call will be to plan out the California release and identify resource gaps or issues for delivery.

Full agenda will be sent to the TSC mail list prior to the call, but in general, the schedule will be as follows:

9:00-9:30CST: Core, Supporting, Application work planning

9:30-9:55: Device Service work planning

9:55-10:05: break

10:05-10:30: Security work planning

10:30-11:00: System management work planning


For those on the Security mail list, please note that your call has been canceled for this week, as Security topics will be covered as part of the extended TSC meeting.

To be added to the meeting invite for Wednesday, please subscribe to the TSC mail list at https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc, or send me an email and I can add you directly to the mail list and/or meeting invite.

Dial-in information has also been provided below for easy reference:

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/983155298

Or iPhone one-tap (US Toll): +14086380968,983155298# or +16465588656,983155298#

Or Telephone:
    Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll)
    +1 855 880 1246 (US Toll Free)
    +1 877 369 0926 (US Toll Free)
    Meeting ID: 983 155 298
    International numbers available: https://zoom.us/zoomconference?m=mkFexUxEcqHlvXHw53PqScTDRvS48PiQ


Thank you,


Brett

--
Brett Preston
The Linux Foundation
+1 (971) 303-9030
bpreston@...

Google Talk: bpreston@...
Skype: bprestoncf

Re: Question on reverse proxy's usage

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

Hello. Tingyu.

 

Thank you for answering me. Because of you, I could be clear for that reverse proxy will stand on every edge device and have a role for doing authentication/authorization and forwarding a request to containers behind reverse proxy.

 

Then, I want to ask one more thing: how to configure reverse proxy to hook up all requests sent to inside containers

I think, there are two configurations to operate reverse proxy for multiple containers with regard to their REST APIs

 

Configuration-(A): Expose a same port(e.g. 8080, 443) and define "prefixed" URIs for containers

Configuration-(B): Expose container's exposed ports

 

IMO, Configuration-(B) looks better because containers can use thier own ports and REST APIs without any change even if reverse proxy is employed. On the other side, is there any advantage of Configuration-(A)?? Please let me know the advantage of Configuration-(A)

 

And which configurations is considered in EdgeX?? I know this is not decided, yet, but I want to know some opinion for those configurations.

 

I've remained an explanatory material for Configuration-(A) and (B), below. Hope it help to understand this discussion.

-------

  1. Configuration-(A): Expose a same port(e.g. 8080, 443) and define "prefixed" URIs for containers
    1. Figure
    1. Supported solution: Nginx, Traefik
    2. Pros
      1. Less port on host device is exposed --> More secure
      2. Port conflict problems could be mitigated for multiple containers using same port
        1. More than two containers using same port can be deployed to a single host
    1. Cons
      1. All containers should be distinguished by URIs of containers. To do that, URI prefix should be defined to the containers
        1. EdgeX Core service: <IP>:48098/api/v1  --> <IP>:8080/core-service/api/v1
        2. PROBLEM:  "Prefix" URIs should be pre-defined and agreed to all containers in the device (No use of same prefix URI to two containers)

 

  1. Configuration-(B): Expose container's exposed ports.
    1. Figure
    1. Supported solution: Nginx
    2. Pros
      1. Maintain container's own ports. No need to change REST APIs of containers
    1. Cons
      1. Port conflict problems for two containers could matter.

 

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

 

 

--------- Original Message ---------

Sender : Zeng, Tingyu <Tingyu.Zeng@...>

Date : 2018-03-14 07:11 (GMT+9)

Title : RE: [Edgex-tsc-security] Question on reverse proxy's usage

 

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

 

 

 

Re: EdgeX: TSC Call (Wednesday, March 28)

Brett Preston
 

TSC Meeting: Special Release Planning Meeting for CA call beginning in 30 minutes --

Slides:
https://docs.google.com/presentation/d/1ojeq8CtuPdAQyXtdb_Aw2xuBhLpPaJANFoum1gMUFMg/edit#slide=id.p3

Time: Wednesday, March 28, 7-9 AM (PDT)

Phone/Internet:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/983155298

Or iPhone one-tap (US Toll):  +14086380968,983155298# or +16465588656,983155298#

Or Telephone:
    Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll)
    +1 855 880 1246 (US Toll Free)
    +1 877 369 0926 (US Toll Free)
    Meeting ID: 983 155 298


Thanks,


Brett


On Mon, Mar 26, 2018 at 12:26 PM, Brett Preston <bpreston@...> wrote:
Members of the EdgeX Technical Community,

The focus for this week's TSC call will be to plan out the California release and identify resource gaps or issues for delivery.

Full agenda will be sent to the TSC mail list prior to the call, but in general, the schedule will be as follows:

9:00-9:30CST: Core, Supporting, Application work planning

9:30-9:55: Device Service work planning

9:55-10:05: break

10:05-10:30: Security work planning

10:30-11:00: System management work planning


For those on the Security mail list, please note that your call has been canceled for this week, as Security topics will be covered as part of the extended TSC meeting.

To be added to the meeting invite for Wednesday, please subscribe to the TSC mail list at https://lists.edgexfoundry.org/mailman/listinfo/edgex-tsc, or send me an email and I can add you directly to the mail list and/or meeting invite.

Dial-in information has also been provided below for easy reference:

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/983155298

Or iPhone one-tap (US Toll): +14086380968,983155298# or +16465588656,983155298#

Or Telephone:
    Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll)
    +1 855 880 1246 (US Toll Free)
    +1 877 369 0926 (US Toll Free)
    Meeting ID: 983 155 298
    International numbers available: https://zoom.us/zoomconference?m=mkFexUxEcqHlvXHw53PqScTDRvS48PiQ


Thank you,


Brett

--
Brett Preston
The Linux Foundation

Skype: bprestoncf



--
Brett Preston
The Linux Foundation
+1 (971) 303-9030
bpreston@...

Google Talk: bpreston@...
Skype: bprestoncf