Date   
Re: Question on reverse proxy's usage

Zeng, Tingyu
 

Hey Jihun,

As you described bother options have their pros/cons. The biggest issue with config-B is that it will expose multiple ports to the external world, which contradicts the main purpose of putting a reverse proxy between, so we prefer config-A as a better choice currently. Think about down the road for edgex – we may have AAA ( Authentication/Authorization/ AccessControl) features added in to the product so a centralized reverse proxy will single entry point may server better IMHO.

Tingyu

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

 

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

a.     Figure

                              i.       

b.     Supported solution: Nginx, Traefik

c.     Pros

                              i.        Less port on host device is exposed --> More secure

                             ii.        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

d.     Cons

                              i.        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)

 

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

a.     Figure

                              i.       

b.     Supported solution: Nginx

c.     Pros

                              i.        Maintain container's own ports. No need to change REST APIs of containers

d.     Cons

                              i.        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

 

 

 

 

security development/testing tools for EdgeX?

Zeng, Tingyu
 

David & Riaz,

 

As we are getting close to identify the security features of EdgeX, we have covered KONG/Traeffic etc as reverse proxy, HashiCorp Vault for local secret protection etc, however it seems  security testing is something that hasn’t been brought out for discussion.

 

I am thinking some testing tools list here that may benefit the product, such as

-          Static code analysis ( VeraCode etc)

-          Pen testing suite (Metasploit, Nessus)

-          Container security ( Twistlock etc.)

 

what are your opinions regarding security tools that may benefit the development and testing in a big scope?

 

 

Thanks,

Tingyu

Re: Question on reverse proxy's usage

Jihun Ha <jihun.ha@...>
 

Hi. Tingyu.

 

Thank you for sharing valuable information and your opinion.

BTW, is there any candidate URIs for EdgeX containers where reverse proxy is employed?

For example:

    device service --> http://<host IP>:80/device-service/api/v1/deviceprofile

    notification service --> http://<host IP>:80/nofi-service/api/v1/subscription

 

I'd appreciated if you can let me know :)

 

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-29 04:57 (GMT+9)

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

 

Hey Jihun,

As you described bother options have their pros/cons. The biggest issue with config-B is that it will expose multiple ports to the external world, which contradicts the main purpose of putting a reverse proxy between, so we prefer config-A as a better choice currently. Think about down the road for edgex – we may have AAA ( Authentication/Authorization/ AccessControl) features added in to the product so a centralized reverse proxy will single entry point may server better IMHO.

Tingyu

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

 

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

a.     Figure

                              i.       

b.     Supported solution: Nginx, Traefik

c.     Pros

                              i.        Less port on host device is exposed --> More secure

                             ii.        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

d.     Cons

                              i.        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)

 

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

a.     Figure

                              i.       

b.     Supported solution: Nginx

c.     Pros

                              i.        Maintain container's own ports. No need to change REST APIs of containers

d.     Cons

                              i.        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: Question on reverse proxy's usage

Zeng, Tingyu
 

The decision hasn’t been made but the community is leaning towards using the individual existing micro service name of the EdgeX as short partial url, just like the example mentioned in your email.

One thing we need to pay attention when choosing the proper partial url is to avoid using special characters in the url due to two reasons.

1.       The special characters needs to be encoded in the URL when passing around.

2.       The special characters are risky in url and query string from security perspective, mainly because of the potential XSS vulnerability.

 

Thanks,

Tingyu

From: EdgeX-TSC-Security@... [mailto:EdgeX-TSC-Security@...] On Behalf Of Jihun Ha
Sent: Tuesday, April 3, 2018 10:53 PM
To: EdgeX-TSC-Security@...
Subject: Re: [Edgex-tsc-security] Question on reverse proxy's usage

 

Hi. Tingyu.

 

Thank you for sharing valuable information and your opinion.

BTW, is there any candidate URIs for EdgeX containers where reverse proxy is employed?

