An aim of OpenID Connect is to solve the problem of death by a thousand passwords by allowing the user to select their identity provider including ones that the relying party has never heard of through Dynamic Registration. A problem of allowing the user to select their identity provider is that the authentication challenge page needs to show all the registered identity providers.
This means that this page becomes like the NASCAR problem. The NASCAR problem describes the jumble of branding icons on websites, e.g. 3rd party sign-in/login options or sharing buttons. It is dubbed the NASCAR problem because of these clusters of 3rd party icons/brands on websites resembles the collages of sponsorship decals covering NASCAR racing cars. It’s a problem because such clusters of icons/brands cause both visual noise and people to be confused, overwhelmed or unlikely to remember individual icons, especially as the clusters seem to grow with the introduction of new 3rd party identity/profile/social sites and services.
When using OpenID Connect, it’s likely that the client will both have buttons for popular servers as well as a text field for user entry of an email address or URL. (OpenID Connect does not directly solve the “NASCAR” problem).
How therefore to solve the NASCAR problem in OpenID Connect?
The client will need to either limit the number of registered authorisation servers supported by their service or provide a mechanism for selecting from a larger list of identity providers. Furthermore if the OpenID Connect Dynamic Registration capability is enabled a form field for the authorisation server’s URL needs to be provided as a last option below the existing identity providers.
Limiting the number of supported identity providers maybe easier for commercial sites. In a public sector / government scenario there may be legal reasons why the number of authorisation servers cannot be constrained. As a future example it may become necessary for a government service provider to support all retail banks operating in that country acting as authorisation servers (e.g. PAYM in the UK) and all the mobile network operators acting in that country (e.g. MobileConnect). In this example there may be more that 50 different authorisation providers and the user may have an existing registration with multiple identity providers. It is here that presentation of identity provider is important and mere alphabetic listing maybe insufficient.
The TOGAF Architecture Development Method (ADM) is designed to be sufficiently generic to cover all types of IT programmes. This generalism means that the ADM method can support both organisation and governmental identity management projects. This blog post, as part of a series on identity management in TOGAF, shall cover the best fit of the ADM to a IdM project and will try to answer the following questions:
What is the best way to realise Identity Management (capability & project) within TOGAF’s ADM?
Is TOGAF a suitable Enterprise Architecture model for something as generic and security conscious as identity management?
What is the best way to realise IdM in ADM? The ADM may be generic but it depends upon co-operation with more specific industry verticals (e.g. TeleManagement Forum (TMF) in telecoms) for a more detailed realisation of a technology architecture. Identity Management is as equally inclusive as TOGAF and hence equally applicable across all industry verticals. TOGAF defines four architecture domains (BDAT): Business, Data, Application, and Technology. And the TOGAF Architecture Development Method describes a process for “deriving an organisation-specific enterprise architecture that addresses business requirements”. As such the ADM requires manipulation to fit your organisation and any specific programmes. In an earlier post in this series (IdM Stakeholders, View and Concerns) I produced a set of building blocks necessary for producing a successful identity management system. For traceability I have mapped these building blocks to the four BDAT architecture domains and to the various phases in the ADM. As part of this mapping I have described which building blocks need for an identity management system to be delivered early.
Building Blocks to be delivered earlier that normal within the TOGAF ADM:
Phase B: Business Architecture & Business Architecture Requirements
Phase C: Information Systems Architecture & Application Architecture: Vendor selection & Component list
It is crucially important when working with a technology that may have multiple components to be able to explain each component in terms of its business capabilities.
Depending on the software vendor the component names and areas of responsibility will change. For example Oracle & ForgeRock’s definition of Access Management differs.
The business case should have already have been completed at this stage but it is important to split out responsibility to each component.
The test cases can be promoted at this stage so that both component independent and project overall tests are defined early.
It is critical to promote the necessary environments for a IdM implementation. These are required for testing and patching and for integrating each individual system to which access will be granted.
In a federated architecture working with 3rd parties then for each third party a set of test & contract agreement environments will be needed
If the architecture is a partial migration then environments may need to be consolidated
As the IdM system is a security component it is recommended to introduce good deployment policies at this stage, for example separation of package naming and deployment.
Phase F: Information Systems Architecture & Technology Architecture: Security Policies
Security risks must have been identified and the responsibility for the identity management system must be agreed early
If the solution is a migration project then the legacy security policy from implementation must be compared with the organisation’s policies and the ambition for secured systems
Conclusion: Is TOGAF a suitable Enterprise Architecture model for something as generic and security conscious as identity management At an organisational level an identity management programme is normally initiated to provide a business enablement capability (e.g. SSO or Federation), a legal requirement (e.g. Healthcare) and / or a security capability (e.g. reduced DDoS exposure). At a national / government level an identity management projects vary in scope and identity ownership architecture. Austria’s Zentrales Melderegister (ZMR) or Denmark’s Det Centrale Personregister are examples of identity owning identity management projects working to enable access to eGovernment services. The UK Cabinet Office’s Identity Assurance programme has the same goals but externalises the identity lifecycle to trusted identity providers. Furthermore some programmes such as the UK land registry are not immediately concerned with individual identity but have a strong identity management capability encapsulated within a larger data structure. For both organisational & governmental IdM deployments the TOGAF ADM model can be applied. The TOGAF ADM model is designed to provide an organisational enterprise architecture capability. However TOGAF ADM can be applied to just IdM because Identity Management is a sufficiently complex area and the number trusted identity providers increases. The ADM is suitable for an Identity Management programme but overall enterprise architecture should be applied to all organisational data & security capabilities.
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?
Some M2M devices will always connect to the internet using a fixed network connection / Wifi and others will always connect using a mobile network connection using an eUICC but there will be some that will offer both wifi and mobile network. It is these devices that will need to support wifi offloading where possible. It is for these devices where providing a standard API gateway and AuthN & AuthZ capability will be most complex.
For example, my oven is always positioned in my kitchen and connects to the wifi network to allow me to view inside by a mobile app so that I don’t have to open the oven door during the fifteen minutes a soufflé takes to rise that would cause the temperature to change and my soufflé to collapse. This way I can inspect and control the temperature remotely. It also mean I have an excuse to check my phone during boring dinner parties. Only my app is paired to the oven so only I am authenticated and authorised to remotely check on my soufflé thus there is no potential risk of a malicious guest could accessing my oven app and destroy the soufflé by changing the temperature.
An M2M oven with embedded camera would decrease flops
The majority of my home m2m devices will be static devices, I rarely travel with my oven, and these will in the majority of cases be Wifi enabled. Unfortunately I cannot guarantee wifi coverage throughout my architect’s ivory tower so some mobile internet devices will need to connect over 3G/4G (for example the BBQ in the lower field). The problem for my oven and BBQ manufacturers is that they would need to support both Wifi and the GSMA standard for M2M / smart device SIMs (eUICC). It would then be responsibility of the m2m device to support wifi offload where available.
Authorisation may be necessary when the function of the device is shared amongst a group with one or many people acting as the super administrator. If I sell my oven all of my authentication and authorisation permissions have to be removed from the M2M device but as I will likely buy a new oven with more soufflé capacity I would like to keep my existing settings. Furthermore if my soufflé skills increased I may take a job in Paris and would need to reregister my oven’s eUICC or wifi connection. In this case I would definitely want to keep all of my authorisation permissions and maybe grant further permissions for all the extra soufflés I’d be baking.
Device resale and device portability are supported by the eUICC specification as they are necessary for widespread adoption of M2M devices. What is less supported is a common standard for AuthN & AuthZ that would allow me to keep my device preferences when I either move with or my devices or sell them and replace them with newer devices.
This is where OpenID Connect may be useful as it enables profile information on top of the authorisation model provided by OAuth 2.0. OpenID Connect 1.0 extends OAuth 2.0 so the client can verify claims about the identity of the end user, get profile information about the end user, and log the user out at the end of the OpenAM session. OpenID Connect also makes it possible to discover the provider for an end user, and to register client applications dynamically. OpenID connect services are built on OAuth 2.0, JSON Web Token (JWT), WebFinger and well-Known URIs.
It remains to be seen whether OpenID Connect will be integrated with the standards for eUICC as part of the GSMA Mobile Connect. Furthermore it will need to be supported by the wifi offloading devices (e.g. my BBQ’s manufacturer) as the standard for all M2M AuthN & AuthZ. It seems likely at first that device authorisation and later home M2M gateways will implement proprietary technologies and will maintain identity in individual walled gardens. My architecture ivory tower has a few of those too.
OpenID Connect (final specs launched Feb 2014) is an interoperable authentication protocol based on the OAuth 2.0 family of specifications. It uses straightforward REST/JSON message flows with a design goal of “making simple things simple and complicated things possible”. OpenID Connect lets developers authenticate their users across websites and apps without having to own and manage password files. OpenID Connect has been implemented worldwide by Google, Microsoft, Deutsche Telekom, salesforce.com, Ping Identity and others.
The GSMA Mobile Connect service is a mobile operator collaborative initiative to implement a mobile phone number-based authentication mechanism on top of OpenID Connect. With Mobile Connect the MNO creates a token which is then shared with vendors to verify the customer. The token can be tied to an email address or another user identifier but the GSMA views the MSISDN as the unique identifier for identity aggregation and vendor integrations will be based around mobile phone number. Don’t mention Vodafone360!
The OpenID Connect is built as a simple identity layer on top of the OAuth 2.0 protocol. It allows clients to verify the identity of the end-user based on the authentication performed by an authorisation server. OpenID Connect supports identity attributes by obtaining basic profile information about the end-user in an interoperable and REST-like manner. OpenID Connect allows for clients of all types, including browser-based JavaScript and native mobile apps which allows the mobile internet device to act as a local authorisation server authenticating applications with the identity provision held within the secure SIM card.
OpenID Connect differs from OAuth which is an access granting protocol and as such has no definition of identity. As an example Facebook extends OAuth with what it calls a ‘signed request’ in order to provide identity on top of authorisation. The ‘signed request’ is conceptually analogous to OpenID Connect’s JWT “ID Token” which works with multiple identity providers by using the IETF JSON Web Signature (JWS). In order to be interoperable Open ID Connect provides a standard way of requesting and responding claims for which Open ID Connect has defined a standard scope, RESTful granular methods for request objects & claims and a JSON based “ID Token”.
Open ID Connect supports identity providers such as Google+ Sign-In and IdPs on to the mobile internet device. In this later case the mobile phone can act as self issuing identity provider (e.g. Janrain). It is in this space that GSMA Mobile Connect will feature strongly supporting both the large Identity Provider (e.g Deutsche Telekom‘s support for OpenID for its Business Marketplace to act as an OpenID 2.0 provider to support single sign-on for applications) and the customer delegated model with identity stored and provided from the phone.
The PAYM mobile payment service enables UK bank customers to transfer money to an individual using their mobile phone number (MSISDN) as the identifier. Currently nine banks and building societies have adopted the PAYM service and customers of these providers can now register to use the service.
The PAYM architecture is based on a centralised database of receiver’s MSISDNs. The terms and conditions as part of signing up to the service require the customer to agree that their “mobile number will be stored on a database managed by a third party on behalf of all the participating banks and building societies”. The customer’s name, MSISDN and bank are then held as records within the centralised database. The sender’s bank accesses the PAYM database to confirm that the recipient is registered with the service and to retrieve their bank or building society account details of the receiving party.
According to the Payments Council’s How Does PAYM Work section “the payment will be processed whether or not the recipient’s phone is on or within coverage. In most cases the payment will reach the recipient’s account almost immediately and they will be able to see it in recent transactions on their account”. This means that there is no check by PAYM that the MSISDN is on the home location register or in use by the receiver.
The sign-up process requires MSISDN validation as part of a 2 factor step-up authentication process implemented by each PAYM supporting bank and building society. This allows the MSISDN to be validated before registration with the centralised database. It is sensible to presuppose that the centralised database ensures uniqueness for the MSISDN so that the same mobile phone number cannot be registered by two individuals.
Because the receiver’s mobile phone number (MSISDN) is used as an identifier which is only validated on registration there is the possibility that the payment receiver may not be the current MSISDN subscriber. Not all customers keep their existing phone number when they move network operators so a receiver may only be using a old phone number as an identifier. In the UK mobile number porting is ‘donor-led’ which requires the customer to initiate things by contacting the donor (first) network operator and asking for a Porting Authorisation Code (PAC code), which is needed to retain a phone number when switching. The customer must then give this to the recipient (second) network operator before things can proceed. If the receiver who changes networks initiates donor-led mobile number porting then all services linked to the mobile phone number will remain linked to the mobile number. But if the receiver who changes networks does not initiate this process then the PAYM account identifier is tied to an unused mobile phone number.
Mobile phone numbers that are not ported will eventually be recycled and made available to new customers. If the new ‘owner’ of the mobile phone number chooses to register with PAYM they may find that the number is already is use and all therefore be blocked from registering. There is no current process for claiming an already registered mobile number. The process for de-registration or mobile number change is first user driven: “Customers are able to de-register from the service at any time. To de-register customers can change their choice of payment account, the mobile number they have registered for the service and the bank or building society they have joined with at any time. To change your registration from one bank to another, you need to deregister through the bank or building society you have signed up with and then re-register with the new participating bank or building society. The payments council has not implemented a process for this use case.”
The PAYM service would be stronger if it were linked to a synchronous HLR registration service supported and provided by all UK Mobile Network Operators.
Smart M2M devices require authentication & registration with the mobile network. Standardisation of service is proposed by the ETSI Service Capability Layer deployed to the Mobile Internet Device / Gateway. Security between the network and the mobile internet device requires authentication, key agreement and establishment that enable M2M Service Bootstrap, provisioning and M2M Service Connection procedures that are grounded on a clearly defined key hierarchy of the M2M Node.
The European Telecommunications Standards Institute’s M2M Release 1 provides standardised security mechanism for the reference point mobile internet device. This architecture is based upon the following principles:
ETSI M2M adopted a RESTful architecture style with information represented by resources structured as a tree
ETSI M2M standardises resource structure that resides on an M2M Service Capability Layer (SCL) where each SCL contains a resource structure where the information is kept
M2M Application and/or M2M Service Capability Layer exchange information by means of these resources over the defined reference points
ETSI M2M standardises the procedure for handling the resources
The SCL is deployed to the M2M mobile Internet device (mId) / gateway and requires authentication & registration with the M2M network. ETSI M2M provides standardised security mechanisms for the reference point mId. Mobile Internet Devices/gateways hold secret keys protecting the connection in a “secured environment” and are provisioned with the key M2M Root Key (Kmr).
This requires using RESTful operations over the mobile internet device:
M2M Service Bootstrap: provision M2M service provider assigned ID & M2M Root Key (Kmr)
M2M Service Connection: mutual AuthN of mobile internet device end points & generation of M2M Connection Key (Kmc – derived from Kmr)
(Optional) Mobile Internet Device security: establishment of secure communication over mobile internet device based on Kmc (and sub-keys)
The Internet of Things, as distinct from the internet of people, requires communication between devices to enable home automation, telematics and health care monitoring. This intercommunication is dependent upon semantically structured and shared data for enabling functions such as identification, authentication, authorisation, bootstrapping and provisioning. Standardising both the semantically structured data and the enabling functions across M2M applications and devices would reduce the cost and extend the life of M2M devices. Standardisation for the Internet of Things is the aim of a common service layer for M2M.
There is no single internet definition for the Internet of Things, but to function as a network “Things” must have representation within the Internet. This representation includes structured data (e.g., status, capabilities, location, measurements) which needs to be semantic in order to be shared, processed and acted upon. The sharing and discoverability of information requires governance according to privacy settings and access rights. Because the Internet of Things (IoT) requires M2M application and device communication within minimal or no human involvement these privacy settings and access rights need to represent the delegated authority of the human user. Therefore M2M devices require bootstrapping of provisioned M2M service credentials (e.g. identities, M2M Root Key) which can be used for connecting and registering with different service layers and service authorities.
M2M devices can be active such as Zigbee sensors or passive such as RFID tags. M2M devices can be connected to an MNOs network using eUICCs or can be connected to an IP extending personal area network (e.g. Zigbee gateway). The ETSI principles for M2M & smart device communication are RESTful resource oriented APIs that are IP based but interwork with specific IP and non IP technologies in the M2M Area networks. The variance between device communication mechanism (IP & non-IP) and behaviour (passive vs active) makes defining an embeddable M2M common service layer a challenge.
The oneM2M group aims to develop technical specifications that address the need for a common M2M Service Layer that can be readily embedded within various hardware and software, and relied upon to connect the myriad of devices in the field with M2M application servers worldwide. The common M2M Service Layer should be agnostic to underlying network technology (yet leveraging the unique features of these underlying networks), and it will use network layer services (such as security (encryption and authentication), QoS, policy, provisioning, etc.) through an adaptation layer/APIs.
The challenge for Authentication, Authorisation & Accounting in M2M will be to build trust between the human user and the delegated authority to the M2M device. In order for an embedded common M2M service layer to operate it must support AAA (authN, authZ & accounting) for smart devices using an agreeable mechanism between multiple device manufacturers and network operators. The Telecommunications Industry Association are defining a functional standard for Authentication, Authorization and Accounting for Smart Device (AAA-SD TIA) which is encapsulated in TIA TR-50 Functional architecture for M2M Smart Device Communication System Architecture describes AAA-SD as ” provide authentication, authorisation and accounting services to other entities in the network to establish and enforce security policies. The services may include generation of keys, generation and validation of certificates, validation of signatures, etc”. The functions proposed by the oneM2M service layer must align with TIA TR-50.
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…
GSMA Official Document 12FAST.13 – Embedded SIM Remote Provisioning Architecture published in December 2013 provides a technical specification to enable the remote provisioning and management of Embedded SIMs to allow the “over the air” provisioning of an initial operator subscription and the subsequent change of subscription from one operator to another. The technical specification includes technical use cases for the provisioning of the Embedded Universal Integrated Circuit Card. The following are worked examples of business use cases for M2M provisioning.
Use Case #2: Corporate Customer Fleet Management Change MNO
Pamela wishes to upgrade the telematics capabilities of City Deliveries’ existing vehicles. The existing vehicles are after-market fitted with an M2M device including an eUICC embedded SIM provisioned to MNO B.
Pamela wishes to migrate these subscriptions from MNO B to MNO A to take advantage of dedicated telematics software provided by MNO A.
Use Case Flow:
City Deliveries enters into a subscription with MNO A for the after-market devices
MNO A knows the eUICC-IDs for the devices and the ID of the registered SM-SR
The eUICC is registered with a common SM-SR between MNO A and MNO B
MNO A initiates provisioning of the devices
MNO A initiates the Profile Download and Installation which results in an ISD-P created in the eUICC for the MNO, containing a Profile in disabled or enabled state. The SM-SR has updated the EIS for this eUICC accordingly.
MNO A activates the subscription and all the devices are operative with MNO A
MNO B initiates de-provisioning for all the eUIDDs
MNO A’s profile is cleared from all devices
Alternative Flow (Step 3): The eUICC is registered with a different SM-SR
Note: To allow remote access to the eUICC the eUICC Manufacturer (EUM) registers the eUICC at a selected Subscription Manager Secure Routing (SM- SR). This means that related information which is relevant throughout its further lifetime, in particular the Platform Management Credentials, Provisioning MSISDN, are stored in the SM-SR database. Without this step, remote access to the eUICC will be impossible
If MNO A manages their profiles with a different SM-SR than MNO B then the management of the eUICCs will be handed over. In this case SM-SR X will request the necessary data to manage the eUICCs (e.g. the appropriate access credentials, characteristics of the eUICCs, previous SM-SRs) in the M2M devices from SM-SR Y. SM-SR X will not want the SM-SR Y to have knowledge of the eUICC profile management credentials it will have. Therefore SM-SR Y and SM-SR X perform a change of eUICC management responsibilities involving the eUICCs in the process. As a consequence SM-SR X becomes the entity managing the eUICCs on behalf of the MNO A.
penID Connect, it’s likely that the client will both have buttons for popular servers as well as a text field for user entry of an email address or URL. (OpenID Connect does not directly solve the “NASCAR” problem).
API Crazy 