Enterprise Mobile App Challenges, Part 1

First let me say what I mean by Enterprise Mobile App: an app running on a smart phone or tablet that is used by company employees and partners as part of their job. Probably custom built. Probably accessing a mix of existing LOB back-ends, some new back-ends and some commercial services (storage, analytics,…). Back-ends on-prem and in the cloud.

I am sure that definition misses some things (I will return to a few obvious ones later) but I am sure that it hits a huge number of projects. So what does it take to build, deploy, manage and maintain an app like this? Since this is a Centrify blog I will point out various solutions we have to some of these challenges, but I am also just thinking aloud about the holes that exist and how they can be addressed. Also hit me with feedback about challenges I have missed

Challenge 1: Identity

How does the app know who the user is and what they are allowed to do? How does the app connect to the various back-ends and have the back-ends be aware of the same information. Should it work with your existing directory services, AD being the most obvious one?

Having the app prompt the user for a user name and password is fine, but:

  • How to wire up to AD
  • Its hard to enter complicated passwords on a smartphone
  • What if we have 3 apps: does the user have to log into each on

What is really needed is an identity system something like the desktop model, you login once and all apps know who you are and can find out more information about that the user (rights, name, email, phone,..). Centrify offers solutions to this using our ‘zero-sign on’ technology. We provides SDKs for major platforms that allow apps to know who the user is; get information about them (and other users in the organization) and convey that identity to various back-end services.

What can the user do? We have roles: roles can be used to create groups of users that, amongst other things, can be used by an app to control access to features. Roles membership can be exposed to the back-ends too.

And of course we have great, painless and secure AD integration; this is, after all, an area where we have a long and successful track record. You can use AD user identities; roles can be defined in terms of AD groups if needed; you can access a user’s email, phone number, organizational position, etc. You can query other users in AD. But we are not limited to AD, if you need to have users from other organizations mixed in – that works too.

All standards based. Primarily SAML, adding OAUTH and JWT

Challenge 2: Configuration

An app needs configuration. The type of data needed is obviously highly dependent of the nature of the application. Some obvious things are

  • URLs of the backend servers
  • icons, colors etc.
  • trace and debug settings
  • policies for access (can only be used within 4 miles of a given location for example)

These are deployment issues as much as direct application issues. You typically want to be able to control things based on:

  • Who the user is
  • What the device is
  • Live, development, test environments

To deal with this type of requirement we recently added a new feature to our platform and SDKs. This allows an app to query for arbitrary configuration data values. The app can also easily to subscribe to change notifications; i.e. if something has been changed in the app configuration it will be notified via a callback that a change has occurred.

From the admin’s point of view the configuration settings are managed as part of our policy management system. This allows policies to be stacked, merged and filtered depending on various criteria. The interface for controlling these settings is in our cloud management console or via REST calls to our back-end.

Hopefully you recognize these as real issues; let me know.

Next post will talk about distribution and central control.