Add support for conditional access based on user role

[kaikreuzer]

migrated from Bugzilla #423548 status NEW severity enhancement in component Core for --- Reported in version unspecified on platform PC Assigned to: Project Inbox

On 2013-12-08 15:16:18 -0500, Kai Kreuzer wrote:

Migrated from https://code.google.com/p/openhab/issues/detail?id=387

On 2015-09-25 03:52:04 -0400, Kai Kreuzer wrote:

Some input from my side what I see should be covered. There are multiple levels of access control that can be addressed:

1. Global access control as it is done in openHAB 1 (see https://github.com/openhab/openhab/wiki/Security#authentication). I.e. for any access to the runtime, the user needs credentials and is then assigned a role. JAAS is probably a good option here. Note that the solution has to work in general for any OSGi HttpService, it must not be specific to Jetty (while in openHAB 2, we can add a Jetty-specific configuration for JAAS then).
2. Restrict certain urls and/or http verbs for certain roles. See the example discussed in https://www.eclipse.org/forums/index.php/t/1068387/.
3. Restrict access on certain data, e.g. return a HTTP 403 when my kids try to access localhost:8080/classicui/app?sitemap=admin. This could be implemented in phases, the most important resource would be sitemaps, then come items, things, rules, etc. But in general this mechanism should be available on all resources. Configuration of such restrictions should not only be by resource name, but possibly also by type/tag, e.g. do not grant access to any item that is tagged as "security".
4. Filter data within requests, i.e. if I do not have rights for sitemap "admin" (see 3), the REST url /rest/sitemaps should not even list it. Sitemaps that refer to items that I am not allowed to access should filter out these widgets automatically.
5. Check implications on automation rules. Normally, rules are executed by the system and not the user. But we could imagine that a trigger was caused by some user (e.g. an item state change) and thus the rule could be regarded to be executed on behalf of this user - then again, the permissions should be checked and e.g. sending commands to restricted items must be blocked.

Does anybody has further ideas/requirements?

[kaikreuzer]

I proposed Shiro long time ago in this topic.

@marziman We are all aware of this and @splatch had answered on that already at that time. And I fully agreed with him that if there is a way to avoid bringing external libs into the core ESH APIs, it should be done by all means!

So again why we dont first look into enabling the usage of Shiro?

Because any 3rd party lib should clearly only be a second choice for the reasons mentioned above.

[kaikreuzer]

@splatch Many thanks for your detailed answer. I hope I didn't sound too harsh, it was just late last night ;-) I definitely didn't want to complain about the work you have done so far and I am well aware that you always said that there are still important parts missing.

I am still in support of your approach to keep a concrete implementation out of the core and rather only define APIs and wrappers in ESH (where ESH-solutions could then plug in something like Shiro). The AuthenticationProvider is a good start in this direction, but what I found is that we will probably also have to design the AbstractSecurityHandler in a similar way - it should be possible for solutions to do decisions on the "raw" HttpServletRequest; this could be potentially be merged with the JAX-RS stuff as I am not sure whether ContainerRequestContext is really necessary, if we had the HttpServletRequest instead.

but first I have to digg a little bit more around pax web to source http context used for registering servlets.

Note that ESH does not use http whiteboard pattern, but all servlets register through httpService.registerServlet where they pass the appropriate HttpContext (at the moment always the default one retrieved through httpService.createDefaultHttpContext()). So we could actually simply define an interface AuthenticatedHttpContext and assume an according implementation is registered by the solution as an OSGi service as per discussion above. If we had this as a service and we find a way to make it available to pax-web, it could then also be used for servlets that are added through the white-board pattern (although this is currently not relevant for ESH itself).

[kaikreuzer]

So we could actually simply define an interface AuthenticatedHttpContext and assume an according implementation is registered by the solution as an OSGi service as per discussion above.

Maybe not a good idea after all. The less intrusive way would not to fiddle with the HttpContext, but to use a servlet filter. For openHAB, this could be done through pax-web and there is no need to change any code in ESH.

[splatch]

The less intrusive way would not to fiddle with the HttpContext, but to use a servlet filter.

I thought about filter and pax-web because it allows to plug in standard filter based security. Can't remember if filter registration is already part of Http Service specification or not, but even if not - soon should be. :) Http context reference will be needed just to bind servlets together with filter to group them into one "webapp" without having single WAR. After that regular Java EE filter should be able to handle multiple paths (servlets).

[kaikreuzer]

if filter registration is already part of Http Service specification

Not it isn't - at least not in the OSGi version used in ESH as a minimal requirement (4.2).

[madte]

@kaikreuzer Sorry for the super late response. Working out the Secure Device Pairing and secure communication topics consumed a lot of time, unfortunately i won't be able to really understand the OpenHAB software architecture to present a detailed concept on how to integrate access control. There will only be some high level information about access control concepts in general and a rough concept for OpenHAB in my thesis. My CoAP binding with DTLS support made good progress though, i will look into submitting a pull request after I successfully defended my thesis, which should be around the end of april.

To your question about using third-party frameworks. With security related systems, it is always advisable not to design and implement your own solutions, but to use widely used, thouroughly tested and if possible standardized components that ideally have formally verified security properties. The main reason for that is simply that implementations usually have bugs, which can render the whole security concept useless. With established widely used solutions, many bugs have already been found and fixed. Standardized solutions also generate more public interest and therefore the underlying protocols and the implementations are often checked by information security researchers. So i would definetly recommend to design and implement as few as possible yourself. To secure the RESTful API, the Eclipse Keti project looks promising to me.

[kirantpatil]

Hi @madte,

Is CoAP binding with DTLS support available for public testing ?

Please post the source code link and instructions to test it.

Thanks.

[marziman]

Hi @kaikreuzer, just came across this. Is there any news on this? I think this is still important abd wanted to ask how the state is

[kaikreuzer]

@marziman See here. I am happy for anyone that is willing to pick this up!

[marziman]

Hi @splatch , @JochenHiller and @htreu ,

as discussed at the SmartHomeDay. Lets get this back on the focus. I would like to pick this up as @kaikreuzer aked for it. I wann also include @heikoscholtes to the discussion. Can we maybe shortly discuss how to proceed with this topic? We can provide some ideas, requirements which we see as important for this topic. We were thinking about things like:

• User & Authorization (permission) concept
• Next to BasicAuth, also OAuth2 support
• Item based access control, assigned to a user or subuser

After better understanding what could be done and what is even possible, we can split the work between all involved people.

What would be the best way from your point of view colleagues?

Thx & BR Mehmet

[JochenHiller]

@marziman Thanks for picking that up again. As you pointed out it would be good to agree on common requirements and derive then the implementation concept. OAuth2 would be an essential part of that, where we can try to make an initial contribution based on existing solution.

I can imagine that steps:

• have a call to refine yet known requirements
• sum up, document and agree on these requirements here
• have a second call to talk about implementation components (AuthN, AuthZ, RBAC, OAuth2, ...)
• have an implementation concept, probably rough API design, document here
• split up work between volunteers

Any comments? Me and maybe 1-2 more colleagues would join on that. Who else would like to be involved?

[kirantpatil]

@marziman,

Is it going to be part of ESH ?

We are also in plan to implement it in ESH rather on OH2.

New developer from our end will join from mid of next (Nov) month.

Thanks for your initiative.

[HeikoScholtes]

@JochenHiller: this sounds great and I totally agree on proceeding as suggested by you. Please also involve me in these discussions/calls.

Thank you for picking up this initiative again @marziman

[splatch]

Soon this issue will turn 2 years old. Just few days ago a year passed since my authentication experiments (26th Oct 2016), which took me 6 months ;-). I think it is definitely a time to get back to this topic.

