On Thu, Aug 9, 2018 at 11:20 AM, Ondrej Tomcik <ondrej.tom...@kistler.com> wrote:
> Hello Greg, > > > > *Ondrej Tomcik **:: **KISTLER **:: **measure, analyze, inovate* > > > > *From:* Gregg Reynolds [mailto:d...@mobileink.com] > *Sent:* Thursday, August 9, 2018 5:45 PM > *To:* Tomcik Ondrej > *Cc:* iotivity-dev@lists.iotivity.org; Scott King < > scott.k...@fkabrands.com> (scott.k...@fkabrands.com); Max Kholmyansky ( > m...@sureuniversal.com); Kralik Jozef; Rafaj Peter > *Subject:* Re: OCF Native Cloud 2.0 > > > > > > > > On Thu, Aug 9, 2018 at 6:48 AM, Ondrej Tomcik <ondrej.tom...@kistler.com> > wrote: > > Dear IoTivity devs, > > > > Please be informed that the new Cloud 2.0 design concept is alive: > https://wiki.iotivity.org/coapnativecloud > > Your comments are warmly welcome. > > Implementation is in progress. > > > > > > Obviously you put a lot of work into this, thanks. > > > > How does it handle third-party users? For example, Mom, Dad, kids, > relatives, guests, all have different permissions, dynamically configurable. > > Current IoTivity implementation force you to use very specific user/device > management model. What is *bad.* > What is bad about it? To me the OCF security model boils down to resources, creds, ACLs, and the services need to enforce policies (auth/authz). I guess you are talking only about the Iotivity implementation, not the security model? If the implementation is bad we should look at improving it, no? G > In this concept, AuthorizationService implementation is completely up to > the user – user is the company who want to use the OCF Native Cloud. Of > course we will provide sample AuthorizationService which communicates with > the GitHub, but this one will be not used for production – I believe J. > If you’re interested in multiple owners of the device, share the device > with friends, and so on, you have to model this structure of users and > management on yur own. OCF Native Cloud just defines contract, how it is > communicating with the AuthorizationService. Meaning, the OCF Native Cloud > will ask AuthorizationService, if the pending request (resource uri + > device + token) is authorized or not. Token identifies the user who issued > the request and together with resource uri + device id, > AuthorizationService can clearly answer if the request is authorized or not. > > > > AuthorizationService should also emit events *(changes which SID (user > identifier – subject id) has access to which DID (DeviceId)),* which are > cached by the OCF Native Cloud so each user request is not triggering > request to the AuthorizationService. > > > > Make sense? You can see it here: > > https://wiki.iotivity.org/_media/auth_1.png?cache=&w=900&h=699&tok=413462 > > Or read whole Authorization Bounded Context - https://wiki.iotivity.org/ > coapnativecloud#authorization_bounded_context > > > > And, important is this note: > > Each request session must be backed by an access token, so the OCF Native > Cloud can authorize that request. In case of the OCF Servers / Clients, a > TCP session must be backed by the access token and validated through the > sign-up process. Each command issued by the OCF CoAP Gateway is then backed > by the validated token. > > > > Gregg > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9841): https://lists.iotivity.org/g/iotivity-dev/message/9841 Mute This Topic: https://lists.iotivity.org/mt/24238274/21656 Group Owner: iotivity-dev+ow...@lists.iotivity.org Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
