This article is how I would deliver an Identity Management architecture and implementation in accordance with the Open Group’s TOGAF architecture development method. This post is based on my personal experience as a digital enterprise architect and as a solution architect implementing indenting management, master data management and security systems. I intend this to be part of a series on applying TOGAF and using IdM as an example. In this first post I will only describe the functional capability necessary for an IdM system and will focus on the TOGAF definitions for stakeholder, concern, view and viewpoint.

System:

Firstly the Identity Management (IdM) implementation will be referred to as the TOGAF system. This system has stakeholders who have concerns. The stakeholder has a view of the system which is taken from their viewpoint. These definitions allow a business architecture and architecture building blocks to be created for the identity management system and used as part of the TOGAF ADM.

Stakeholders:

The non-exhaustive stakeholder list for an IdM system include: system owner (e.g. Business sponsor), system maintainers (e.g. Individuals who manage the solution), user maintainers (e.g. Individuals who manage the users & their permissions within the directory system), security governance (e.g. Individuals who validate and sign off the architecture and the software according to the organisations security principles), system developers (e.g. Individuals responsible for coding, packaging and deploying the system) and project team members (e.g. Individuals responsible for the software delivery and maintenance of the IdM system).

I’ve not described them here but the organisation’s HR function who manage the organisation’s joiners and leavers (also promotions & changes) will be key stakeholders if the IdM system is to be used to manage the employees (potentially both internal and external).

The end-user stakeholder is the most important for an identity management system because their concern will massively influence the software solution. For example it may not be necessary for an organisation to maintain the customer end-user’s credentials these saving the organisation large costs in terms of registration and password reset capabilities. In the case of an eCommerce implementation it may make more sense to trust the OpenID Connect capability of PayPal’s (other authentication providers too) Login with Paypal rather than enforcing a local registration for each customer. Choosing external IdP trust as the identity provider does not remove all of the existing stakeholders because system ownership, system maintenance and security concerns remain valid concerns. The stakeholder list depending upon the solution requires review as part of the ADM process.

Stakeholders can be categorised by type such as corporate, system, end-user and project. I often prefer to avoid type categorisation as the type can quickly become a pseudonym for the stakeholder themselves and as such dilute their importance and the quality of their concern. It is though useful to have a repeatable organisational list of stakeholders as these process are repeatable through multiple organisational software deliveries.

Concerns:

Concerns and requirements are not necessarily synonymous because concerns are conceptually larger groupings of requirements that encapsulate the key interests of the stakeholder. Crucially because a concern is a key interest it determines the acceptance of the system. Acceptance criteria must be made against a specific requirement in order to objectify the sign-off process otherwise the system implementer will be at mercy to the vagaries of emotional acceptance.

For a successful Identity Management system implementation concerns are crucial but thankfully also fairly obvious. For example the security governance stakeholders (naturally the most risk averse people on earth apart from England cricket captains) would have the following concerns: security testing coverage including penetration testing, cryptography, encryption and digital signing concerns, risk management concerns such as password management and policy, assurance, availability and administration concerns.

It is important to capture concerns jointly with the stakeholder but to own the process of concern capture if the actual stakeholder or stakeholder function has not defined previously defined their concerns. It is most likely that the security governance function will have pre-published and regularly maintained documentation covering organisational security policy. I have regularly seen security governance stakeholders try to enforce that internal and external password policies should be the same. For example the security governance function will require a much stronger password management policy than maybe necessary or appropriate for a customer facing website. This is a good example of where security concerns and customer concerns will clash. The best approach here for the enterprising architect is to preposition the customer evangelist for this conflict.

Views:

A view is a representation of a system from the perspective of a related set of concerns. A view consists of architectural documentation (e.g. diagrams, requirements coverage, PowerPoint) showing stakeholders not only how their concerns are being met but also how they are being met. Remember that different stakeholders will have different views of the IdM system such as the security governance team member will have a different view to that of the customer evangelist.

The following are the architectural artefacts that I regularly produce for an identity management system implementation and how I use them to manage concerns (note that these artefacts will be phased and not all are immediately necessary for business stakeholders):

Requirements ( I will cover these in more detail later in this series but it is sufficient here to say that identity management is a complex area in which many business owners will have little technical expertise. I advise against over elaboration of technical IdM requirements following a “system shall…” approach and rather focus on the business reasoning for technology and standard selection and also the UX wireframing / mock-ups (depending on the appropriate level of detail) for login & registration processes)