I am a little bit concerned about going with things such this via calls as their usual outcome needs to be written somewhere. Then it gets clarified over few review cycles in order to proceed with work. I don't know exact rules for Eclipse Foundation but we could start from shared google doc which could be edited and commented by interested people in order to get final requirements. Call can be added when there will be a necessity for wider discussion.

From my side I can summarise all constraints and limitations in technical area from my past findings and post them as document for further review and verification.

[sjsf]

I don't know exact rules for Eclipse Foundation

The Eclipse Development Process isn't specific about any tools or the like. The main thing we have to keep in mind here would be the point about the OS rules of engagement, which require everything to be open and transparent.

So in my interpretation it shouldn't be a problem if you talk to each other or use a (public!) google docs for syncing and editing the requirements collaboratively as long as you eventually paste them here into an issue once everything got worked out. This would be only to make sure e.g. the owner of the document doesn't close it down later on or google shutting down its services.

[marziman]

@splatch, @JochenHiller,

sorry for being a little in standby. I had some private happenings where I lost my Dad and it was a hard time. I would say, maybe everybody can write down his ideas/requirements (functional and technical). @splatch you can also write down what you found out and whats your mind. After that we follow Jochens proposal and steps.

When would be a good time to meet? Lets nail down a date and everybody should bring his ideas and requirements until that date. This could be a skype call. Can we exchange emails and skype, so we can better communicate?

