Entitlement Service API
- encrypting and signing authorization tokens (licenses) delivered to clients. Clients have a separate public key by which they can decrypt and validate authorization tokens.
- hosting a set of trusted certificates, which allows client applications to validate that the service endpoint they are interacting with is in fact the entitlement service. This prohibits setting up a “fake” entitlement service to provide positive answers to authorization checks. Client applications are built to include a public key that they use to validate the “trusted certificates” response from the Entitlement Service. This mechanism can be used in the system generally to establish trust on client side for any web service in addition to the Entitlement Service.
- https as protocol scheme
The recommended way to implement this is to define separate product packages for each client / device type, which further allows to use different license models for each.
It could also be extended to different types of content – for example, a user from a web-browser client can access 10 articles and 1 video clip while a user from a mobile device can access 10 articles and 10 video clips.
We define “pseudo roles” for users including categories:
- authenticated user
- last editor
In this scenario the “viewer” role (meaning unauthenticated user) would be allowed certain things, which may be more limited than authenticated user. One such “viewer” Entitlement configuration may define the ability to access (eg.) 3 pieces of content before the client application directs the user to a paymentwall.
A. If you deployed any of our APIs and then subsequently choose to move to another provider for whatever reason, you are not locked-in, either commercially or technically.
You own the data
Commercially, our APIs are provided on a monthly subscription basis with a one-month notice period so you have flexibility in terminated our commercial relationship. Technically, all of our APIs are standards-based and therefore it is straightforward to transition to a new provider. For example, if you wanted to move to a different Entitlement Provider, the product package definitions can all be exported from our Entitlement API and ingested into a new provider given that they support all requirements that you have. Similarly, user IDs within the Identity Provider can be moved to another Identity Provider. Each migration would involve a migration project, but this is something that we would help you with as you would like us to.
An additional benefit of our APIs that is not easily found with open-source products in the Identity and Access Management sector is expert support. Our company provides multiple support channels and packages should you need further assistance after the initial deployment. With open-source IAM projects the integration cost often far exceeds the cost of a commercial solution because disparate, point-solutions are being made to work together. By contrast, our APIs are composable services, designed from day 1 to work well with each other, integrate simply into other, standards-based systems and all stem from the same Java-based development framework, that is itself a mature product with a development guide, roadmap and support packages.
Service (using its API) to include that new package. (As an iOS app, this may be exactly the same as your existing ‘Newspaper App’ Product Package for iPhones and iPads in which case nothing would need to change, but if the ‘Newspaper App for iWatch’ product package was unique then it would need to be added as a product package). Once the entitlement rules for this new product package have been defined and configured, that it is ready to be included in the overall product set. This configuration process with take 5 to 10 minutes to do.
- You sell digital content online via a monthly subscription model.
– users can subscribe to a free account
– once subscribed they are able to access 10 pieces of content
– once they hit the 10 piece limit, they are pushed to paywall where they are required to subscribe to a paid account in order to maintain access to content.
In this scenario, our Entitlement service provides the metering on the subscribed user and tracks their usage before pushing them to the paywall. What is particularly neat is that it supports a ‘constraints-based’ model which then supports metering against a number of factors including:
- access device type: you may want to provide more content to users on iOS devices than Android devices for some business reason. Our ENT service could allow iOS users to access 20 pieces of content whereas Android users could only access 5.
- content type: you may want to provide un-subscribed users with access to 10 pieces of video content and 3 text articles. Our ENT service will support this.
- user origin: similarly, you may want to provide unsubscribed users, accessing content from the UK, with 10 pieces of video content and 10 pieces of text content before pushing them to a paywall. By contrast, users from other parts of the world can only access 3 pieces of video content and 3 pieces of text content.
- concurrency: if you need to allow a user to access the same content, but from more than one device, our ENT service supports this.
If you think of Spotify, they have a piece of software built in-house which governs which users can access Spotify’s catalogue (with or without ads) and on how many devices for each users. Our ENT service can provide exactly the same functionality out of the box.
- Selling digital content to ‘anonymous’ users
Similar to the example above, it may be the case that you have a lots of users visiting a website but you don’t know who they are. Our ENT service can still be used to apply a meter to them. The ENT service is an ‘identity-based’ Entitlement so it has the ability to gradually build up a user provide even if we don’t initially have access to their email address. The ENT service can do this initial from an IP address and then build the user profile from there. So this means:
- you can use the ENT service to provide a certain number of pieces of content to an anonymous user before pushing them to a Registration wall, after which they can then be given certain access rights to other pieces of content before being pushed to a paywall (as per example 1).
- Selling software applications on a subscription basis to one user with multiple devices.
-You selling anti-virus software.
-Each license you sell allows your customer to use the software on one PC and 2 mobile devices.
– our ENT service would govern the access of the customer to the application from each device over the defined subscription period. When that period ends, the applications on each device would no longer function without renewal.
Our solution does not require a license server to be installed on the customer site
The 10Duke Entitlement Service does not rely on license keys and therefore there is no need to issue, revoke, replace, or reconcile licenses. This mean your internal cost of license admin will be a fraction of what it is if you use Flexnet.
The 10Duke solution is ‘always on’ means that it dramatically reduces unauthorized usage of your software. Unless a user is logged in and has a valid license, they can’t use your software. Period.
If you provide a suite of application to your customers, including web, desktop and mobile apps, licenses to all of them can be configured and managed all through the 10Duke system. That is something Flexera just can’t do.
Identity Provider API
video transcoding tasks such as accepting user-uploaded videos or generating output video file to support playout on multiple devices.
audio transcoding to allow uploaded audio files to be played back on a variety of device types, regardless of format
mashing or producing composite media from several input media assets
creating thumbnail images for videos and images automatically on upload
inserting and updating metadata in media files
image manipulation including common tasks such as cropping, resizing, rotating, etc.
doing CAD file format conversions
media companies, particularly with large video assets.
gaming companies, needing to push executables as well as updates to executables
anti-virus companies, needing to push executables as well as updates to executables
law firms storing and managing large amounts of documentation in the cloud.
architects storing and managing large design files in the cloud.
healthcare companies storing and managing large image files in the cloud.
building and construction industry storing and managing large CAD models or BIM files in the cloud.
Smart Feeds API
– *The core (secret sauce) is that Smart Feeds has a 4 tier architecture that takes raw event data generated by the sensors, buffers and persists it and then renders it into a concept of ‘feeds’ which are specific categorizations of the sensor data (for example, by type of sensor, by location, etc.) so that a feed specific to all fridge sensors in shops with a floor area of 1000m2 can be simply pushed through to a client application and made available to the end user to view. The key here is scale (‘000s of sensors, producing raw events every second or half second ) and the ease of defining/configuring feeds to be consumed by the client app.
– *Setup/ integration time. With Smart Feeds, if your sensor data is already available via wifi, it will take just a couple of hours to set up and get a purpose-built end to end solution running. This is in comparison to a toolchain that would require integrating two general tools and applying them to a specific business case. Hadoop is powerful, but you need to get a guy (or two) to get it up and running, integrate to Splunk, configure Splunk to find and spit out the correct data and then once it’s all set up, you’ve also got the cost of assigning resource to manage the whole toolchain. Slow, slow, slow….
– *Cost – running some combo of Hadoop and Splunk won’t be cheap in terms of licensing, personnel and server costs. Also, is that what you want your guys working on? Smart Feeds is less expensive and completely SaaS and our guys can do the integration bit quickly and for free.
– *End to end – part of the simplicity of Smart Feeds is that is supports a variety of roles and permissions to the app itself, so you can let people from all different part of the business into see the data if you want to. The operational analytics guy may be the main one, but you could also send your CEO, or a store manager, a url, and get him/her to login to view temp data from a specific store, across a set of stores, or across the whole estate. Smart Feeds helps to bring the data alive, make it accessible and helps people understand what is going on with elements of the business that are not normally focused on (but are nevertheless critical).
– *Hunger – where I think that Smart Feeds will get really interesting is in predictive analytics.
Yes, please. Deploying and configuring our APIs is straightforward. We would provide the APIs under an evaluation license at no cost. Any work done during the PoC could be used in any subsequent production deployment and therefore can be viewed as an initial investment. We can start tomorrow.