Open IoT Summit North America

This post was originally published on the Predix Developer Network Blog.

I had the privilege of attending the Open IoT Summit NA recently. It was a developer conference held in Portland, OR and co-located with the Embedded Linux Conference. Before I discuss the conference and open-source software at GE Digital though, let’s review basic application security.

Application Security

#!/bin/pseudo
IF user is employee THEN
show employee entrance
ELSE
show visitor lounge

Many applications have requirements to provide secret functionality that only an administrator can use. A naive approach to solving this type of problem is to sprinkle some conditionals like the above to bounce any unauthorized users out. So where Authentication answers the question of “are you who you say you are”, Authorization answers the question of “are you allowed to do that”.

It works, is simple and effective… until you need to scale your privileges system.

Relationships Can Get Complicated

A system with a high-level of difficulty is complicated. Storing user credentials with a base64 encoding scheme transferred over a TLS connection sounds complicated. A system with many components however is complex though any part of that system on its own may be straightforward. All GE Field Engineers or Foo Subcontractors have read access to GE manufactured wind turbines in the Turbine Service Dashboard at Bar Wind Farms during weekdays 9–5. Foo subcontractors may also write data to the Asset Service but only for the pilot project in the Springfield location for the next 6 months. Many industrial settings are large complicated environments with a complex set of relationships.

This is where the Access Control Service comes in.

Access Control Service (ACS)

The Access Control Service has a unique characteristic when compared with some of the other Predix Services. Not only was it created at GE Digital, it has also been released under an Open Source Apache 2 license. You can download, read the source, fork and contribute to the project.

What’s it do?

Take the following hypothetical business requirement:

Users of APM in the role of Controls Engineer based in CA can view assets manufactured by GE at CA sites, but not sites in OR

How do we parse this sentence? We have a subject (a user) who is trying to access a resource (an asset). The subject has attributes (role=Controls Engineer, location=CA) and the resource has attributes (manufacturer=GE, location=CA). This is a requirement for the APM application. A Role-Based Access Control (RBAC) system is not always sufficient because roles may be location specific. That’s where fine-grained access control such as with ACS has value.

Once these attributes are defined in ACS, we can evaluate a policy-set that makes a decision (PERMIT, DENY) as to what action (GET, PUT, POST, DELETE) can be taken by a subject on a given resource.

Since ACS is a microservice these attribute settings are:

  • decoupled from your application
  • shareable across multiple applications
  • distributed for high-availability in the cloud

You don’t need to reinvent the wheel or the engine for that matter, use ACS as your Policy Evaluation Engine and even with a simple case, as your requirements change you will already have a solution that is robust and scaleable from the beginning.

How to do it?

Step 1: Create the service instance

You need to create an instance in your Cloud Foundry org/space.

cf create-service predix-acs beta demo-acs
cf create-service-key demo-acs demo-acs
cf service-key demo-acs demo-acs

With the service-key this gives you some important details like the Predix-Zone-Id and URI you need for the following steps.

{ “uri”: “https://predix-acs-beta.run.aws-usw02-pr.ice.predix.io”, “zone”: { “http-header-name”: “Predix-Zone-Id”, “http-header-value”: ”abc-guid-123”, “oauth-scope”: “predix-acs.zones.abc-guid-123.user” }

Step 2: Authorize client in UAA to talk to ACS

When you GET the UAA token for your client id (used by your application), you want to insure you have read/write access to attributes and policies so that you can make changes. These coarse-grained OAuth 2.0 scopes if you GET /oauth/token would then look like the following example:

{
"access_token": ”token",
"token_type": "bearer",
"expires_in": 43199,
"scope": "acs.policies.read acs.policies.write
acs.attributes.read acs.attributes.write
predix-acs.zones.abc-guid-123.user
uaa.resource uaa.none openid",
"jti": ”1234567890”
}

Step 3: Make service calls to ACS to create attributes

Now you can go to work — create subjects, resources, and policy-sets to fit your application’s needs. The headers include the access token we got from UAA in Step 2 and the Predix-Zone-Id we got from our cf service-key call in Step 1.

PUT /v1/subject/evangelist
Authorization: bearer ${access_token}
Accept: application/json
Content-Type: application/json
Predix-Zone-Id: abc-guid-123
{
“subjectIdentifier”: “evangelist”,
“attributes”: [
{
“issuer”: “https://acs.predix.io”,
“name”: “role”,
“value”: “Developer Evangelist”
}
]
}

The ACS feature set includes a number of ways to manage your attributes.

  • Hierarchical attributes to maximize reuse of attributes
  • Scoped attributes to limit the scope of applying a given policy when certain asset attributes are present
  • Attribute connectors to discover attributes from external data repositories

Check out the official documentation to learn more about these concepts and features.

Step 4: Make service calls to ACS to manage policies

As with attributes there is some core functionality for dealing with policy management.

  • Policy evaluation engine
  • Multiple policy sets

Here is an example policy-set for assets that evangelists need to access for an asset.

PUT /v1/policy-set/default
Authorization: bearer ${access_token}
{ “name”: “default”,
“policies”: [
“name”: “Evangelists can access assets”,
“target”: {
“resource”: {
"name": "asset",
"uriTemplate": "/assets/{asset_id}"
}
“action”: “GET”
“subject”: { … }
},
“conditions”: [{
“name”: “is an evangelist”,
“condition”: “match.single(subject.attributes(
‘https://acs.predix.io’, ‘role’),
‘Developer Evangelist’)”
}],
“effect”: “PERMIT”
]
}

Step 5: Evaluate the policy

The final step is what originates from your application when making any authorization decisions — a query to identify whether or not a given subject is allowed to perform a given action on a specific resource.

POST /v1/policy-evaluation
Authorization: bearer ${access_token}
{
“action”: “GET”,
“resourceIdentifier”: “/asset/12”
“subjectIdentifier”: “j12y”
}

If the response is ‘DENY’ then you can gate the functionality in your application.

Open Source at GE Digital

Now that you know a bit more about how ACS works you may be wondering — why did GE Digital decide to open-source a Predix service? Is this a trend to contributing more open-source projects? What open-source software is used in ACS?

Great questions, let’s start with the User Account and Authentication Service (UAA).

UAA

You can categorize engineering personalities into makers and breakers. The makers are really good at picking up components and wiring them together to create something new. The breakers on the other hand, well, they look at something that exists and figure out how to take it apart to see how it works. Both are critical contributions to making a rock-solid platform.

We have cyber-security professionals who have found value in being able to review and understand software components such as Cloud Foundry UAA. If a vulnerability is detected from simply scanning through the source code — there is a governance process in place to report and submit patches to harden those systems.

The value works both-ways, by open-sourcing projects like ACS we can invite security professionals to make sure the software is correct.

Architecture

Projects like ACS depend on other open-source projects so it makes sense to give back. To name a few examples:

  • Spring Boot
  • Groovy
  • Titan DB
  • Apache Cassandra
  • Apache TinkerPop
  • Gremlin
  • Redis
  • Cloud Foundry

Open IoT Summit

I thought I’d share a few of my favorite things from the conferences to wrap up.

  • Linus Torvalds in the opening keynote discussion
  • Yocto’s growth as a build system for embedded linux distribution
  • Portland neighborhoods and businesses (ie. voodoo & blue star donuts)
  • Intel Hackathon and speakers sharing their knowledge
  • Meeting up with Predix Builder Influencer Chris Anderson and his Bullitt
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.