Author: mustnotgrumble

Enterprise M2M Use Cases: #1 Corporate Customer Fleet Management New M2M Order Provisioning

mustnotgrumbleLeave a comment

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 #1: Corporate Customer Fleet Management New Order

Pamela, the purchasing manager of City Deliveries purchases a number of M2M enabled vehicles for their company’s fleet.  The new vehicles include an embedded SIM provisioned to Mobile Network Operator A.

Pamela is happy as MNO A is there existing network operator and enters into a subscription with MNO A for the M2M enabled vehicle devices.

Use case flow:

  1. MNO A initiates the provisioning of a number of devices included in City Deliveries subscription
  2. MNO A already use Subscription Manager Secure Routing (SM- SR) to which the eUICC is registered and hence the SM-SR does not need changing.
  3. The MNO Profile is downloaded and installed to the eUICC by the SM-SD.  The ISD-P created in eUICC for MNO, containing profile in disabled state, SM- SR updated EIS.
  4. Target profile is enabled on the eUICC. As this is a new eUICC on the first MNO then no previously enabled profile requires disabling.
  5. MNO A activates the subscription

More detail is provided by the macro procedures 1, 2 & 3  in GSMA Official Document 12FAST.13 – Embedded SIM Remote Provisioning Architecture 

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.

Loops in Scala (Imperative & Tail Recursive)

mustnotgrumbleLeave a comment

The following are different ways of implementing simple loops in Scala

While loop

The Scala while loop executes a certain block of code, as long as a certain condition is true.

while(someObject.hasNext())
    process(someObject.next());
Do While Loop

The Scala  do while loop is similar to the while loop except the condition is executed after the loop body. This means that the loop body is always executed at least once.

var myInt : Int = 0; 
do { println("myInt = " + myInt); myInt+=1; } 
while(myInt < 10)
For loop

The Scala for loop also executes a certain block of code, as long as a certain condition is true. The i <- construct is called a generator. For each iteration it initializes the val i with a value.

for(i <- 1 to 10) println("i is " + i);
Omitting For

The 1 to 10 in the for loop is the Range type. To support Domain Specific Languages (DSL) the 1 to 10 is actually a method call that returns the Range type.

(1).to(10);
to vs. until

Keywords to and until can be used when creating a Range object. Inclusive to includes the last value in the range, and exclusive until leaves it out.

for(i <- 1 to 10) {
    println("i is " + i);  // prints 1-10
}

for(i <- 1 until 10) {
    println("i is " + i);  // prints 1-9
}

Tail Recursive loop

All of the above loop examples are imperative functions making use of iteration.  Scala as a functional programming language supports Recursion (tail in this example) and Iteration (as above). Because Recursion will fail if there is a finite call stack, Java, for example, prefers Iteration which holds the local variables called by the function. As a result Java provides for loops, for-each loops, while loops, do loops, arrays, Iterators, ResultSets, etc.

Scala supports Tail Recursion that can use the same stack frame by encapsulating the loop. Once the loop has completed Scala does not need the local variables anymore because it has completed all the encapsulated computations.  Scala can then reuse the exact same stack frame the next time it loops through the very same function. This limits Out of Memory exceptions and makes parallel processing easier.

def loopTailRecursive(iterator: Int, con: (Int) 
                      => Boolean, acc: List[Int]): List[Int] = {
  val suc = iterator + 1
  val temp = acc :+ suc
  if (con(suc)) loopTailRecursive(suc, con, temp) else temp
}
println(loopTailRecursive(0, (_ % 10!=0), Nil))

Scala provides the @tailrec method annotation which verifies that the method will be compiled with tail call optimisation. If it is present, the compiler will issue an error if the method cannot be optimised into a loop.

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

Identity Management Business Case Drivers for both Customer and Workforce

mustnotgrumble1 Comment

Developing a business case for identity management is often a challenge because there are not always immediate tangible benefits. Furthermore the legal or security need to maintain separation between customer and workforce will create overlap between architecture that may necessitate separate business cases. It is therefore important to explicitly align the business case with the enterprise architecture for identity management.

There are three main drivers of an identity management business case:
1. Risk and/or regulatory requirement business case
2. Operational improvement and/or cost savings business case
3. Business enablement business case (e.g. cloud or deperimiterisation)

Different categories of identity management system:
1. Customer identity management
2. Workforce identity management

Risk and/or regulatory requirement business case can include international regulatory requirements (e.g. International Safe Harbour Privacy Principles) or industry specific regulations (e.g. healthcare HIPAA/HITECH) or specific risks determined by a security audit. These drivers effect both customer and workforce identity management implementations.

Operational improvement and/or cost savings business case drivers include aggregation and simplification of existing identity management solutions, including identity through merger & acquisition. It is very hard to quantify the immediate FTE saving from simplification of identity management systems but a business case can easily be made from the aggregation of multiple workforce identity management systems.

In an organisation with multiple customer identity management systems (often from M&A) a business case can be made from both a cost savings perspective and from a business enablement perspective (e.g. cross-sell opportunities).

A business enablement business case can also include a workforce identity management solution where the employee is granted access to external systems through trust based deperimiterisation. For example securing data on business devices may come under a business enablement business case while supporting secure and encrypted BYOD may come under all three business cases.