30 April 2014

Power IoT Offline Authentication With OpenIDM

The Internet of Things (IoT) is an exciting buzz, for the many collections of previously dumb devices that are now gaining 'smart' status and increased network connectivity.  Whilst there is an increasing rush to make everything connected, not all egres devices can be on line all the time.

Many IoT devices are small, even compared to the smallest of smart phones.  Many have limited memory, processing power and networking capability.  This can reduce the ability of the device, to interact with central authentication and authorization services over common approaches such as HTTP and REST.

Challenges

Without connectivity to a central source, how do devices authenticate users, services and other devices or perform policy enforcement point style use cases?  The requirement for offline capabilities forces many to look at cumbersome out of band syncing or caching approaches.

JSON Web Tokens

Asymmetric cryptographic solutions have been around for years and can provide many encryption and signing approaches when it comes to data in transit or authentication assertions.  The federation protocol SAML2 relies on PKI crypto heavily.  But how can this help in the brave new world of IoT? JSON Web Tokens (JWT) - or jots - can provide a lightweight signed payload that can be verified by an offline device, without the need for runtime communication to a central source.  A JWT signed with the private key of a device can contain things like the public key of the identity requiring access as well as any other claims, expiration timestamps and audience attributes.  These signed assertions can be quickly provisioned, stored and then presented by users and devices in order to gain access to an offline resource or machine.

(For further information on JWT see - http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html)

The creation of a JWT in this use case would require a few pieces of information.  Firstly the payload - this is likely to contain the public key of the user, service or thing wanting access (this is used later in the authentication process during a challenge/response style interaction), an expiration time (Unix timestamp), an aud (or audience) attribute (which advertises who the JWT is for) and any other potential attributes used as claims.

The payload is then signed with a private key, using information from the JWT header, which contains algorithm details.  The result, is a dot-separated three valued encoded string.



Integrating With OpenIDM

The power of OpenIDM is it's simplicity and speed, with which new services and endpoints can be integrated into it's core engine.  OpenIDM uses the omnipresent web language of Javascript to provide logic and processing capabilities that can be created or extended.  A simple custom REST endpoint - a web URL containing static data or dynamic processing capabilities - can be setup in a few hours, that can provide the ability to provision JWTs instead of the standard provisioning use case of permissions such as groups or roles.

The custom endpoint is simply a Javascript file of 100 or so lines, that contains some open source Javascript crypto libs to help sign and manage the JWT, as well as some simple OpenIDM actions to update managed objects and perform retrievals of objects in OpenDJ.  The end result is a JWT that is provisioned against the object stored in OpenIDM as well as either provisioning of that attribute to a downstream system (if for example you want to push the JWT to an API or device distribution service) or simply into OpenDJ.

Once the end user or device has collected the JWT, they can then present the JWT to the device they wish to access in an offline manner.  The authenticating device doesn't need to have HTTP access.  It can simply use local crypto to verify the signature of the JWT, and create a challenge response using the public key of the subject, that is already contained inside the JWT payload.  A successful challenge response process would require the subject presenting the JWT to have the corresponding private key, so is a nice mix of multifactor something their have authentication.

I'll shortly release the code to Github as a community contribution.