Use cases in the industrial internet often have requirements for access control that are not satisfied by standards that are prevalent in the consumer space. For example, standards like OAuth 2.0 model privileges as flat lists of coarse-grained scopes that are granted for the entire user login session. Newer standards like UMA allow for finer-grained access control but do so in ways that require more client-side complexity. Additionally, Neither of these standards define a common way to write policies or manage privileges.
Meanwhile, in the enterprise space, the XACML standard has slowly gained traction. While XACML is a comprehensive standard, our experience has proved that it is costly to implement and comes with a steep learning curve. Thus, we decided to build a service that offered a simplified and comprehensive Attribute Based Access Control (ABAC) for RESTful APIs.
The Eclipse Keti project provides an access control service that protects RESTful APIs from unauthorized access.
Keti is a service that was designed to protect RESTfuls API using Attribute Based Access Control (ABAC).
The solution itself is implemented as a cloud-native RESTful API that adheres to the guiding principles of the twelve factor app. Key characteristics of the service include:
- Central management of policies and privileges
- The ability to manage hierarchical privileges (e.g. sub-groups) and scoped privileges (e.g. assigning elevated privileges based on the resource accessed)
- A policy format tailored for developers who build RESTful APIs
- An access control decision engine
Spring Boot is the primary framework that Keti is built on. Additionally Keti uses the following open source libraries:
- Titan DB, an implementation of Apache TinkerPop, for it's graph data structure
- Jedis as a Redis client for caching
- Spring Security to protect it's API
- Spring Data JPA for persistence to RDBMS
An operator deploys Keti in the same datacenter where the web services it protects are deployed. Either a common gateway, or the web service itself, sends requests for authorized access to Keti and enforces the decision received in the response. When deployed, Keti typically has the following service dependencies.
- UAA as an OAuth server
- Redis (optional) for decision caching
- Cassandra through Titan DB for graph persistence
- PostgreSQL, or H2 as a RDBMS
Below is a basic diagram of how Keti fits in the interaction between web application and web service.
The context of this work and the resources that it will protect are related to IOT use cases. Eclipse has a nexus of IOT related projects, and companies that support them, and the Keti project fits well together with them.
The initial contribution, which will include working builds, will happen shortly after acceptance.
- Support for managing multiple policy sets
- Support for generic OAuth servers
- Support for Basic authentication
- Connectors for merging attributes from LDAP and SQL stores
Comments Sign in to post comments
Interesting
Submitted by csengul on Tue, 2016-10-25 11:01
This is definitely an interesting project - wil you be designing a new policy presentation (moving away from XACML)? Will it be more towards JSON-based request/response that was considered for XACML?
You can put me down as an interested party too.
Thanks,
-Cigdem
Interested Party
Submitted by Kai Hudalla on Tue, 2016-09-27 04:55
Please add Bosch Software Innovations GmbH as an interested party.
Thanks,
Kai
Thanks Kai for input. We will
Submitted by ilipkind on Wed, 2016-09-28 17:57
Thanks Kai for input. We will definetly do that once I have priviledges to modify the proposal.
Wishing a more detailed description
Submitted by kkreuzer on Sat, 2016-09-24 00:32
I think the proposal is very short, I would expect some more detailed information about the what and why and how.
Embedded or server only?
Submitted by kkreuzer on Sat, 2016-09-24 00:30
Does this primarily target cloud servers or is it also meant for embedded use, e.g. one gateways?
IoT or Runtime?
Submitted by jvermillard on Thu, 2016-09-22 12:00
Hi,
Looks great! Just a question: why limit it to IoT and not put it in "runtime" ? Because after taking a look at the code the scope looks broader than connected objects (a bit like jetty, which is a runtime project).
IoT or Runtime
Submitted by iskerrett on Tue, 2016-09-27 14:41
I think the suggestion for the IoT PMC was since there seems to be interest in integrating ACS with some of the other IoT projects. The RT PMC is mostly focused on OSGi technology so I don't think ACS is a perfect match either.
RT Scope
Submitted by gunnar on Tue, 2016-10-11 11:50
Ian, I think there has been enough scope creep in RT to allow non-OSGi projects? The project itself looks very applicable to anything backend-ish. Thus RT would be a fit. If, however, IoT is the target audience/primary customer then it may very well make sense to have it under IoT.
I think we should contact the
Submitted by jvermillard on Thu, 2016-09-29 08:54
I think we should contact the runtime PMC to known their view on the scope of this project.
If we follow this 'non osgi and iot project use it' logic, since most of Java Eclipse IoT project are using Jetty, we should move jetty to IoT :D
I would hope the project
Submitted by bcabe on Wed, 2016-09-28 14:22
I would hope the project plans on delivering some reference/example integrations with Eclipse IoT projects. Maybe something that should be clarified in the proposal.
I agree with Julien, this
Submitted by Kai Hudalla on Tue, 2016-09-27 04:54
I agree with Julien, this seems to have a much broader applicability than just IoT :-)
Kai