Technology standards. Selection and reasoning for standards are pre-solution design prerequisites. What are you protecting and how? Are you SAML, Kerberos, Shibboleth, OAuth, or OpenID Connect? More importantly why and can you explain why?

Security policies. Hopefully these will have already been defined in your organisation. If not start immediately.

User model diagram for entities & attributes necessary as part of the directory system and identity repository (it is important that the business owner is involved in this stage especially as they often enjoy & appreciate it). This artefact is a key architectural building block for the IdM system and requires regular review if scope changes.

User lifecycle processes. This is the cradle to grave information that requires a human architecture to manage and maintain the system. Are you outsourcing or keeping in house? What bits can you split off? How does any of this differ from your existing systems? Have you got business agreement, budget and guarantee that it will be supported?

Vendor selection. Do you have a preferred vendor, do you require an RFI / RFP? If yes is your stakeholder list appropriate? Are the captured concerns sufficient to differentiate between vendors.

Component list: description of all the various software components involved. This is useful and appreciated especially when certain vendors have balkanised their licensing of IdM components. What & why for each component needs to be succinctly described.

Physical architecture & deployment model (preferably in UML) is probably the most important technical architecture artefact in an IdM system deployment. It is critical to know how directory services are being located and exposed to other systems covering authentication and authorisation. If the deployment is a CoTS (most likely as no-one would write this stuff from scratch anymore) product deployment then one of your stakeholders would often be the vendors professional services team and the system implementers concern will be the ratification of this architecture.

Sizing & capacity model. These are very difficult to produce as an organisation will ask for as much as possible accord g to budget. It’s obvious to refer to previous models but as identity management maybe a new function or a large master data management driven consolidation then previous models may not apply. I would ask both the vendor and system implementer to help.

Test Model. Testing for identity management is complex and critical. At an early stage it may be sufficient to define security policies and encryption / signing technologies. It is important to have all the necessary testing and patching environments available ahead of time. A review of testing tools is as early-mid phase activity.

Patching & support model. This is both a pre & post go-live activity. The pre go-live a model is required for how patches are downloaded and applied and tests run. Normally a parallel environment is required. Also licence support guarantees are necessary from the vendor.

Architecture roadmap. More importantly a business roadmap is required because identity management is an area that is often degraded to being just an enabler rather than a clear discrete but involved function of your business. If your organisation is conducting a data cleansing exercise through master data management then how exactly does this fit with the identity management roadmap?

System delivery roadmap. This is not the enterprise architects ownership but it must encompass the architecture perspective because, for example, if there is a data cleansing / consolidation exercise then the identity management system delivery will often be split between various functions and directory service actions and the component deliveries will need to be spaced out to allow approval and validation steps.

From all of these artefacts different views can be collated to provide a concern compliance model. This can also be used by the architecture board as part of architecture compliance reviews. Always remember to try and start objective if you are producing these artefacts and try to mark your own homework before the architecture governance board marks it for you. Confidence is critical in a security product implementation and it is far easier lost than ever won back.

Viewpoints:

A viewpoint defines the perspective from which a view is taken. The metaphor given by the Open Group is relationship between viewpoint and view is analogous to that of a template and an instance of the completed template. In my view this does not capture the subjective nature of the stakeholder whose concerns are more than a checklist template. The template analogy does not convey the importance of good documentation and presentation as part of an enterprise architect’s skill set. The viewpoint differs from the concern as it is the stereotype of the stakeholder. The experienced stakeholder will regularly raise concerns that should be raised by other stakeholders. These concerns may need capturing or have already been captured but some can be waived if the relevant stakeholder has provided reason. For this reason the view presented to the stakeholder must be from a viewpoint that mirrors their relevant concern.

views and viewpoints for an identity management system

Above I provided a set of the architecture building blocks relevant to an IdM system implementation. Here they are mapped to the relevant viewpoint.

Trade-offs to make between concerns:

It is the role of the enterprise architect to balance competing concerns. The most obvious within an identity management implementation is the competition between identity as an enabler and security as a constraint. The identity management project can quickly end up being responsible for other systems security. This forces the system into being a blanket security provider and always returns an architecture that is as only strong as its perimeter defence. It is therefore important to gain quick business agreement that identity and security are not the same thing and security is a concept for which all organisation stakeholders have to take personal responsibility. This way the identity management system can address the concerns for which it is best suited such as identity management and access provisioning.

