Dual persona solutions are emerging as one way to address BYOD (Bring Your Own Device) and more generally dual-usage mobile.
Dual persona divides the phone/tablet into two logical halves - enterprise IT is authoritative over one half, and the employee over the other. Because the two are securely separated, what activities (poorly chosen passwords, dubious downloads, etc) that might occur on the personal side don't put at risk the applications and data on the business side.
Conversely, the policies and restrictions IT imposes on the business side don't impact the employee's personal usage. IT is happy because the enterprise data is protected against loss, and the employee is happy because they needn't feel their employer is constantly watching over their non-business activities.
As the name suggests, Dual Persona is an identity-based solution - personas are different facets of the user's complete identity. When the individual is acting within the business persona (e.g. reading corporate mail, logging into Salesforce, or reviewing a document), then their corporate identity facet (as manifested in an AD account, defined groups/roles, and corresponding authorizations for application access) is active. Whatever security policies IT has defined (e.g. PIN, timeout, no screenshot, etc) are triggered.
Whenever the individual is performing non-corporate activity (i.e. anything else) then their personal identity facet (as manifested in Facebook, Twitter, their own email accounts, and Angry Birds scores) is active and the IT defined security policies do not apply.
The above implies that the two different sides of the device have different representations of the user - one set linked to their corporate identity and used in the business persona, and another set linked to their various social providers and used in that persona(s).
Concretely, these representations should NOT be passwords, but rather be 'security tokens' - previously issued down to the relevant persona by a 'token server', and stored away securely. It is by attaching such a security token to an Application Programming Interface (API) request that a native application on the device effectively authenticates to the API - the token serving to identify both the user and the application and so informing an authorization decision by the API.
OAuth 2.0 (see tutorial) is emerging as an important standard by which native applications (whether on the business or personal side) on a device can retrieve a security token that represents the particular user and, critically, which persona.
Both enterprise and SaaS Authorization Servers (AS) can issue OAuth tokens down to the applications on the business side for use against business APIs, and multiple consumer Authorization Servers (such as Facebook, Google, etc) issue their own tokens down to the applications on the personal side for use against their own sets of APIs (to post to Twitter, to retrieve a calendar, etc.)
Discussions of Dual Persona typically focus on how such solutions keep business data secure and separate from the Wild Wild West of what may happen on the personal side. Arguably more important (because data can only be lost once but tokens potentially reused over and over) is how Dual Persona solutions keep the security tokens that represent the user in the two different personas siloed and safe. That's a topic for another blog.