For example:

    device service --> http://<host IP>:80/device-service/api/v1/deviceprofile

    notification service --> http://<host IP>:80/nofi-service/api/v1/subscription

 

I'd appreciated if you can let me know :)

 

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-29 04:57 (GMT+9)

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

 

Hey Jihun,

As you described bother options have their pros/cons. The biggest issue with config-B is that it will expose multiple ports to the external world, which contradicts the main purpose of putting a reverse proxy between, so we prefer config-A as a better choice currently. Think about down the road for edgex – we may have AAA ( Authentication/Authorization/ AccessControl) features added in to the product so a centralized reverse proxy will single entry point may server better IMHO.

Tingyu

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

 

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

a.     Figure

                              i.       

b.     Supported solution: Nginx, Traefik

c.     Pros

                              i.        Less port on host device is exposed --> More secure

                             ii.        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

d.     Cons

                              i.        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)

 

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

a.     Figure

                              i.       

b.     Supported solution: Nginx

c.     Pros

                              i.        Maintain container's own ports. No need to change REST APIs of containers

d.     Cons

                              i.        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

 

 

 

 

 

JWT token validation on reverse proxy

Jihun Ha <jihun.ha@...>
 

Greetings,

 

When I read the document (https://wiki.edgexfoundry.org/download/attachments/329467/18_03_14_ver_EdgeX-simple-jwt-auth-DRAFT.docx?version=1&modificationDate=1521118200000&api=v2) about reverse proxy and auth server, I had a little confiusion for validation JWT token on reverse proxy.

AFAIK, JWT has a capability to validate the received token by resource server without any  query to auth server or database, which can be done by self-containing information in JWT token.

So if reverse proxy is employed and API request with JWT token is sent to the reverse proxy, I think it can validate the token by itself without query to Authorization Server.

But Page 2~3 in the attached document describes that Reverse Proxy receives the JWT token and query the token to Authorization Server, which looks weird to me.

    

What am I missing now in this point? I'd appreciated if anyone correct me :)

 

Thank you in advance.

 

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

 

 

Issue JWT Token to EdgeX service

Jihun Ha <jihun.ha@...>
 

Hello, Mr. Draskovic.

 

I've read your proposed EdgeX auth service document and have a few of question on that:

What if EdgeX services on different devices need to communicate with each other WITHOUT any user's interaction? According to your proposal, service on the client side should have its JWT token and send it to the peer service. That means, it sounds like the client service should get JWT token through login procedure. But it is hard for me to imagine how a service can login to Auth service to get JWT token without any user's input. It is because I think it is very hard to put account/password to every single services to get their own JWT token.

 

Is that any way for EdgeX service to get JWT token or something to service authentication without user's account and password? Or, other authentication method like certificate-based authentication should be used in case of service authentication?

 

Thank you in advance.

 

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: Issue JWT Token to EdgeX service

Drasko DRASKOVIC
 

Hi Jihun,

On Tue, Apr 10, 2018 at 8:24 AM, Jihun Ha <jihun.ha@...> wrote:

Hello, Mr. Draskovic.



I've read your proposed EdgeX auth service document and have a few of question on that:

What if EdgeX services on different devices need to communicate with each other WITHOUT any user's interaction?
All the flow described in the doc happens without human interaction.

According to your proposal, service on the client side should have its JWT token and send it to the peer service. That means, it sounds like the client service should get JWT token through login procedure.
No - this token is a permanent bearer token (a key) that is flashed
into the device firmware in the factory. Note that expiration time for
these kind of tokens is usually set to never expire,in order to
simulate simple bearer token (although refreshing a token is also
possible scenario, if the server supports this feature).

JWT token can also be revoked (if server supports), or/and replaced if
the device's firmware supports this operation.

But it is hard for me to imagine how a service can login to Auth service to get JWT token without any user's input. It is because I think it is very hard to put account/password to every single services to get their own JWT token.
No need for login or any user accounts: device just presents it's key
(JWT token), and if the token is valid we authenticate device (we let
requests from this device pass into the system).


Is that any way for EdgeX service to get JWT token or something to service authentication without user's account and password? Or, other authentication method like certificate-based authentication should be used in case of service authentication?
Certificate-based auth is complex because you would need to maintain
PKI infrastructure on the server side. Simple bearer tokens (in this
case JWT) are much more simpler.

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: JWT token validation on reverse proxy

Drasko DRASKOVIC
 

On Tue, Apr 10, 2018 at 2:58 AM, Jihun Ha <jihun.ha@...> wrote:

Greetings,



When I read the document (https://wiki.edgexfoundry.org/download/attachments/329467/18_03_14_ver_EdgeX-simple-jwt-auth-DRAFT.docx?version=1&modificationDate=1521118200000&api=v2) about reverse proxy and auth server, I had a little confiusion for validation JWT token on reverse proxy.

AFAIK, JWT has a capability to validate the received token by resource server without any query to auth server or database, which can be done by self-containing information in JWT token.

So if reverse proxy is employed and API request with JWT token is sent to the reverse proxy, I think it can validate the token by itself without query to Authorization Server.
True - token can be validated, but if we want to support token
revocation, then Auth server must look into the DB and see the list of
revoked tokens, in order to refuse the token which has been revoked.

In it's basic way of usage, JWT do not support/advise revocation -
because it is stateless and has short TTL, thus has to be continuously
refreshed (or re-generated by user re-log). However, in the case of
devices these JWTs should be observed purely as a bearer tokens, a
keys that never expire, so can be eventualy revoked on the server if
key is leaked from device's flash. This makes these JWT stat-full, and
you need a DB to track the list of revoked keys.


But Page 2~3 in the attached document describes that Reverse Proxy receives the JWT token and query the token to Authorization Server, which looks weird to me.
Where you will keep a JWT sercret and verify the JWT - even if it is
stateless - it's up to you. So we can put it in reverse proxy if it
supports JWT check (Kong does, but not every proxy has this
functionality), or you can give this secret to every single service
and let it decode the JWT (only if these JWTs are stateless, as I
mentioned before). I find this less secure, and prefer concentrating
secret to one single dedicated service (Auth server) - and anyway,
device JWTs will probably be state-full, so handling everything on one
Auth server makes sense.

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

Opinions/suggestions regarding security testing framework and approach targeting EdgeX California release?

Zeng, Tingyu
 

Hello community,

 

We just had our first security testing group meeting this morning and there are two security testing guides discussed.

 

1.       OWASP IoT top 10 and IoT security guidance https://www.owasp.org/index.php/IoT_Security_Guidance

OWASP is a collaboration of application security community and it’s top 10 list are well recognized and followed.

 

2.        IIC Endpoint security best practices https://www.iiconsortium.org/pdf/Endpoint_Security_Best_Practices_Final_Mar_2018.pdf

It was released about two weeks ago and categorizes the aspects of security of endpoint

 

 

As an initial efforts we are trying to map these guidance into EdgeX and evolve the security testing along future EdgeX releases. Let us know if you have different idea or suggestions. A draft will be provided to reflect our approach later.

 

 

Thanks,

Tingyu

 

 

Re: Opinions/suggestions regarding security testing framework and approach targeting EdgeX California release?

Andrew Foster
 

Folks,

 

We’ve setup a Security Testing Subgroup page on the WikI  at https://wiki.edgexfoundry.org/display/FA/Security+Testing+Subgroup to keep track of future scheduled meetings, recordings, minutes, work items, documents etc.

 

Regards,

 

Andy

 

From: EdgeX-TSC-Security@... <EdgeX-TSC-Security@...> On Behalf Of Zeng, Tingyu
Sent: Tuesday, April 10, 2018 4:44 PM
To: EdgeX-TSC-Security@...
Subject: [Edgex-tsc-security] Opinions/suggestions regarding security testing framework and approach targeting EdgeX California release?

 

Hello community,

 

We just had our first security testing group meeting this morning and there are two security testing guides discussed.

 

  1. OWASP IoT top 10 and IoT security guidance https://www.owasp.org/index.php/IoT_Security_Guidance

OWASP is a collaboration of application security community and it’s top 10 list are well recognized and followed.

 

  1.  IIC Endpoint security best practices https://www.iiconsortium.org/pdf/Endpoint_Security_Best_Practices_Final_Mar_2018.pdf

It was released about two weeks ago and categorizes the aspects of security of endpoint

 

 

As an initial efforts we are trying to map these guidance into EdgeX and evolve the security testing along future EdgeX releases. Let us know if you have different idea or suggestions. A draft will be provided to reflect our approach later.

 

 

Thanks,

Tingyu

 

 

EdgeX Documentation Preview

Andrew Foster
 

Dear EdgeX community,

 

As part of the forthcoming California release it was decided that the existing product level content from the Wiki and any new content generated to support the release would be converted into a format (we decided on reStructuredText - reST) that enables this information to live alongside the code and be managed from the EdgeX Foundry GitHub repository.

 

The initial work to support the work has now been completed, although we are still improving and tidying up the content as we head towards the California release.

 

The new documentation can be accessed at https://github.com/edgexfoundry/edgex-go/tree/master/docs. Once you have cloned the edgex-go repository you can simply build the documentation by running $ . build.sh from the /docs directory.

 

The source reST and graphics files are held in individual directories underneath the /docs directory.

 

We have also hosted a generated HTML version of EdgeX Documentation at  https://www.iotechsys.com/cmsfiles/iotech_systems/docs/html/index.html it you don’t want to build your own local copy of the documentation then this is the best place to start.

 

We would welcome feedback on the new documentation and if you spot any typos, bad formatting etc. then you can simply report it to me (andy@...) to start with or alternatively add an Issue to GitHub and assign it to me (andyf1967).

 

Regards,

 

Andy

 

Product Director

Tel: +44 (0)7703 006 379

 

Re: EdgeX Documentation Preview

Drasko DRASKOVIC
 

Interestingly enough, works on ReadTheDocs practically out of the box:
http://edgex-foundry.readthedocs.io

At least first two chapters, then it got lost :)

I just pointed ReadTheDocs to our repo, this is what it produced. I'd
have to see if some additional tweaks are needed and how to tell RDD
to use it's own template, not this white one...

Best regards,
Drasko

On Tue, Apr 17, 2018 at 11:41 AM, Andrew Foster <andy@...> wrote:
Dear EdgeX community,



As part of the forthcoming California release it was decided that the
existing product level content from the Wiki and any new content generated
to support the release would be converted into a format (we decided on
reStructuredText - reST) that enables this information to live alongside the
code and be managed from the EdgeX Foundry GitHub repository.



The initial work to support the work has now been completed, although we are
still improving and tidying up the content as we head towards the California
release.



The new documentation can be accessed at
https://github.com/edgexfoundry/edgex-go/tree/master/docs. Once you have
cloned the edgex-go repository you can simply build the documentation by
running $ . build.sh from the /docs directory.



The source reST and graphics files are held in individual directories
underneath the /docs directory.



We have also hosted a generated HTML version of EdgeX Documentation at
https://www.iotechsys.com/cmsfiles/iotech_systems/docs/html/index.html it
you don’t want to build your own local copy of the documentation then this
is the best place to start.



We would welcome feedback on the new documentation and if you spot any
typos, bad formatting etc. then you can simply report it to me
(andy@...) to start with or alternatively add an Issue to GitHub
and assign it to me (andyf1967).



Regards,



Andy



Product Director

Tel: +44 (0)7703 006 379



--
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 Documentation Preview

Andrew Foster
 

Drasko,

It might be hierarchy that confuses it. Also there is a step in the build process to run raml2html and incorporate the generate HTML into the overall set of HTML. No idea how ReadTheDocs would deal with that (haven't had a chance to investigate).

Regards,

Andy

-----Original Message-----
From: Drasko DRASKOVIC <drasko@...>
Sent: Tuesday, April 17, 2018 12:57 PM
To: Andrew Foster <andy@...>
Cc: edgex-tsc-core@...; edgex-tsc-qa-test@...; edgex-tsc-security@...; edgex-tsc-systems-mgmt@...; edgex-tsc-devops@...
Subject: Re: [Edgex-tsc-security] EdgeX Documentation Preview

Interestingly enough, works on ReadTheDocs practically out of the box:
http://edgex-foundry.readthedocs.io

At least first two chapters, then it got lost :)

I just pointed ReadTheDocs to our repo, this is what it produced. I'd have to see if some additional tweaks are needed and how to tell RDD to use it's own template, not this white one...

Best regards,
Drasko






On Tue, Apr 17, 2018 at 11:41 AM, Andrew Foster <andy@...> wrote:
Dear EdgeX community,



As part of the forthcoming California release it was decided that the
existing product level content from the Wiki and any new content
generated to support the release would be converted into a format (we
decided on reStructuredText - reST) that enables this information to
live alongside the code and be managed from the EdgeX Foundry GitHub repository.



The initial work to support the work has now been completed, although
we are still improving and tidying up the content as we head towards
the California release.



The new documentation can be accessed at
https://github.com/edgexfoundry/edgex-go/tree/master/docs. Once you
have cloned the edgex-go repository you can simply build the
documentation by running $ . build.sh from the /docs directory.



The source reST and graphics files are held in individual directories
underneath the /docs directory.



We have also hosted a generated HTML version of EdgeX Documentation at
https://www.iotechsys.com/cmsfiles/iotech_systems/docs/html/index.html
it you don’t want to build your own local copy of the documentation
then this is the best place to start.



We would welcome feedback on the new documentation and if you spot any
typos, bad formatting etc. then you can simply report it to me
(andy@...) to start with or alternatively add an Issue to
GitHub and assign it to me (andyf1967).



Regards,



Andy



Product Director

Tel: +44 (0)7703 006 379





--
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: Security call canceled today

Brett Preston
 

Members of the Security WG,

In case the cancelation notice did not arrive in your inbox, a quick note to inform you that today's Security WG call has been canceled.

Thank you,


Brett

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

Google Talk: bpreston@...
Skype: bprestoncf

EdgeX Security WG call canceled for Wednesday, April 25

Brett Preston
 

Members of the EdgeX Security WG,

This week's call is canceled, as several WG members are at Hannover Messe.

The next call will be on Wednesday, May 2.

Thank you,


Brett

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

Google Talk: bpreston@...
Skype: bprestoncf

NIST IoT Security/Privacy workshop

Zolfonoon, Riaz
 

Hi All,

 

FYI, this is a last-minute announcement of an upcoming NIST IoT workshop (I just heard about it myself). Just letting you know if anyone is interested in attending. The registration ends today though!

 

https://www.nist.gov/news-events/events/2018/07/considerations-managing-iot-cybersecurity-and-privacy-risks-workshop

 

The pre-read document for attendees is attached to provide more context.


Thanks, Riaz

 

 

First design discussion for HW based Secure Storage

David Ferriera
 

Hi All,

   We will have our first design discussion in tomorrows weekly meeting.  Jay from Intel has agreed to attend.  This is the first session so we will spend some time discussing a baseline of the feature.

  TPM and PKCS#11 may come up in the conversation.  Here are some links.  No need to read the specs by tomorrow :)  Overviews are good enough.




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

Blog: Security Services in California release

Michael Hall <mhall@...>
 

Hi Mae,

Here's a link to a draft for my next blog entry, about the security
services introduced in the California release. It doesn't go into a lot
of technical detail, but gives an overview of what the benefit of those
services are and the role they play in the overall architecture of EdgeX
Foundry.

https://docs.google.com/document/d/1yghKb3NkinqSVyUYDTNVujmVYB_6z5q_TSj6IKBXqQQ/edit?usp=sharing

I've also copied the Security WG mailing list on this. David, Tingu,
Alain this is based off the information I got from your presentation to
the TSC last month. Can you also review the text and let me know if I
got anything wrong, or anything that you would like to be added? The
purpose of the blog post is to spread awareness that we have these
security services now, and then if people are interested in more details
we can direct from there.

Thank you all!

--
Michael Hall
Contractor, The Linux Foundation

Re: Blog: Security Services in California release

Zeng, Tingyu
 

I am updating the document for some minor changes.

Thanks,
Tingyu

-----Original Message-----
From: EdgeX-TSC-Security@... [mailto:EdgeX-TSC-Security@...] On Behalf Of Michael Hall
Sent: Friday, August 10, 2018 3:44 PM
To: Maemalynn Meanor; edgex-tsc-security@...
Cc: Brett Preston
Subject: [Edgex-tsc-security] Blog: Security Services in California release

Hi Mae,

Here's a link to a draft for my next blog entry, about the security services introduced in the California release. It doesn't go into a lot of technical detail, but gives an overview of what the benefit of those services are and the role they play in the overall architecture of EdgeX Foundry.

https://docs.google.com/document/d/1yghKb3NkinqSVyUYDTNVujmVYB_6z5q_TSj6IKBXqQQ/edit?usp=sharing

I've also copied the Security WG mailing list on this. David, Tingu, Alain this is based off the information I got from your presentation to the TSC last month. Can you also review the text and let me know if I got anything wrong, or anything that you would like to be added? The purpose of the blog post is to spread awareness that we have these security services now, and then if people are interested in more details we can direct from there.

Thank you all!

--
Michael Hall
Contractor, The Linux Foundation

Re: Blog: Security Services in California release

Maemalynn Meanor <maemalynn@...>
 

Thank you, Michael and Tingyu! Unless this group has any objections or addition changes, I’ll prep this to go live tomorrow. 


Thanks,
Mae

Maemalynn Meanor
PR Manager 
The Linux Foundation
Maemalynn@...
(602) 541-0356
Skype: Maemalynn





On Aug 10, 2018, at 1:29 PM, Zeng, Tingyu <Tingyu.Zeng@...> wrote:

I am updating the document for some minor changes.

Thanks,
Tingyu

-----Original Message-----
From: EdgeX-TSC-Security@... [mailto:EdgeX-TSC-Security@...] On Behalf Of Michael Hall
Sent: Friday, August 10, 2018 3:44 PM
To: Maemalynn Meanor; edgex-tsc-security@...
Cc: Brett Preston
Subject: [Edgex-tsc-security] Blog: Security Services in California release

Hi Mae,

Here's a link to a draft for my next blog entry, about the security services introduced in the California release. It doesn't go into a lot of technical detail, but gives an overview of what the benefit of those services are and the role they play in the overall architecture of EdgeX Foundry.

https://docs.google.com/document/d/1yghKb3NkinqSVyUYDTNVujmVYB_6z5q_TSj6IKBXqQQ/edit?usp=sharing

I've also copied the Security WG mailing list on this. David, Tingu, Alain this is based off the information I got from your presentation to the TSC last month. Can you also review the text and let me know if I got anything wrong, or anything that you would like to be added? The purpose of the blog post is to spread awareness that we have these security services now, and then if people are interested in more details we can direct from there.

Thank you all!

--
Michael Hall
Contractor, The Linux Foundation