ADM Cycle & ordering of architecture artefacts:

The architecture building blocks that are described above are developed in TOGAF between the ADM Phases A through D. I do not specifically disagree with the TOGAF ordering but of all the artefacts produced for an IdM implementation it is the security audit that takes the longest and the physical and deployment architecture that needs to be brought forward where possible.

Conclusion:

In TOGAF the primary question the EA needs to answer is does the architecture address all of the concerns of the stakeholders?

Most identity management software vendors will rationalise their service enablement capability as so:

Identity and access management has traditionally focused on managing user accounts in the form of directory service entries – the traditional IAM/IdM view

it has seldom involved managing identities, let alone multiple types. They might digress slightly here on the history of Master Data Management which has had to grow to the side of identity management but often within the organisation so has never been able to support an identity type discovery service.

Identity and access management (IAM) has traditionally focused on managing user information technology accounts in the enterprise. The rise of different types of accounts and identities such as cloud, mobile and other devices, e-commerce, and social networks has asymmetrically complicated things. – So far so good

Furthermore the internet of things requires identity management for devices, embedded SIMs and network connections all of which require tying back to potentially enterprise, family or personal accounts. – Note about licence costs likely at this point

The increase in user and device accounts will require IAM providers to offer more flexible solutions but in all likelihood enterprise will continue to confine their IAM capabilities according to their directory service. – Product pitch coming here…

Depending on the organisations existing IAM capabilities and embedded technologies the software vendor will generally pitch a service enablement capability that sits on top of legacy directory services. This should be an intelligent Master Data Management capability but often is a lightweight OAuth & SAML cloud enabling layer and an upgraded 2FA/3FA service for external authentication & possible BYOD.

As these a vendor driven pitches they do not seek to solve enterprise’s more fundamental issue of how to consolidate all those existing directory services and to support multiple identities. A strategic architecture is needed for that first…

Identity and access management have traditionally been used to manage the identity and credentials assigned to human users. Machine to machine devices such as Smart Metering GPRS enabled electricity meters or SIM cards in cars require their own identity and access management capabilities. These include new M2M authentication schemes because traditional authentication schemes always assume the presence of a person. This means that most authentication technologies cannot be applied in machine-centric M2M context. Following from this the following are five keys authentication and authorisation challenges posed by a non-human orientated identity and access management system.

1. M2M Security and Authorisation:

With human user password based security has specific known issues but the secure credentials remain with the individual. With M2M access management it cannot be assumed that a given M2M module assigned to an individual or a system always remains a valid and true association. M2M devices can be lost, stolen, replicated, decrypted and hacked by both well-intentioned or malicious entities. As with BYOD the identity of the M2M must be continually validated using higher levels of encryption & signature that reflect the passive state of M2M devices.

2. Directory Services for M2M:

The increase in M2M services means that the number of non-human identities is growing. This increase requires a directory of all non-human identities which can be both organisationally managed or externally managed. As with the M2M Authorisation challenge a record is required for each individual M2M module.

3. Role and Attribute Management:

M2M device identity management must include roles & attributes that encapsulate its use. This may include the end-user, the service provider, the related services, the available resources, the module’s location, the module’s potential roaming allowance and other usage based attributes. Furthermore, the M2M device may require authorisation according to the data off-load technology such as when switching from GPRS to Near Field Communication data off-load.

4. Module Provisioning:

Individual M2M modules may be assigned to a collective M2M ecosystem and/or a family / person. Any provisioning operation would require a presumably remote M2M module to be activated as either a standalone item (e.g. single meter system) or as part of a group of items (e.g. collective security systems). Identity provisioning rules that are extensible are critical to ensure both management and maintenance of M2M devices across the ecosystem.

5. Security Updates and Control:
Making changes to M2M modules depends upon the network architecture (GPRS, wired, wireless, NFC etc) but to provide ecosystem security (e.g. security patches) it must be possible to make real-time and near real-time control changes to M2M modules when vulnerabilities and anomalies are detected. Traditional human identity and access management systems can more easily protect against cyber-attack threats by bulky applying patches. With passive authentication systems such as in certain smart meter technology it is not always possible to make an upgrade and there is always the risk that individual modules with an ecosystem can become contaminated. Therefore any architecture must work with an isolating mechanism for quarantining modules and their data.