- 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 10Duke Entitlements.
- 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 (e.g.) 3 pieces of content before the client application directs the user to a payment wall.
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. 10Duke 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.
With a well-designed Entitlement API, this license validity information can be stored locally and therefore require minimal license checks (via API calls) at the end of each calendar month (or a defined subscription period). This allows you to create a better user experience for your customers.
Once the entitlement rules for this new product package have been defined and configured, it is ready to be included in the overall product set. This configuration process will 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, 10Duke Entitlements 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. 10Duke Entitlements 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. 10Duke Entitlements will support this.
- User origin: similarly, you may want to provide unsubscribed users accessing content from a certain country 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, 10Duke Entitlements 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. 10Duke Entitlements 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. 10Duke Entitlements can still be used to apply a meter to them. 10Duke Entitlements is an 'identity-based' entitlement so it has the ability to gradually build up a user profile even if we don't initially have access to their email address. 10Duke Entitlements can do this initially from an IP address and then build the user profile from there. So this means:
- You can use 10Duke Entitlements 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're selling anti-virus software. Each license you sell allows your customer to use the software on one PC and 2 mobile devices.
10Duke Entitlements 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 requires no license server to be installed on the customer site.
- 10Duke Entitlements does not rely on license keys and therefore there is no need to issue, revoke, replace, or reconcile licenses. This means your internal cost of license admin will be a fraction of what it is if you use Flexnet.
- The 10Duke solution is ‘always on’ which 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 applications 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.
10Duke Identity Provider API
Option 1 - "Lazy migration" is where users are prompted to change their password in the 10Duke Identity Provider (IdP) when they log in the first time.
Option 2 - "Eager migration" is where we use API or direct database integration from 10Duke IdP to AD and move all users in one go (this option may also be doable by an export / import approach). Users still need to change their password / reclaim their account.
Can't find what you're looking for?
Contact us - we're happy to help!