Lets continue on this one, since we are a lot of people and joining forces will surely bring this topic foward!

BR Mehmet

[marziman]

@splatch: Just do it. Start the Google Doc and we add stuff. If you wanna share it before hand, we can take a look and add our ideas too.

It is important to have a discussion base and a call to agree on some parts from my point of view.

[splatch]

@marziman sure, gimme day or two to recap on what was made and put it into gdoc.

[jmsjones]

I have been looking over this thread and the linked material and wanted to pass along some initial thoughts.

Clarifications regarding requirements

• What authentication methods need to be supported? Username and password is a minimum. OAuth2 has been requested. I have been considering using LDAP.
• Most of the discussion has been based on runtime access, such as can the user view a certain sitemap. Does access to configuration need to be controlled as well, such as creating items? I can see arguments either way on this. Controlling access to configuration is much more complex.
• One of the comments above states "It would also be nice to open up a guest mode if you are connected locally but not expose that externally". I'm not clear on the intended meaning of local vs. external in this context, but it does imply that access should be controlled by location in addition to user. Is this something that needs to be considered? I believe that external access is a separate issue and that only the user should be considered.
• Is there any expectation that this security implementation will be sufficient to allow remote access directly from the internet? I expect not.
• Are entities (items, sitemaps, etc.) secured as a whole, or to the property level? Examples:
  • A user might be able to view the state of an item but not the tags.
  • If configuration access control is implemented, a user might be able to change an item label, but not modify its parent groups.

Issues

• If configuration access control is desired, it can only be realistically applied to entities configured through the REST interface. Access to text configuration files is controlled by the OS.
• Entities do not have any hierarchy or structure. In my experience the ability to inherit permissions in a hierarchy makes management much simpler.
• All UIs will need to be modified to provide login methods. This should be fairly straightforward for username/password entry, but third party systems such as OAuth could be more convoluted.

Other notes

• If users are conditionally allowed to create rules, then the rules will need to be able to execute as a specific user (impersonation).
• Add-ons that run outside the server process (such as HABPanel) will need to be able to access custom permissions.

[splatch]

Hi all, It took me longer than expected, but I closed part related to description of concept and put a small list of initial requirements. Document is available here: https://docs.google.com/document/d/1Vja574ycr2f_1nDdhLheEPdqkRlsvHf2lc_byY2ahzc/edit?usp=sharing. If you would like to get write access to change document contact me at luke@code-house.org - will send you invite. If you need to move document anywhere else to official accounts - feel free to do such. I'm not seeing myself as any kind of moderator or supervisor to this part of eclipse smart home, but based on additional requirements provided by you, together we will be able to confront concept with expectation and, discuss further steps.

Technical limitations are very short at this moment as I didn't want to dive into this area again before requirement clarification.

[marziman]

@splatch Thanks alot. We will add our comments and I had a longer discussion with @HeikoScholtes about this topic before christmas break, resulting that Heiko is going to provide our ideas, requirements in a document, too (maybe directly in your doc). We may at the end merge all of the inputs, as soon we have all feedbacks and a common accepted view on this. From our side, @HeikoScholtes will actively be the contact person, since he is responsible for the main dev activities on our side.

BR Mehmet

[ghys]

Hi, I just want to link to #3113 here - I tried adding basic support for JSON Web Tokens a while ago but never got around to finish it (there are many implications, notably make all UIs implement an OAuth2/OIDC flow, I only made the parsing of tokens inside the Authorization header part). Perhaps it will be of value, since the requirements document has very similar concepts.

[HeikoScholtes]

Hi @splatch, @ghys, @kaikreuzer and @marziman. I also added a second document with requirements that also include authentication and authorisation use-cases from a cloud point of view. Imagine you have a remote access to the ESH server you also need to authenticate and authorise the users in the cloud and if the cloud is offline you also have to consider and synch it with the ESH mechanisms. The contribution is to provide a different angle on the topic, considering the cloud part and remote access. Before I merge the requirements and document with the one from @splatch I would like to get your opinion on this remote access aspect.

Thank you and BR Heiko

ESH_access_control.zip

[marziman]

@JochenHiller & @kaikreuzer can you also provide your feedback to the shared documents. I think we need to have a hangouts soon, if all interested parties of community gave their input. There we can nail down some points and discuss how to proceed.

Thx & BR Mehmet

[triller-telekom]

@htreu and me have just discussed a view thoughts regarding the role based access and we have summarized our results in the google document. @splatch Can you please accept my changes? THX.

[splatch]

@triller-telekom I appended your section and placed two additional comments. Please take a look on them.

[marziman]

Hi @htreu & @triller-telekom and @splatch ,

did you actually take a look on the document @HeikoScholtes provided as zip file? Can we please try to pick up all sources of requirements and ideas and not only focus on the Google Docs document? Please make sure to orchestrate all inputs. If no one does this, we can take that over. But we should highly try to find the "overlapping" and "common" approaches and afterwards the spots, which maybe one party didnt have in mind.

Thanks & BR Mehmet

[splatch]

@marziman Yes, I have discussed with @HeikoScholtes his document last week. So far it is not yet clear if ESH will implement OAuth provider interface.

From requirements point of view there will be necessity to let run multiple authentication providers supporting given type of credentials and try all until first success while user login. So when first provider fails to validate credentials second still may confirm his identity.

[triller-telekom]

Yes, we did have a look at the document in the zip file.

What I do not like about it is the whole cloud based approach. ESH is meant to be a framework that runs locally in your home. if a solution that is based on ESH decides to add a cloud component, fine. But then it also has to implement everything it needs for this. In the openHAB2 case we have sketched an idea on how to do that.

All authentication and permission checks should be done by the framework inside ESH and not in a cloud service somewhere.

So from the document I would favor the "server only scenario" and do not see any problems with the mentioned "cons", see our examples in the google docs document regarding the openHAB2 cloud access.

[marziman]

Hi,

I think we should be more open minded with that one. If all parties want that ESH is more used in products and can be a solid base with good AuthN AuthZ, it needs to support and also make "cloud based" Auth mechanisms possible. Lets please not fall into dogma at this topic, since we will end with a Auth concept which will only run with ESH based standalone, cloudless solutions. That ESH supports OAuth is a must from my point of view, since it is used in so many usecases as defacto standard. And if we take a look at it from an objective view, this was a) proposed several times from community people, which we shouldnt ignore in this project since it is OSS and not driven by one dedicated party b) and going without OAuth will limit ESH to "server only scenario" which ignores remote access and other things, which obviously needs security controls, too.

I dont agree fully with this one sided approach "All authentication and permission checks should be done by the framework inside ESH and not in a cloud service somewhere", which makes ESH restricted to a "only at home" usable framework. ESH should rather make the most popular Auth mechanisms possible to implement. And this would also include a way, that a cloud serves certain security features. I dont want to be dogmatic and I am fine if the ESH project people will insist on the "only by ESH" apporach. But I would really propose that there are the mechanisms in ESH placed to make the ESH Auth cloud compatible and ease that for people willing to use ESH in a scenario where a cloud also plays a role. So what speaks against it to forsee this mechanisms?

As I mentioned, I dont think looking at ESH as "only at home" framework will help for the future of new use cases, which will definitely involve clouds too.

[triller-telekom]

@marziman I think you are mixing 2 things up here:

One is authentication, i.e. verifying a users identity and the other one is authorization, i.e. executing permission checks.

Authentication might ALSO (not only) be done in a cloud via OAuth2, but the permissions should be stored and checked by the local ESH server.

[splatch]

@marziman @triller-telekom I think we can agree on technical things without diving into philosophical aspects of our work. :-) Lets focus and define software provider interfaces required for involved parties to implement their solutions and make sure that they are vendor or use case neutral.

From above messages I can clearly see there is necessity to define a user and permission store interfaces (regardless of their form at this moment) which will cover aspects related to authorization as well as identity management.

[kaikreuzer]

