FAQ

Yes, please. Deploying and configuring our Identity Provider and Entitlement API is straightforward. We can start tomorrow.

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.

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.

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

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.

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.

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.

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.

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.

Here are three example use cases:

1. 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.

 

2.  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).

3.  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.

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:

1. Our solution requires no license server to be installed on the customer site.
2. 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.
3. 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.
4. 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.

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.

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.

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.

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.

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.

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.

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.

Yes, e.g. email and password validation is a built in feature (by means of configuration).

Yes, an easy but very secure process is provided out of the box.

Yes, this is possible using consumer scope privilege configuration (consumer = connecting application + user).

Yes, complete delete and full audit trail features are available.

Yes, e.g. AWS based messaging is available out of the box.

Yes, detailed event-based logging and reporting is supported.

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.

Yes, 10Duke’s Dynamic Schema implementation enables a flexible data access service.

Yes, the 10Duke IdP has uses a normalized data model, which makes such actions straightforward.

Yes, activating an audit trail and logging to track such information routing covers this and related requirements.

Yes.

Yes.

Yes.

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.

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.

File+ case be used for:

• 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

File+ can be used in any market where there are large datasets and have a need for file storage or management across a wide geographic coverage and a need to transfer large amounts of data from A to B. These include:

• 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.

A web-upload form normally receives one file at a time or occasionally multiple file upload. The scalability of such a solution is limited. As File+ is available via a RESTful endpoint, it can incorporate much more flexibility, into a client application and cover a much wider range of use cases.

FTP enables file transfer/copying and is much more limited in scope than File+. There are a number of known issues with FTP including security, poor scalability in terms of limitations of the size of file that can be transferred and how many files that can be transferred. By contrast, you can use File+ as a more flexible, scalable solution that gives you as a developer a dedicated file management application rather than just a limited transport mechanism.

Yes. Rsync has well-know scalability issues. It has limited efficiency (for example, just building an index of what needs to be synched, is slow) whereas File+ has much broader scope and can be applied to a wider variety of use cases, in addition to being able to keep files in sync.

Yes, File+ offers very similar functionality to S3 but can be used on premise or in private cloud deployments. AWS is secure, as it uses client-side encryption, but if you encrypt data before transfer then they are equally secure. The AWS S3 API doesn’t offer conversion features as well as file management features so with File+ you arguably get more out of the box. If you wanted to run a hybrid cloud, using AWS S3 but also another set of storage servers, you could use File+ to manage both.

File+ can be deployed in a variety of ways including on-premise, in a private cloud or in a hybrid cloud.

You’re right that some Hadoop+Splunk combo could start to produce results in a similar fashion but the two solutions are significantly different due to 5 main factors:

• 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 we think that Smart Feeds will get really interesting is in predictive analytics.