Entitlement through custom authentication not based on simple username/password scheme

[#1]

We are considering adobe DPS to publish our digital magazines.  Like many other publication companies we also have existing "print" subscribers.

We have an authentication solution that uses WS-federation.  This works by browsing to our login website.  After the user is authenticated, we POST back a JWT security token to the calling application.  It is important to know that we want to show user interface to log in.  Some of our customers login through their Facebook/Twitter account so we don't have any passwords for them.  Our login website also makes it possible to evolve all of our applications and websites in a consistent manner.  For us it is really important that we don't create extra credentials for our users.  We want them to authenticate the same way everywhere.  (the login website also deals with changing "terms and conditions" and will automatically enabled future external identity providers (like Google and Microsoft - it also allows us to force people to update their profile if we don't have a complete profile etc...).

From the DPS entitlement solution we see that the only possibility that is foreseen out of the box is to authenticate users through a username/password credentials.  Is it possible to replace this mechanism with an "open embedded browser/capture token" scenario ?  If so, how can this be done ?  (I guess the other entitlement operations are OK for us)

Many thanks in advance.

[#2 · Accepted solution]

In the new DPS (2015), the only way a user can login is via the native SignIn dialog using user name/password credentials. Details: The native login method will result in a call to the serviceAuthURL specified the integrator settings for Direct Entitlement. DPS will make a Http POST request to the SignInWithCredentials URL passing the user name and password. DPS expects an auth token to be returned that the viewer stores natively. That auth token is what identifies the user for the direct entitlement calls

In the earlier version of DPS (Classic), login differs in a couple of ways:

1. DPS allows HTML to initiate a free-form login flow and even branch out of the app to obtain an auth token
2. DPS had a Library SDK API by which the application could explicitly set an auth token after initiating the custom login flow

There is no equivalent to the DPS Classic SDK APIs in DPS 2015 at this time. Although, we are planning for additional OAuth/Social Login capabilities in the future.

[#3]

Hi Willy,

The APIs you've referenced are for DPS Classic (called Digital Publishing Suite rather than the newer Digital Publishing Solution ), which as Kristy points out, does provide some additional login options made possible with custom coding.

There are no analogous APIs available in DPS 2015 (Digital Publishing Solution) and one can't write a custom app to access the same server-side APIs used by the out-of-the-box DPS apps.

Thanks,

Brian

[#4]

Hello,

Thanks for the reply.  We feared already as much.

We went one step further and had a look at what the DPS App builder produces (apk, ipa) .  We were able to track the viewer on android to an open source project https://github.com/joniks/Android-MuPDF.  As far as I can see this would enable us to build our own app that uses the DPS server-side API's.  Something similar will probably be possible for IPhone.

Are we allowed to create our own custom app based on the adobe API's ?  (Would that be through http://www.adobe.com/devnet-docs/digitalpublishingsuite/DPSViewerSDK-2.32/docs/library/index.html ?)  Are there any examples available ?

Again hoping for response,

Willy.