General FAQs
Will you participate in an Evaluation project?
Yes, please. Deploying and configuring our Identity Provider and Entitlement API is straightforward. We can start tomorrow.
Can you tell me a little more about your business model?
We provide our APIs on a SaaS basis, with a minimum monthly (baseline) and then charge per active user per month. An active user is typically defined as any user that makes at least once license check per month.
How much do your APIs cost per month?
It depends on which APIs we are talking about and the scale of activity your business generates. We provide our APIs on a SaaS basis, typically with a flat baseline fee which includes some level of authentication/authorisation activity and then with a per active user fee on top of this. More advanced features such as MFA or use of or OrgAdmin application incur additional charges. We offer 12, 24, 36 and 48 month contracts.
10Duke Entitlements API
Does your Entitlement API support the use of digital signatures? If not, what would need to be done to include these?
Digital Signatures are used generally in the domain of cryptography and usually their use is related to ensuring that data has not been changed between the provider and the consuming end. 10Duke Entitlements uses certificates, encryption and digital signatures in relation to many things, including:
- 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
Does your Entitlement API govern concurrent usage?
Yes, our Entitlement API can be configured to reflect certain constraints and one of these can be concurrency. For example, it can be set to allow a user to access an application via a web-browser and also access the same application via a mobile client application, but prevent that same user from accessing the application using a second web-browser or a second mobile application. Other constraints can include geography, time, device, counting of content access and user state (i.e. logged in, not logged in).
If we are trying to reward different user types or users who access our content from a particular device, such as a mobile phone, can your Entitlement API be configured to allow 10 pieces of content be delivered to a mobile device and only 1 to web browser client?
Yes, for our Entitlement API, this is a particular entitlement that would simply need to be configured to reflect those particular constraints - a user from a mobile device can access 10 pieces of content and a user from a web browser can access 1 piece of content.
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.
Many of our users are just browsing our content and have not registered with us. Can your Entitlement API limit their content access even if we don’t know who they are?
Yes, this is possible by means of our Identity Provider and Entitlement API working together. A ‘browsing user’ is simply a type of user as defined by the Identity Provider.
We define “pseudo roles” for users including categories:
- Author
- Owner
- Authenticated user
- Last editor
- Viewer
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.
Your Identity Provider and Entitlement API are APIs to which we would connect our client applications. The underlying applications for your APIs are proprietary software and are not open source. What happens in the event that we choose to deploy one or both of your APIs, but then 18 months later for whatever reason, we decide to move to another provider? To what degree are we locked in?
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.
How scalable is your Entitlement API?
Our default deployment model is designed to support 20-30 million user profiles, and the entitlement traffic generated by them. The largest customer implementation that has been tested involved 300 million end users so our Entitlement API can likely handle any significant load you may choose to throw at it.
Where does the ‘configuration’ take place and where are the define product packages and policies (constraints) stored?
Configuration can be done using the REST API or alternatively using 10Duke Entitlement's configuration UI. Product packages, license models, licensed items, etc. entities are stored in the database of 10Duke Entitlements.
How would your Entitlement API work with the Hybris Entitlement engine?
You wouldn’t deploy the two together. Our Entitlement API is an alternative to Hybris entitlements.
The Hybris Entitlement Engine charges per API call. Do you do that?
No, we offer a per user per month fee, or a flat monthly fee for larger customers. Client applications can optimize the number of API calls needed and the value of an API is not related to the number of calls that may be made to it. Particularly in the case of a digital product that is licensed monthly, the client application can be configured to make a license check only a few times each month in order to verify that a valid license exists.
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.
If I become a customer using the 10Duke Entitlement API and a year from now a new device is released, for example the Apple iWatch, and I want to deliver a variant of my newspaper’s app for that device, what would I need to do?
Once you have your new ‘Newspaper’ App for iWatch, you would need to define a new licensable product package (eg. ‘Newspaper App for iWatch;) and then configure 10Duke Entitlements (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, it is ready to be included in the overall product set. This configuration process will take 5 to 10 minutes to do.
What are some user case examples for the 10Duke Entitlements to help me understand it better?
Here are three example use cases:
- 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.
What are your services for authorisation?
10Duke Entitlements is a service that allow you to define and control user access to any protected resource (like an application, item of data, or piece of content). It takes care of authorisation decisions.
In the case of a 2nd product, does the licence to that product sit within the same Entitlement or a new/different one?
It depends on the vendor's preference.
Can you offer the same services or something similar to Gemalto?
Yes, 10Duke Entitlements can offer the same capability as Gemalto except that our solution is cloud-based and much more flexible and we don’t rely on license key or dongles.
Can you see how frequently the users use the software or what functions they use in the software?
Yes, this insight is provided by our Event Data API which is a collection of all data relating to when users access your application, what licenses they use and what features or modules of your applications they use.
Can the customer define the names when internally controlling the licence?
Yes, there are a couple of different features our solution has to enable this. For example, we can whitelist a domain so that any user from a particular company will be able to access a license to a product. Also, we have a company administration tool with which a company admin can administer their own users and control licenses internally.
Can your product make a connection to our CRM database?
Yes, our solution can be integrated with most CRM products. Data is passed between the systems using either XML or JSON.
Does your solution support offline license usage?
Yes, the solution can be configured to support offline usage for a defined period of time. When the defined period expires, the client application would need to connect to the licensing service to check that the license is still valid.
Does your solution provide an overview of what licenses have been issued?
Yes, in our SysAdmin tool you can see what licenses have been issues, which have expired, which are due for renewal and several more information points.
Is it possible to give a partner the responsibility to issue licenses?
Yes, via the Org Admin tool the responsibility of issuing license can be given to your customer so that they are able to administer their own users and own licenses. For larger organisations, this is typically something they prefer to do and it reduces your internal admin workload as well.
Do you do the integration process?
Integrating our APIs to your applications is something that you can do yourself if you wish and we are there in a support role as needed. Our APIs are well documented (developer.10duke.com) and we also provided a number of open-source SDKs that can help your technical team connect your applications to our APIs. We are also on hand to help guide you through how 10Duke Entitlements is configured.
In SysAdmin, can you see the organisation they are from in the user tab?
In SysAdmin you can see user emails and thereby what organisation they belong to. Equally, if you filter by organisation, you can see what users belong to that organisation.
If I have a new group that I want to give access to the same Entitlement, do I just add them to the Entitlement?
Yes.
After an Entitlement is created, can we delete the specific product package and the licensing will still work? If yes, is it retained in SysAdmin primarily for reference/future use?
Yes, provided none of the underlying licensed items are deleted from the system. Yes, the product package information is retained primarily so it can be used again. There is no cost to hold it in the system.
If our customer buys a 40-person licence of 'Product A' and one user has activated 'Product A' a on 3 devices (old laptop, new laptop and office desktop), would this account for 3 of the 40 licences or just one?
It is entirely up to the vendor's preference and 10Duke Entitlements can be configured either way to support either the consumption of one licence or three. It can be constrained per individual or per device.
How is organisation membership established and by who?
The user is set with an entitlement by the licence administrator (a team leader within the organisation).
One of our licence models is using a MaxAggregateUse constraint. Can we remove the constraint from the licences that have been already granted based on this licence model?
Yes, the constraint can be removed.
When it comes to talking to the customer about renewal, can we see how often they have used the software in the last year?
Yes, our Event Data API provides you with a lot of detail from when a user last access your application, to which feature or features he used, to what license he is using. This information can also be provided at an organisational level, so you can view usage across a company.
What makes the difference between you and Flexera? Why can you be competitive?
The 10Duke approach to software licensing is fundamentally different to that of Flexera’s and our product is designed to overcome many of the limitations found in Flexera, Gemalto or Reprise products. This blog post goes into more detail about the differences between 10Duke and Flexera, but the main points to be aware of are:
- 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
If I am using the 10Duke Identity Provider, how does one of my customers reset their password?
The default password reset process requires the customer to click on a ‘Forgot Password?’ link and then enter their registered email address. The IdP then sends a link via email to the customer which takes them through a password reset process. The default security level (which can be made either more strict and more lenient) uses an expiration time-based token and a user secret in the process. More strict security can include e.g. SMS delivered tokens to ensure that the genuine user has required the password reset.
If we are running 3 separate web applications, do your Identity Provider Support Single Sign-on between them so the user only has to sign in once?
Yes, the user would log in to the first web application, but in practice they would be actually logging into the Identity Provider. This would then authenticate them and grant access to the first web-application. When the user tries to access the second web application, a similar process would occur and the IdP would authenticate them to the second application. The process is the same for the third (or N) web application. For the user, they only login once and each subsequent authentication happens so quickly it is not normally noticeable by them. Similarly, once they log out of one application, they are logged out of the IdP itself and therefore are logged out of all applications.
Does your Identity Provider support fingerprint scanners as a method of authentication?
Yes, the IdP can be configured to include a number of alternative way to authenticate users. The challenge is harder on the client application side as the protocol and best practises require that clients connecting to the IdP do not know how the user is authenticated. This means that the IdP is responsible for presenting the challenge and the client application(s) must have the capability to present relevant UI and methods for the user to interact. Common technologies and methods usually use “smart card” based approaches.
Does your Identity Provider allow us to work with companies where the company is a customer and may have a number of people within it who receive a subscription but are managed as a ‘group’ subscription?
Yes, our Identity Provider has a particularly extensive model for supporting organisational structures. In this case, the IdP could recognize ‘The company, customer’ for which there are designated representatives who can login and manage the subscription and to which people the subscription is provided. The number of subscriptions and type of subscription within that group is government by the Entitlement Service, which working in the SSO environment is able to connect users to their organizations and thus further make the connection between a user and her right to consume the customer organizations entitlement.
How are clients updated when a new version of the Identity Provider solution is released?
Changes to OAuth, SAML and other SSO protocols are rare and therefore in most cases there is not a need to update client applications for this reason. Also, the HTTP / endpoint contract that the IdP provides supports versioning, which means that old client versions may be maintained for a time period deemed feasible by our customers without adversely impacting their current SSO service in production.
What Social Login providers does the 10Duke Identity Provider support?
The 10Duke IdP supports any social login provider that function as an OAuth 1.0a, OAuth 2 or SAML 2 provider so services such as Google+ , Facebook, LinkedIn, Twitter, Instagram and more.
Does your Identity Provider allow users alter, correct or delete their profile data?
Yes, the Profile management/edit screen are fully customizable and allow end users to edit fields such as name, organization, profile picture, password, mobile number, email address, etc.
Can you apply data validation (address/email address/ profanity etc.?)
Yes, e.g. email and password validation is a built in feature (by means of configuration).
Are users able to reset their own password?
Yes, an easy but very secure process is provided out of the box.
Can you restrict access to some of the user's data fields from different apps / sites using the sign in system (e.g. one app could collect info not seen generally)
Yes, this is possible using consumer scope privilege configuration (consumer = connecting application + user).
Can you delete users e.g. if needed for legal reasons. Can you also retrieve their records and history?
Yes, complete delete and full audit trail features are available.
Is there any integration with email service provider / notifications provider?
Yes, e.g. AWS based messaging is available out of the box.
Does your platform offer diagnostic capability and if so, how granular is this (e.g. can we see down to an interaction)?
Yes, detailed event-based logging and reporting is supported.
Can you have multiple identities linked to a single user profile?
Yes, for example, you can allow the same user to access your apps from a social profile, such as Facebook, but also directly using an email/password combination. These IDs can be reconciled as one profile in the IdP database.
Do you provide a customisable database schema for a single user profile store?
Yes, 10Duke’s Dynamic Schema implementation enables a flexible data access service.
Can all information relating to an individual be easily extracted to ensure that Subject Access requests can be met within statutory time limits?
Yes, the 10Duke IdP has uses a normalized data model, which makes such actions straightforward.
Can the service/solution be easily record where information comes from and where it may be disclosed to?
Yes, activating an audit trail and logging to track such information routing covers this and related requirements.
Do you support users connected to multiple organisations?
Yes.
Do you support One Time Password (OTP) via SMS?
Yes.
Do you support One Time Password (OTP) via Email?
Yes.
What is your user migration process?
There are two approaches that we recommend regard to the user migration. Each has different benefits and we'd need to review each customer case a bit more in order to be able to recommend the best approach.
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 you migrate current account passwords?
Passwords would need to be reset but this could be done in a simple, self-serve ‘make your account more secure’ type workflow so there would be minimal disruption to users.