Category: Identity Management

Remote Control Soufflés: Challenge of M2M Authentication & Authorisation and Mobile data offloading

mustnotgrumbleLeave a comment

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.

Remote viewing would decrease flop rate
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.

Open ID Connect and GSMA Mobile Connect

mustnotgrumble1 Comment

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.

PAYM and Donor Led Mobile Number Porting Use Case

mustnotgrumble1 Comment

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.

The Future of Identity Management According to CoTS Vendors Part 1

mustnotgrumbleLeave a comment

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

  1. Identity and access management has traditionally focused on managing user accounts in the form of directory service entries – the traditional IAM/IdM view
  2. 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.
  3. 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
  4. 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
  5. 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…

Embedded SIM SM-DP & SM-SR

mustnotgrumble1 Comment

The GSMA has united the mobile operators and SIM suppliers behind a single Embedded SIM specification to avoid costly, fragmented & incompatible technical solutions and help accelerate the M2M market.  In order to support M2M use cases with no human intervention and to facilitate the secure over the air installation of mobile operator credentials into a SIM, two new key network elements have been specified by the GSMA:

Subscription Manager Data Preparation (SM-DP):

  • Role that securely creates and encrypts operator Profiles and then securely installs them into the eUICC
  • The SM-DP securely packages profiles to be provisioned on the eUICC. The SM-DP manages the installation of these profiles onto the eUICC
  • The Profile Enabling procedure between the MNO and the SM-DP is used to enable a Profile previously downloaded and installed on an eUICC. The procedure is initiated by the MNO owning the Profile to be enabled.

Subscription Manager Secure Routing (SM-SR)

  • Role that which enables secure download, enablement, disablement and deletion of Profiles on the eUICC
  • The SM-SR ensures the secure transport of both eUICC platform and eUICC profile management commands in order to load, enable, disable and delete profiles on the eUICC

Certificates & Credentials:

  • The Embedded Universal Integrated Circuit Card (eUICC) Certificate is issued by the eUICC Manufacturer for a specific individual eUICC and is certified by the eUICC Manufacturer Certificate which are issued to a GSMA accredited eUICC Manufacturer.  The eUICC Certificate enables eUICC authentication and certification to other entities; the authenticated key set establishment between a SM-DP and an eUICC and authenticated key set establishment between a SM-SR and an eUICC
  • Download and installation are protected by Profile Installer Credentials shared between the SM-DP and the Issuer Security Domain Profile
  • The architecture of the eUICC and its remote Provisioning system complies with the requirements of 3GPP TS 21.133 [21133] “3G Security, Security Threats and Requirements”

5 Key Architectural Considerations on Implementing Identity and Access Management for M2M

mustnotgrumbleLeave a comment

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.

 

Salesforce Identity Connect to Other Directory Services

mustnotgrumbleLeave a comment

Identity Connect is a charged extension to Salesforce Identity that enables an organisation to use their existing directory services.  It specifically allows integration to Active Directory and enables the upload of user data from Active Directory to one or more Salesforce organisations, and automatically to synchronise this data when user entries are added, changed, or removed. In addition, Identity Connect enables single sign-on (SSO) to Salesforce, using the Security Assertion Markup Language (SAML)

 

Identity Connect is built on top of ForgeRock Bridge Service Provider Edition which is deployed as an on-premise identity service with a browser-based admin UI and acts as an identity bridge between Salesforce and the Enterprise’s active directory.   The ForgeRock Bridge Service Provider Edition does not only support Active Directory Synchronisation but can provide Identity Synchronisation to other Directory Services and provide “Real-time, automated user account synchronisation between enterprise and cloud services”.

The majority of Active Directory usage is for internal enterprise staff and as such partners may be managed in other directory services.  Therefore it is not unreasonable to ask when Salesforce will extend Identity Connect to support other directory services.

Cross Domain Identity Patterns: Mapped Federation

mustnotgrumbleLeave a comment

With Mapped Federation users need to exist in both the identity provider and the service provider. As per transient federation a metadata exchange contract is defined between the identity provider and the service provider. With Mapped Federation further attributes for uniquely identifying the user are required. This may be the UID (e.g. email address) that identifies the authenticated user in the identity provider’s IdP Identity and the service provider’s Local Identity

fed3

Advantages:
User record can be mastered externally while still controlling access to a limited number of resources (e.g. seat based licensing model)
Model is suitable for splitting authentication from authorisation in legacy applications

Disadvantages:
Mapped Federation often needs a joiners and leavers process such as Just In Time User Provisioning or SCIM

Examples:
Salesforce.com

Cross Domain Identity Patterns: Chained Federation & Service Broker

mustnotgrumble1 Comment

Chained Federation allows access to multiple Service Providers to be granted to multiple trusted Identity Providers. The identity provider request access to the service provider via the Service Broker which authorises the request and forwards to the appropriate service provider based on the TargetURL. This is useful where an enterprise is providing multiple services to multiple customers (identity providers) and does not want to manage many to many relationships.

fed2

Advantages:
Externalise trust to external identity providers who bear cost of on-boarding users. User can choose their identity provider.

Requirements:
Agreed contract with identity provider.

Challenges:
In an enterprise implementation further data may be required to decorate the user and assign role or permission (see Mapped Federation)
The Service Broker needs to maintain the service provider targetURL and the service broker URL. In an enterprise implementation this is often best provided as a service.

Examples:
UK Government Gateway
3 Legged OAuth implementation (e.g. Twitter)

Cross Domain Identity Patterns: Transient Federation

mustnotgrumbleLeave a comment

A transient federation agreement is a pre-negotiated (trusted metadata exchange) set of contracts (normally bilateral) which enable trusted pairs to recognise each other’s identities. The contract may specify user roles, governance, security and verification policies, or specific technical methods. The implementation may utilise a Trust Broker (possibly a 3rd party credential authority) for validating the relationship. Organisations with similar goals or structure create a standard agreement rather than negotiating individually.

Fed1

Suitable for when two trusted parties can agree a contract on roles, governance and security policies. Improved by a semantic pull model. Limited by transient federation requiring role definitions to be maintained.

Next: Mapped Federation

Implementations:
System for Cross-domain Identity Management Scenarios
SAML 2.0