Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for conditional access based on user role #579

Open
kaikreuzer opened this issue Dec 3, 2015 · 129 comments

Comments

@kaikreuzer
Copy link
Member

commented Dec 3, 2015

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?

@GradyD

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2016

I'd like to see a way to use my google account, so support for external OAuth2 providers.

It would also be nice to open up a guest mode if you are connected locally but not expose that externally.

@ozel

This comment has been minimized.

Copy link

commented Jan 25, 2016

+1 for Global access control as it is done in openHAB. we want to use openhab2 in an organization-wide newtork do to show control for visit points and exhibitions.

@kaikreuzer

This comment has been minimized.

Copy link
Member Author

commented Jan 26, 2016

@ozel Does that mean your are volunteering for implementing it? :-)

@ozel

This comment has been minimized.

Copy link

commented Feb 17, 2016

@kaikreuzer sorry, that's way out of my skills. I come from an embedded C world with precicely defined typing etc. and struggle a lot these days in just getting my openHab java rules working relibaly... However, I follow https://community.openhab.org/t/authentication-in-oh2/1723/24 and as soon as there's something to test I'll volunteer for that

@splatch

This comment has been minimized.

Copy link
Contributor

commented Apr 19, 2016

Some time ago in my fork I added few classes which could potentialy cover authentication support in ESH. Main purpose is to avoid any specific framework for handling that and letting vendors customize with their own choice. For this reason even JAAS is not enforced, however could be used to implement basic login.

Linked commit introduces following structures:

  • Authentication which represents information about user and assigned roles (generaly speaking). This is simplest model which could be a starting point to more advanced policies which could let users controls who can interact with specific items.
  • Credentials - generic purpose structure which can hold data needed to obtain authentication. One type of this might be UsernamePassword, another ie. OAuth token.
  • AuthenticationProvider element responsible for verifying given Credentials and returning Authentication in case of successful login process.
  • LoginResource - a dummy implementation of login resource which could be used from user interface level.

In perfect world internal code should utilize Authentication object to calculate access and visibility to items, that's why I put all auth-related stuff in core bundle. Authentication object should be also kept in HTTP session to avoid resending credentials with every requests (to deny usage of basic/digest scheme).

@digitaldan

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 2016

@splatch do you know how would this be enforced in the addons/bundles? I was playing around with implementing simple http based auth this morning. The only way I could successfully do this in a standard way was to create a custom HttpContext object that implements the "handleSecurity" function.

My knowledge of OSGI dependency injection is zero, it would be nice if the call to the "createDefaultHttpContext()" which all bindings with rest endpoints seem to use would return a context that does authentication (and could redirect to your bundle)

@kaikreuzer

This comment has been minimized.

Copy link
Member Author

commented Apr 25, 2016

@splatch Your concept looks good to me, I think it is a good starting point for tackling this feature - so feel free to create a PR with it and a basic implementation of the providers and resources.