Hi all,

Sorry to reply so late, but both @JochenHiller and myself have been sick / on vacation / both over the past week and I had to catch up with a lot of stuff.

So first of all thanks @splatch and @HeikoScholtes for sharing your documents, I think both are very good and a perfect start for the further discussions. I have added a few comments on the Google doc, but also read the PDF from Heiko. @HeikoScholtes We urgently need to agree on the vocabulary for the "cloud-based access": You call it "offline", but in our world "offline" means the local instance is offline and thus there is no cloud-access. I'd assume you rather wanted to call it "offsite"? Probably better to stick with "cloud". Wrt the content of your document: This is something where we really need to involve @JochenHiller as he designed and solved all such issues already once - he's my admired expert on all things OAuth (and many other things) 😉 .

if the ESH project people will insist on the "only by ESH" apporach

No worries, @marziman, not at all :-)

I very much second @splatch's suggestion to really focus for the start on the interfaces that we might need and leave implementation topics (and the decision which implementations might be in ESH and which are left to the solution providers) out of the game for the beginning. Wrt the interfaces, I would like to point at all the work that has already been done a year ago and which resulted in the ESH Auth interfaces that are to be found at https://github.com/eclipse/smarthome/tree/master/bundles/core/org.eclipse.smarthome.core/src/main/java/org/eclipse/smarthome/core/auth. Besides defining nice interfaces, we should nonetheless also check the feasibility of it all and do some POC along the way - after all I miserably failed the last time when trying to use the pretty simple and straight forward interfaces that we have now with the simplest implementation (BasicAuth) that one can imagine...

[marziman]

Hi @kaikreuzer,

I suggest to make a call or a kind of meeting regarding this topic. All interested ppl (Heiko, Lukasz ++ etc.) can join the call. There we can speak about the vocabulary and the first concrete steps. I hope @JochenHiller can join too, so we can also speak about OAuth among other topics, related to this high priority topic.

Lets please not wair too long and try to schedule it soon. Can you @kaikreuzer be the host of that call.

Thanks a lot! BR Mehmet

[jmsjones]

First off I would like to thank everyone who has been involved with this topic. It is obvious that everyone is passionate about making sure this core functionality meets all needs. IMHO we need to redirect the conversation around a more rigid development life cycle.

1. Discuss use cases / Define usability requirements
2. Define functional requirements based on the usability requirements
3. Define the software architecture to satisfy the functional requirements
4. Implement core software components
5. Create or update related software if required (UIs, auth providers)

The focus right now needs to be completing steps one and two. We cannot properly evaluate software architecture options until we have a list of requirements to judge against. I have tried reviewing the information presented so far and condensing it into a single list. Please review the list, point out any missing use cases, provide feedback on my notes, and determine whether or not you believe each item is a requirement.

Use case / Usability requirement	Notes	Functional requirement
Users can be restricted from accessing certain sitemaps, items, things, rules, etc..		Authorization handler must be able to filter resources.
Able to assigned restrictions based on type/tag e.g. do not grant access to any item that is tagged as "security".		Authorization system must have access to all properties of the resource.
If a user does not have rights to a sitemap then /rest/sitemaps should not even list it.		Authorization handler must be able to filter resources.
Rules could be regarded to be executed on behalf of the user that changed the state of an item triggering the rule.	I believe that this introduces a number of potential issues and should not be mandatory. We might want to consider tracking user information with events which the rule could access. We can also consider allowing rules to implement impersonation.	?
Users can log in with basic username and password.		Support local authentication providers.
Users can log in with Google account or other OAuth2 provider.		Support external authentication providers.
It would also be nice to open up a guest mode if you are connected locally but not expose that externally.		Authorization handler must have access to information about the user connection.
IP range checks		Authorization handler must have access to information about the user connection.
Potential: Addons/bundles/extensions may need to be secured.	More definition needed.	?
Users should be able to continue running in the fully open mode that exists today if they chose to do so.		The system should default to allowing all actions.
Potential: Users might want to configure access based on users groups.	I believe this is the responsibility of the specific authorization handler and does not impact the core code.	?
Users need to be able to log into standard UIs (Paper, Basic, Classic, Console).		?
A user may be restricted to only commanding an item during certain times of the day.	I believe this is the responsibility of the specific authorization handler and does not impact the core code.	X
A user may have a quantitative restriction on commanding an item. For example not being able to set a dimmer higher than 70%.	There are two interpretations of this. 1) An attempt to send a command of > 70% will be denied. 2) A command greater than 70% will be changed to 70%.	Potential: Authorization handler must be able to modify requested actions.
Users need to be able to log in using the OH Cloud.	I believe this is the responsibility of the specific authorization handler and does not impact the core code.	X
Users need to be able to log in via the local network even if the OH Cloud is not available.	I believe this is the responsibility of the specific authorization handler and does not impact the core code.	X
Potential: User access to configuring resources and system can be controlled.	It is not realistic for ESH to control access to text file based configuration.	Authorization handler must be able to intercept configuration actions.
Potential: Users can be restricted to accessing only certain properties of a resource. Such a the tags or parent groups of an item.		Options: 1) Authorization requests take place at the property level. 2) The authorization handler can remove properties from the data.

[kirantpatil]

We should also look upon adding DB support to ESH https://github.com/eclipse/smarthome/pull/2081#issuecomment-304440897, so that all username, passwords can be stored in local db. Any thoughts about it ?

[jmsjones]

The data from the requirements table in my previous comment has been moved into the Google Doc. I have also made a number of formatting changes to the document. Please review the document and provide comments on the requirements.

[jmsjones]

@marziman & @HeikoScholtes

I am an OH user, but not an OH Cloud user. This caused a gap in background information for me when I reviewed your document previous (zip file). I spent some time today going over the documentation and source code for OH Cloud and the OH Cloud Connector. I then went back through your document. I believe your document does a good job of describing what you are looking for and I believe it is doable. Much of the document is focused on implementation details which will be useful during the architecture phase. I am requesting that we try to focus on requirements definition right now. With that in mind, I tried to extract the use cases from your document and add them to the "Usability Requirements & Use Cases" section of the Google Doc. Can you review that list to be sure all of your use cases are covered, and provide comments as necessary? Thank you.

[HeikoScholtes]

@jmsjones thank you very much for incorporating the requirements from our original document into the main document. From my side, all aspects are covered and the cloud part is considered 👍 Thank you very much for the great work so far!!!

[jmsjones]

@kirantpatil, A number of ESH components already store data using JsonDB. I believe this same concept could be leveraged for credential storage, and should be evaluated before bringing in other dependencies. Thanks for the suggestion!

[marziman]

Hi @jmsjones ,

really great job! Looks really good and I think we have now all in place to use the document in a video/phone call to nail down the first steps and priorities. So my proposal is:

• Lets agree on an open for all Hangouts session slot (at least @kaikreuzer, @JochenHiller , @HeikoScholtes , @splatch and you @jmsjones ) should join to have the overall parties involved.
• @jmsjones can you propose a rough agenda for the session, so we dont loose each other in details (if no, we can take that over)
• Target: Lets try to nail down all the needed requirments (especially those touching ESH core) to move on and go into the next phase (in your wording 2.) & 3.) )

How do you think about this? I really prefer to get this on table, as long it is all fresh in our minds. A year later it will get more difficult..and unfortunately this happens often in OSS discussions.

Looking forward to the feedback of all here..

BR Mehmet

[jmsjones]

I made some updates to the document today:

• All requirements that I believe were clearly requested and defined have been marked as "Accepted"
• I added some notes and comments to existing requirements
• I added new requirements to better capture certain items
• I added a list of resources that I believe will require some form of permissions
• All requirements that are not marked as "Accepted" are now highlighted yellow

I would like everyone to do a couple things:

• Review the highlighted requirements (including and existing comments) and provide any feedback you can
• Review the section "Considerations > Discussions" and see if anything stands out as needing to be converted into a requirement

I think we have nearly completed the requirements definition of this process and can move onto architectural design very soon.

@marziman, I am willing to participate in a call if everyone agrees that it is the best next step. However, I would like to give everyone a couple days to provide the feedback listed above before doing so. Once the last few open requirements are clarified and resolved we can move right into design, hopefully within the next week.

[marziman]

Ok Thanks! I will take a look tomorrow. We planed a call for Thursday 15.02., 16:00 (German time). If you have time, feel free to join. I hope it is not to much difference to your timezone. It was hard to schedule that meeting for Thursday due to availability, so I think we will have several rounds and that meeting should def. happen. It is a first step..

