Open kaikreuzer opened 8 years ago
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.
@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).
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.
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).
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).
@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.
Hi @madte,
Is CoAP binding with DTLS support available for public testing ?
Please post the source code link and instructions to test it.
Thanks.
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
@marziman See here. I am happy for anyone that is willing to pick this up!
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:
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
@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:
Any comments? Me and maybe 1-2 more colleagues would join on that. Who else would like to be involved?
@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.
@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
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.
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.
@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
@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.
@marziman sure, gimme day or two to recap on what was made and put it into gdoc.
I have been looking over this thread and the linked material and wanted to pass along some initial thoughts.
Clarifications regarding requirements
Issues
Other notes
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.
@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
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.
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
@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
@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.
@triller-telekom I appended your section and placed two additional comments. Please take a look on them.
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
@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.
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.
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.
@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.
@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.
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...
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
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.
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. |
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 ?
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.
@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.
@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!!!
@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!
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:
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
I made some updates to the document today:
I would like everyone to do a couple things:
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.
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
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.
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
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.
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
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
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.
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:
Unclear points for me:
Looking forward for the call this afternoon.
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:
On 2015-09-25 03:52:04 -0400, Kai Kreuzer wrote: