In the second of a series on Identity and Access Management (IDAM), Jagdeep Bhambra discusses the basic functionality available and the key principles of implementing such a solution within an organisation.
As enterprises evolve and have ever-increasing demands on the functionality, capability and services they need to offer the end-user, the nature of managing identities and the ability to access resources becomes equally complex.
The core features can be summarised as follows (see below); variations on the theme vary from product to product.
1 - The ‘Cause’ (usually automated) - many systems provide data for the IDAM system as automated or semi-automated data feeds. These can include Human Resource (HR) systems, Customer Relationship Management (CRM) systems, identity providers (IDP), directories, and Comma Separated Values (CSV) file bulk uploads.
2 - The ‘Cause’ (manual) - in addition to the above, administrators and self-service portals provide the ability to update data within the IDAM manually. This functionality can (and quite often is) exposed in a myriad of ways, such as web services, APIs, etc.
3 - Core Actions - depending on the nature of the input and / or request, a variety of actions can take place within the IDAM system
4 - Core Functionality - the IDAM system at its heart provides a variety of capabilities (some have been discussed in my first blog of this series). The richness and granularity of functionality is dependent on the needs of the organisation.
5 - Shared Services - these can include ‘interfaces’ to services such as risk analysis, scheduling, auditing, compliance, tamper detection, trending, ROI analysis, delegation, etc.
6 - The ‘Effect’ - the net effect is to provide a host of capabilities (benefits) within the organisation and external parties such as access control, enterprise single sign-on, federation, directory management, automation, etc.
Key Principles
Below is a series of recommended principles that have guided the approach to tackling identity and access management within UK Government (these could apply equally to non-IDAM solutions!). These are listed in no particular order, intended to be high level, and to be used in context.
Patience
One must appreciate that delivering IDAM takes time (and effort); this is quite often missed / unappreciated by the business and stakeholders. On average, it can take up to 3 years to deliver a proper, fully implemented IDAM system (estimated through various sources). As with other well-executed projects, the solution implementation should be iterative in nature, phased, well-defined (where possible) and outcome-focused (enabling the customer and business to see value through each iteration). Again, there may (and usually are) unforeseen issues, such as dependency on external systems, contractual obligations with other vendors and/or suppliers, security and compliance.
Do not implement everything at once
GDS recommends an iterative, user needs-driven Agile approach to enable phased delivery (see here). This avoids the ‘big bang’ approach which often plagues complex projects, quite often resulting in a ‘big explosion’.
Do not start by looking at technology solutions
The first step is to understand the customer needs (this could be the enterprise user) and to establish how many of these needs are to be fulfilled. This should be the driving force influencing the design and architecture. Through this phase of discovery, an understanding of the strategic solution should be explored, for example, does the future solution require federation capabilities? Is single-sign on required? What is the size and scale of the rollout, timescales, etc.? The delivery and implementation of the IDAM solution should focus on being results-driven and should provide measurable business value.
What identity management processes are manual?
The IDAM system should be seen as an ‘enabler’, not as a definer of identity management processes. Many times, the issues faced by the organisation with regards to IDAM tend to be due to poor (business) processes which get implemented, rather than the technology itself. The processes should be right for the enterprise, and should work (if this were a manual workflow!). Following on from this, the next step is to identify what problems you are attempting to solve, and understand which of these need to be automated, streamlined, etc. Taking a step back from the technology, you should appreciate that (as with every other technology solution), simply automating and implementing poorly designed business processes into the IDAM solution will inevitably result in a solution that is not fit for purpose. Putting it simply, would the process still work if it were done manually?
Reviewing the risks, constraints and policies
Very often, an update/review of the business risks, constraints and security policies gets overlooked. The review (with representation from key stakeholders) enables all of the above to get updated and assessed. It ensures that they are still in context. You need to ask questions such as “how much of these are still relevant?”, bearing in mind the level of risk vs. implementation vs. delivery, the profile of the data itself, etc. Addressing these will enable better management of the risk profile and scope of the project. The focus here is to approach risk pragmatically, rather than ticking boxes on a sheet.
Collaborating, communication and sharing
The need for the right people, at the right time, with the appropriate level of skills cannot be underestimated (or underplayed!). For success, these factors need to be aligned. A step towards such a nirvana is to involve the business, application, security, risk and implementation owners; never forgetting the end user! Siloed approaches, especially with IDAM, will seldom result in success.
Be aware of operations, business-as-usual, and ‘live’
It has to be appreciated that the core benefit(s) of IDAM solutions are not realised in implementation, but rather when they are 'live' and in full operational mode. With this in mind, an awareness of the operational maintenance, standards, updates, external and internal changes, process optimisation, service management, business (re)alignments and other business-as-usual activities needs to be incorporated into the (ongoing) IDAM strategy. To enforce the last point, IDAM is an ‘organic’ system, and evolves with the business; the implication of this is that the operational model should allow for - and enable - the flexibility the business demands.
It is (very) complex
This point should not be underestimated by any stretch of the imagination; IDAM is considered one of, if not the most complex arenas within enterprise technology solutions. The challenges that need to be addressed should be captured, tracked, measured and managed continually. An iterative approach, and building simpler solutions that can be iterated upon, will have a higher success rate than complex solutions delivered in a ‘traditional’ big-bang approach. The message here is: do not even attempt to do everything at once!
‘Future proofing’
To deliver solutions that can withstand business change, you should build on principles that any good, modern technologist will automatically follow. These include avoiding vendor lock-in where possible, enabling flexibility, adhering to open standards, iterative delivery, implementing continuous deployment / integration, ensuring continuous testing, following good API design, rigorous automation, etc. In summary, Agile engineering and architectural best practices should always be followed within a pragmatic delivery framework.
Bring everyone along the journey
Experience shows that it is always easier to connect people together when they speak the same language! Similarly, when looking at large-scale multi-organisation models (federation), the recommended approach is to ensure that the organisations themselves have a consolidated IDAM solution in place (ideally) before attempting to connect them together. Asking to federate beforehand will result in failure on a massive scale. With this in mind, tackling large-scale implementations requires bringing everyone to a similar level of maturity before considering federation.
Crowd-sourcing
The nature of government allows one to leverage the advantages of a large technology user community, together with it economies of scale. This enables (and empowers) departments to reuse functionality developed elsewhere rather than developing it each time; this allows for a reduced time to market, reduction in cost and risk mitigation. This model is by no means unique to the government. The same model can be applied to arenas such as business process modelling, risk profiling, service management and delivery, etc. where organisations can use the best, discard the worst, and improve on what has been achieved already.
Final Words...till next time
It would be great to hear of any other advice that people could give based upon their own personal experiences in implementing IDAM. Given the broad number of IDAM systems out there, has anyone come across any unique functionality, whether positive or negative, worth discussing?
Follow Jagdeep on Twitter and don’t forget to sign up for email alerts for the Government Technology blog here.
1 comment
Comment by Andy posted on
HI Jagdeep, I sincerely wish you well with creating IDAM capability within UK Government. As the original solution design lead for the Government Gateway I do appreciate some of the challenges you face in working out an updated IDAM solution which is equally able to span Central Government, Local Government, other private and public sector organisations, and not least citizens (not forgetting the ability for individuals to act as agents on behalf of other individuals and organisations) as the Government Gateway has over its lifetime. Of course that was an IDAM solution for a different and earlier stage in the UK's Digital journey when IDAM approaches across Central and Local Government, and NGOs were less mature and more heterogeneous, and technology available to the general population was often less reliable and was certainly less pervasive than it is today.
I would challenge your comment about IDAM being one of the most complex arenas within enterprise technology solutions - in principle IDAM is not that complex in technical solution terms. Certainly there are many public and private sector technology solutions which are far more complex than this. The greater complexity with IDAM is generally in the associated organizational factors, but the system as a whole does have to be well thought through which is why I think it is brave to take the proposed incremental approach to designing a complex enterprise system like this which ultimately needs to be highly robust and trustworthy.