@digitaldan I think nothing speaks against introducing a custom HttpContext that we could provide as a service to all our JAX-RS resources and servlets. The "defaultHttpContext" could still stay the current one which does not require any authentication (we will still need this, e.g. for providing communication endpoints for UPnP, the hue emulator, etc.

@digitaldan

This comment has been minimized.

Copy link
Contributor

commented Apr 27, 2016

@kaikreuzer sounds good to me. @splatch can't wait to see a simple implementation of this!

@splatch

This comment has been minimized.

Copy link
Contributor

commented May 6, 2016

@digitaldan @kaikreuzer We will need custom http context anyway, over which we could delegate security checks to underlying Authorization mechanism and verify if access is granted or not. Feel free to add PR with custom context anyway.

@kaikreuzer

This comment has been minimized.

Copy link
Member Author

commented May 6, 2016

Feel free to add PR with custom context anyway.

PR to where? I thought we are currently waiting for a PR by you here first?

@splatch

This comment has been minimized.

Copy link
Contributor

commented May 6, 2016

PR to where? I thought we are currently waiting for a PR by you here first?

I will start putting all things together around infrastructure, any help with surroundings is welcome. Maybe @digitaldan will be able to base his PR upon my changes.

@digitaldan

This comment has been minimized.

Copy link
Contributor

commented May 7, 2016

The HttpContext object is easy:

public class AuthenticatedHttpContext implements HttpContext {

    @Override
    public boolean handleSecurity(HttpServletRequest request, HttpServletResponse response) throws IOException {
        response.sendError(HttpServletResponse.SC_UNAUTHORIZED);
        return false;
    }

    @Override
    public URL getResource(String name) {
        return null;
    }

    @Override
    public String getMimeType(String name) {
        return null;
    }
}

If we want to go this way,

  1. what package should this live in, maybe org.eclipse.smarthome.io.rest or org.eclipse.smarthome.core.auth?
  2. how should this look up a registered authentication provider and call it inside handleSecurity?
  3. this would mean we need to modify all existing bindings to use/import this new class..... is there a better way?

This approach make me a little uneasy b/c there is no global policy and I would hate to expose services accidentally, but I don't think OSGI will allow any other way.

@kaikreuzer

This comment has been minimized.

Copy link
Member Author

commented May 8, 2016

  1. org.eclipse.smarthome.core.auth sounds good to me as it not only applies to the rest interface.
  2. Could AuthenticatedHttpContext simply be a service itself (then the auth provider would simply be a mandatory static dependency)?
  3. This is imho ok, but I agree that the risk to miss something (e.g. in extensions) is not nice. It would be great to be able to somehow inject this context into httpService.createDefaultHttpContext() - but this is probably only possible through very dirty hacks.
@splatch

This comment has been minimized.

Copy link
Contributor

commented May 8, 2016

  1. This is imho ok, but I agree that the risk to miss something (e.g. in extensions) is not nice. It would be great to be able to somehow inject this context into httpService.createDefaultHttpContext() - but this is probably only possible through very dirty hacks.

I didn't read eclipsesource jaxrs source code too deep, however there is an example with their own security layer which requires registration of AuthenticationHandler and AuthorizationHandler: security example.

@kaikreuzer

This comment has been minimized.

Copy link
Member Author

commented May 8, 2016

Correct, but this will only cover the REST API, but not any other servlet that might be registered by an extension.

@neverend92

This comment has been minimized.

Copy link

commented May 23, 2016

Hello together,
I'm also working on your approach while writing my master thesis at university.
At the moment I'm trying to understand parts of the OpenHab/ESH Code and got stuck at the point the *.items files where read.

I noticed that at this point xtext is used to parse these files, my question is how to setup my eclipse ide to make changes to the xtext files (e.g. to add a user role/group) to the items. I already installed xtext and imported the missing projects, but they are full of errors (missing references, etc.) and once I include them in the run configuration OpenHab starts throwing exceptions. How can this be fixed?

Thanks in advance.

@maggu2810

This comment has been minimized.

Copy link
Contributor

commented May 23, 2016

@neverend92 I don't think your question is really related to this issue. You ask how to setup the IDE (if I understand your comment correctly). For ESH install the Eclipse IDE as described in the ESH documentation and you should be able to change the xtext files (and see the result).
For openHAB IDE use the openHAB community board.

@neverend92

This comment has been minimized.

Copy link

commented May 23, 2016

Alright sorry for that, I will ask for help with this problem at the openHAB community board...

But then I want to ask you all if the approach to extend the *.items configuration files by user groups, etc. is good. Or if there is a better way to connect items and access control?

@maggu2810

This comment has been minimized.

Copy link
Contributor

commented May 23, 2016

I don't know if there has been already some decisions how fine granular the access control should be defined (e.g. REST API access in general, things, channels, items, ...).
I don't think it make sense to start with the *.items configuration as long as I can use the REST API to create another item that links to the same channel...

@digitaldan

This comment has been minimized.

Copy link
Contributor

commented May 23, 2016

Could AuthenticatedHttpContext simply be a service itself

@kaikreuzer are you thinking it would be a service in an existing bundle, or be its own standalone bundle?

@kaikreuzer

This comment has been minimized.

Copy link
Member Author

commented May 23, 2016

I think it must be a part of the core, just as it is done in here.

@marziman

This comment has been minimized.

Copy link

commented May 24, 2016

Why do we want to create Security concepts / Models by our own. Lets use a framework?
@splatch , @digitaldan and @kaikreuzer
What speaks against Apache Shiro (http://shiro.apache.org/) ?
We may put shiro into a single bundle which than exports a SecurityManager as an OSGI service (other bindings could import and use it). It also fits well to Karaf...
as I remember from my investigations for Authentication, there is a Karaf feature for OSGi integration. Shiro has easy API's for authentication, authorization, cryptography, and session management + can be deployed inside a OSGI container
Not sure how thin shiro is, but its worth to check it out..

@digitaldan

This comment has been minimized.

Copy link
Contributor

commented May 24, 2016

Thank @marziman , I'll take a look at Shiro, have not used it in the past, it would be great not to reinvent the wheel, especially with security.

@kaikreuzer

This comment has been minimized.

Copy link
Member Author

commented May 24, 2016

@marziman I came across Shiro quite a while ago and thought that this could be interesting. So I agree that we should have a closer look. I so far cannot judge how well it integrates with Pax-Web, Java-servlets and Jersey.

@splatch

This comment has been minimized.

Copy link
Contributor

commented May 24, 2016

Why do we want to create Security concepts / Models by our own. Lets use a framework?

My main concern on that is bringing external dependency to our more or less dependency less core artifacts. That's why I based on very similar basis as security frameworks so they could be wired in when needed. It was not intented to build everything from scrach but rather adapt existing solution in the way that anyone have freedom of choice.

it would be great not to reinvent the wheel, especially with security.

Currently in Java land there is no security standard other than JAAS. This is the simplest thing we could have, however it brings it's own set of troubles. Anything else than JAAS is in fact - reiventing the wheel. If you will take a look on all security frameworks made in Java - starting from Acegi over Spring Security up to Shiro - they all claim to provide comprehensive security framework. But if Acegi would do it properly in first place I think nobody else would start Shiro. And I'm pretty sure there are other implementations which yet we don't know. This is double edged sword.

@marziman

This comment has been minimized.

Copy link

commented May 24, 2016

@splatch,
I think your Security Idea is good and appretiate your concept.
But we really should investigate first. Iam not dogmatic and dont want to force it. I just got the feeling that this Framework will be good for our requirements. I had no time to make a prototype or sth. like that to say anything about ext. dependencies, but we may think about NOT putting it into the core and making a standalone SecurityManager bundle. We could bring it later to the core, too. Your concerns are valid, so if we know we have 2 or more Security Frameworks we want to make usable, than we could create a more general OH Interface abstracting this by e.g. your Security concept. But for the time being I cant see that.
I would wait for @digitaldan and his feedback. Is that fine for you guys?

@digitaldan

This comment has been minimized.

Copy link
Contributor

commented May 24, 2016

Well I'm no expert on Java security (nor OSGI), I have used JAAS in the past (years and years ago) and remember fighting it constantly every time a corner case came up. I'm sure Shiro has its own "quirks" too. IMHO authentication is becoming one of the major roadblocks to users adopting OH2, so I think this is becoming more urgent to get done soon. @splatch are you still working on submitting your proposal? I would hope there would also be a simple example implementation of it as well.

@kirantpatil

This comment has been minimized.

Copy link

commented Mar 3, 2018

@kaikreuzer

This comment has been minimized.

Copy link
Member Author

commented Mar 8, 2018

Many thanks @marziman, the notes look good to me.
@splatch Will you take the lead on the next steps regarding the embedded API side?

@splatch

This comment has been minimized.

Copy link
Contributor

commented Mar 8, 2018

Hey, I been stuck in other project. Im back to life from next week. Looking forward to get back on it.

@jmsjones

This comment has been minimized.

Copy link
Contributor

commented Mar 10, 2018

I haven't had much time to commit to this lately, but I have been considering a number of implementation options. I have started adding information to the Google Doc to reflect what I view as a viable design.
The leading access control paradigm discussed so far is Role Based Access Control (RBAC). I believe Attribute Based Access Control (ABAC, also referred to as Policy Based Access Control) is a better fit for the requirements that have been established.

@marziman

This comment has been minimized.

Copy link

commented Mar 18, 2018

Hello @splatch, @kaikreuzer, @HeikoScholtes, @antoniosv & jmsjones,

can we please agree to not let this hang around? We should also avoid to add stuff to multiple documents..Just to avoid we loose good ideas and input.

Lets try to get this into a „doing“ mode instead to stay too long on theory. Simce we might need to switch approaches if we find blockers.
We will actively design and implement the ToDos on our side.

@splatch this is a small ping :-)

Hope you can find time to tackle the ESH embedded part of it, while @JochenHiller, @HeikoScholtes and me we will be more or less around cloud side (ohcloud etc.)

Thx & BR
Mehmet

@splatch

This comment has been minimized.

Copy link
Contributor

commented Mar 19, 2018

Hey Mehmet,
Thanks for reminder. I been sniffing around OSGi 4.2 issue lately (let's call it this way), and there are certain trade offs which needs to be paid.

There is no support for filter registrations in this version of specification. This means that the only way to get filters working with current smarthome environment is to register an internal proxy servlet which will dispatch requests and also provide a way to have a filter chain execution.
Even if we decide to not go with filters, there is still requirement to secure other servlets (ie. icons servlet). We need to "intercept" request for that and only one repeatable way which I know is via something like a wrapper servlet.
It is doable, but I am not sure how many rabbit holes we will get (especially with class loading). This version of specification is already 9 or at least 8 years old (September 2009/March 2010). It would be good to not tie down more modern runtimes to that old spec.

I gonna revisit current approach of servlet registration and see if we can cheat old spec to get more verve. I will do a small PoC aside of ESH to show approach and then we can decide if its applicable for project and all known runtimes.

Cheers,
Lukasz

@kaikreuzer kaikreuzer added this to To do in Backlog via automation Mar 20, 2018
@antoniosv

This comment has been minimized.

Copy link

commented Apr 4, 2018

I've been looking into how token-based authentication can be used in the OSGi architecture. I've been trying out isolated examples here and there, but due to the complexity of ESH, it's a tough cookie to put it all together. Additionally, the idea of putting in only abstractions to leave open any 3rd party implementations makes it a bit more difficult to swallow. So far as I have observed, this post's answer hits the nail to what it is intended to be accomplished here. I'll keep trying to figure a way on how to put the pieces together to make it work. Meanwhile, I have a couple of questions:

  • Why do classloading problems happen? I.e. importing packages into the MANIFEST file is not enough?
  • Why do we want to avoid using the jax-rs connector? I'm under the impression that jax-rs is needed for the REST bundle, anyway?
  • What obstacles are there for using a custom filter for the incoming http requests?

Looking at the current implementation of basic authentication (username:password in http request header), it looks like it could be extended to other types of authentication, but since this approach couldn't be used successfully for OH2, what pitfalls would need to be avoided in an alternative solution?

Thank you for your time, guys. =)

@maggu2810

This comment has been minimized.

Copy link
Contributor

commented Apr 5, 2018

As stated already in another issue I already use JWT in an ESH based product.

For the authorization and authentication I use two separate classes both implementing the ContainerRequestFilter. Both classes are annotated with Provider and use the respective Priority of Priorities.

An SecurityContext is set for the ContainerRequestContext.

I also added some utility methods and interfaces so the code that checks the privileges does not depend on the special implementation.
The methods uses the SecurityContext that is injected into the REST resource implementation class for the current handled call using the Context annotation.

So, e.g. if items should be read, I use an "AuthenticationManagerCollector" that is injected by a DS reference that implements the method:
boolean canReadItem(SecurityContext securityContext, Item item)
The collector itself is a service that collects all AuthenticationManager that provide such methods and checks if at least on allows / forbids the access.

The REST resource implementation for "get all items" can so simple filter the result for only the ones that are readable by the caller:

final Stream<EnrichedItemDTO> itemStream = getItems(type, tags).stream()
    .filter(item -> amc.canReadItem(securityContext, item))
    .map(item -> EnrichedItemDTOMapper.map(bc, item, recursive, uriInfo.getBaseUri(), locale));
@antoniosv

This comment has been minimized.

Copy link

commented Apr 5, 2018

@maggu2810 Thank you! Could you make a reference to that issue so I can take a deeper look at your approach?

@maggu2810

This comment has been minimized.

Copy link
Contributor

commented Apr 5, 2018

@antoniosv The "another issue" I talk about only contains the information that I used a JWT based implementation, it does not bring any useful information (#3113 (comment))

@antoniosv

This comment has been minimized.

Copy link

commented Apr 9, 2018

As Issue #2620 got closed, I'll repost this:

I'm having the opposite problem as @maggu2810 . I would like to be denied access to, say, rest/things/items when I use curl without the headers of basic-authentication. However, all requests go through even though the endpoint things/items is annotated by @RolesAllowed({ Role.ADMIN }).
I'm guessing that, at some point, basic authentication was disabled, but what was changed?

Edit: After much fiddling on my own, I figured out this happened because the com.eclipsesource.jaxrs.provider.security plugin was not selected from the run configuration in Eclipse.

@splatch

This comment has been minimized.

Copy link
Contributor

commented Apr 9, 2018

Hey,
Over past couple of weeks I been walking around this topic and looking for a way to remove blocking element which is lack of filter support in OSGi 4.2. Please check below document where I describe simple approach based on whiteboard pattern which will allow to host compatibilty layer for runtime used in commercial products. Such layer will not be necessary for openhab which runs on newer versions of OSGI spec:
https://docs.google.com/document/d/1zTk_GKC4QRmeu9saEfaWbvMZJJRB_ExPyOZdd2hA8vQ/edit?usp=sharing

I am aware that its quite difficult to move on with existing runtime which is used. Implementation of solution does not take a lot of code and will work with any http service implementation. All it does is just wrapping of registered servlet.
I started doing some prototype implementation which I will be able to publish in coming week (or weeks).

Cheers,
Lukasz

@splatch

This comment has been minimized.

Copy link
Contributor

commented Apr 23, 2018

Last week I spoke with @antoniosv and we made some progress. Antonio was evaluating possibility to implement basic security checks with http context. We agreed ge will continue with his work and see if it will be possible to implement JWT checks there. It seems to be easiest solution which will be portable between multiple osgi specification versions.

Inspired by his findings I started looking once again in jaxrs connector and found an element which makes possible to inject http context to wrap jersey servlet. I have no idea how I missed such nice extension point.
There is no need to add any "compatibility layer" described above, its just sufficient to implement this SPI in order to have place for "preflight" checks.

I also started checking servlet registrations in ESH and, with additional OSGi 4.2 http context injection, it is possible to share authorization logic in there. I got some basic code working but some UIs are registered in quite complicated way (comevisu, paperui, dashboard - they wrap servlet in service).
My preliminary assumption was to use base servlet to grab HttpService and HttpContext and close servlet registration in one place, however there are some implications (ie. DS annotations inheritance etc). For now - I managed to port basicui and classicui.

I will submit later PR for review because above improvements is first step in getting this issue resolved.

@marziman

This comment has been minimized.

Copy link

commented Apr 23, 2018

@antoniosv & @splatch,

lets make a meeting and discuss the new findings and synchronize.
We can also share our ideas around this topics, revisit the points from the protocol after our meeting.

Would be great and maybe a good time to check, where we stand and how to proceed to get the „must haves“.

BR Mehmet

@splatch

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 2018

Code which allows to use shared http context is in place:
https://github.com/Code-House/smarthome/commits/esh-authz2

Now we have to provide HttpContext#handleSecurity(request,response) logic. I attempted to provide support for servlet filters, however without registering own dispatcher servlet at context root(/*) it will not work. Servlet filters are dead end for now.

I will focus now on making authentication switch and some way to bridge request to authneticators.

Cheers,
Lukasz

@antoniosv

This comment has been minimized.

Copy link

commented May 3, 2018

I have written some code for the HttpContext#handleSecurity(request,response) logic. I'm making use of the Nimbus JOSE+JWT library to create and verify tokens using a RSA key. For the UI, I'm storing the JWT as a cookie. The logic I have implemented is as follows:

  1. Check if authorization header or cookie is there (if not, return forbidden)
  2. Attempt to do JWT Authentication with auth. header first: parse authorization header to get type of Authorization type. If it's Bearer type, then extract the token and verify it.
  3. If there was no token in the header, but there is a cookie present, take the cookie as token and try to verify it.
  4. If there was no cookie and the auth. header wasn't of type Bearer, fallback to Basic authentication. If successful, allow access and generate a JWT that is stored as a cookie.
  5. Further requests will have the cookie included.

It would be very nice if I could set up a login page instead of relying on Basic authentication for this.
I will try to get the code up somewhere ASAP. My code works for simple servlets, I haven't yet attempted to make it work with REST endpoints with the changes that Lukasz has been doing .

@splatch

This comment has been minimized.

Copy link
Contributor

commented May 3, 2018

Yeah, there is a need to bridge authenticators and http context, I made some scratch around that, but haven't finished it yet. I should get some plumbing done next week.

@veotax

This comment has been minimized.

Copy link

commented May 13, 2018

Personally, I recommend: jCasbin, which is an authorization library that supports models like ACL, RBAC, ABAC.

Related to RBAC, jCasbin has several advantages:

  1. roles can be cascaded, aka roles can have roles.
  2. support resource roles, so users have their roles and resource have their roles too. role = group here.
  3. the permission assignments (or policy in jCasbin's language) can be persisted in files or database.
  4. multiple models like ACL, BLP, RBAC, ABAC, RESTful are supported.

And you can even customize your own access control model, for example, mix RBAC and ABAC together by using roles and attributes at the same time. It's very flexible.

@kirantpatil

This comment has been minimized.

Copy link

commented Jul 27, 2018

Hi @splatch @marziman, any updates on this issue ?

Thanks.

splatch added a commit to Code-House/smarthome that referenced this issue Aug 13, 2018
This commit addresses issue eclipse#579. It does not solve it fully, but creates a base for security mechanism which covers main entrypoints to Eclipse SmartHome - meaning REST and other servlet based interactions such icons and charts.
@splatch

This comment has been minimized.

Copy link
Contributor

commented Aug 14, 2018

@veotax I will speak on behalf of myself, but I think ESH policy is quite simple - it does not force any specific security framework. If you would like to provide a jcasbin backed security layer (based on SPI which is in works) - you are free to do that.

@kirantpatil - I submitted for review first PR which covers infrastructure level security.

splatch added a commit to Code-House/smarthome that referenced this issue Aug 14, 2018
This commit addresses issue eclipse#579. It does not solve it fully, but creates a base for security mechanism which covers main entrypoints to Eclipse SmartHome - meaning REST and other servlet based interactions such icons and charts.

Signed-off-by: Łukasz Dywicki <luke@code-house.org>
splatch added a commit to Code-House/smarthome that referenced this issue Aug 14, 2018
This commit addresses issue eclipse#579. It does not solve it fully, but creates a base for security mechanism which covers main entrypoints to Eclipse SmartHome - meaning REST and other servlet based interactions such icons and charts.

Signed-off-by: Łukasz Dywicki <lukasz@dywicki.pl>
splatch added a commit to Code-House/smarthome that referenced this issue Aug 14, 2018
This commit addresses issue eclipse#579. It does not solve it fully, but creates a base for security mechanism which covers main entrypoints to Eclipse SmartHome - meaning REST and other servlet based interactions such icons and charts.

Signed-off-by: Łukasz Dywicki <lukasz@dywicki.pl>
@kaikreuzer kaikreuzer moved this from To do to In progress in Backlog Sep 12, 2018
@Bagunda

This comment has been minimized.

Copy link

commented Feb 8, 2019

Do we have pass authentication for general page?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Backlog
  
In progress
You can’t perform that action at this time.