I will give feedback regarding your improvements, these days.

Thx & BR Mehmet

[jmsjones]

That will be 10:00 for me so it is questionable if I can make it work. Please send me the details and I will join if I can.

[antoniosv]

Hi! I am new here. I study security at school (mainly cryptography but I have an interest in software security). openHAB and ESH seem interesting and fun, and I would like to help out! I've added some comments in the Google doc, and I hope they are relevant. I also looked at the document in the ZIP, but I was wondering if these two could be merged so they don't overlap or conflict? I've been considering writing misuse cases to add to this document. I will try my hand at them and then add my suggestions to the document if it goes well.
Antonio

[splatch]

Hey @antoniosv,

I study security at school (mainly cryptography but I have an interest in software security). openHAB and ESH seem interesting and fun, and I would like to help out! I've added some comments in the Google doc, and I hope they are relevant. I also looked at the document in the ZIP, but I was wondering if these two could be merged so they don't overlap or conflict?

All comments are welcome, I reviewed them and commented on some. Distinguishing of "control" level for resources is something we need to discuss and I think the best would be to do that during call. Documents have been merged so they do not overlap and all requirements necessary from OpenHab cloud perspective been included in discussion. We would like to focus on providing necessary infrastructure in ESH for implementing required kinds of authentication and authorisation mechanisms.

[antoniosv]

Thank you for your feedback @splatch! I have not yet caught up to understanding the architecture of ESH (I would appreciate any pointers). Thus, for now I could contribute to the more abstract discussion (e.g., deciding between employing cookies or JSON Web Tokens as a session ID). If possible, I would like to be present in this call. I might not be able to contribute much due to me being very new with this project, but a start is a start, I suppose.

Antonio

[splatch]

Invitation for tomorrow call: https://calendar.google.com/event?action=TEMPLATE&tmeid=NXZ0cWZqOGZpZ2M4bjM5c2RnazU5aTE2OHIgbHVrYXN6LmR5d2lja2lAbQ&tmsrc=lukasz.dywicki%40gmail.com

ical for these who would like to join but do not use google calendar: http://dywicki.pl/iCal-20180214-122443.ics

[maggu2810]

Sorry, due to the lack of time (currently a continual impediment) I cannot participate. I will try to find some time to read the documents.

[JochenHiller]

All: I commented to the Google Docs about the requirements and architecture proposal.

My overall feedback to that spec: Thanks to all contributors, I think it is a very good starting point.

During the call for today, I think we should focus (and hopefully agree) on the core requirements and core concepts about the proposed security approach.

I derived from the document these core requirements and concepts:

• separation of authentication and authorization
• separation of authorization enforcement and authorization implementation
• we should provide a simple implementation as default, which might be part of ESH, and used by openHAB
• ESH / openHAB UIs (iOS, Android, Basic, Paper) should support the simple model out of the box
• we should have a more sophisticated solution in mind, with advanced configuration possibilities (hierarchies, delegation models, use of resource properties, ...)
• authentication should be possible locally (like today) and via the cloud (eg. my.openhab.org)
• external Identity Providers should be supported (e.g. Google Account, Facebook).
  • Technically this means supporting external OpenID providers in the cloud, not possible for local access
• OAuth2 should be considered as core mechanism to separate between authentication and authorization
  • We can support a local OAuth2 provider and also an OAuth2 provider in the cloud (as part of my.openhab.org)
  • The cloud OAuth2 provider can support also external OpenID providers
  • We need to add the authenticated identity within a OAuth2 token (normally JSON WebToken will be used for that, where the user identity can be put into)
  • Authorization enforcement for access to resources can be done based on identity as part of the token

Unclear points for me:

• How fine granular should the authorization be designed? Fine granularity drives complexity
• How to align this authorization concept with more static-alike Java security model based on Java permissions? (I would not propose to follow the JAAS standard, as this adds too much complexity, with less benefits on implementation)
• The current spec uses mostly user/groups. I think we should follow better a Role based approach (RBAC) or an Attribute based approach (ABAC) (see https://en.wikipedia.org/wiki/Role-based_access_control)
  • This should be sorted out better in spec. Does this have an implication on API for authorization enforcement?

Looking forward for the call this afternoon.