The concept of a well defined business identity is blurring and this is causing a complex reaction in the area of identity and access management. Internal, enterprise class identity and access management (IAM) has been long defined, as the managing of user access as defined by approval workflows, authoritative source integration and well defined system connectivity.
Historical Business Structures
Historical business identity management has been defined by several well defined structures and assumptions. An organisational workforce that was managed by an IAM programme, was often permanent, static and assigned into a set business function or department. This helped define multiple aspects of the IAM approach, from the way access request approvals were developed (default of line manager as first line of approval), to how roles based access control implementations were started (use of business units or job titles to define functional groupings for example). IAM is complex enough, but these assumptions helped to at least create a level of stability and framing. IAM was seen as an internal process, focused solely within the perimeter of the 'corporate' network. Corporate is this sense is indeed quoted, as the boundary between public and private internal networks are becoming increasingly ill-defined.
Changing Information Flows
If IAM can be viewed as data and not just a security concern, any change to the data or information flows within an organisation, will have a profound impact on the flow of IAM data too. One of the key assumptions of IAM is that of the underlying business structures. They are often used for implementation roll out prioritization, application on-boarding prioritization, workflow approval design, data owner and approver identification and service accountability. This works fine if you have highly-cohesive and loosely coupled business functions such as 'finance', 'design' and 'component packaging'. However, many organisations are now facing numerous and rapidly evolving changes to their business information lines. It's no longer common for just the 'finance' team to own data relating customer transactions. Flows of data are often temporary too, or perhaps only existing in order to fulfill part of a particular process or primary flow. Organisational structures are littered with 'dotted-lines' reports and overarching project teams, that require temporary access, or access to out sourced applications and services.
The introduction of a continued raft of out sourced services and applications (Salesforce.com, Dropbox etc) adds another layer to the complexity, of not only information in general, but IAM information and it's implementation. Accounts need to be created on external directories, with areas such as federation and SSO helping to make 'cloud' based applications become closer to the organisations core. However, those those technical challenges often give way to larger process and management issues too. Issues surrounding ownership, process re-design and accountability need to be accounted for and require effective business buy-in and understanding.
Bring Your Own Device (BYOD) brings another dimension. The data control issues are widely described, but there is an IAM issue here too. How do you manage application provisioning on those devices, and the accounts required to either federate into them or natively authenticate and gain authorisation?
Well like most things, there isn't a quick, technical answer to this evolving area. IAM has long been about business focus and not just security technology. Successful IAM is about enabling the business to do the things they do they best, namely make revenue. Nothing from a technical or operational perspective should interfere with that main aim. As businesses evolve ever more rapidly to utilize out sourced services, 'cloud' based applications and an increasingly reliance on federation and partnerships, IAM must evolve and help to manage the blurring of information flows and structures that underpin the businesses main functions.