A Scottish Safe Harbour for Identity Management

Tags

, , ,

The Data Protection Directive (officially Directive 95/46/EC) regulates the processing of personal data within the European Union and also provides the criteria for Safe Harbour privacy for companies operating within the European Union. The Safe Harbour regulations  forbid sending of customer’s personal data to countries outside the European Economic Area unless there is a guarantee that it will receive adequate levels of protection. There are no Safe Harbour considerations for EU companies with services deployed to Scotland while Scotland is part of the UK and when Scotland has become independent of the UK and joined the EU as an independent country. However there may be a period of time between Scotland becoming independent and joining the EU (as an independent country) when Safe Harbour requirements really matter. At this time no EU company will have a Safe Harbour agreement with the newly independent Scotland. Therefore any company with Identity Stores (or business systems containing personal data) deployed in Scotland will be in breach of the Data Protection Directive. Scotland Id Store 7 PNG

Continue reading

Some Identity Standard Factoids

Tags

, ,

The following are some interesting security factoids that point towards the benefit of a mobile 2FA (Over the Air or Wireless Public Key Infrastructure) federated identity model:

  • The most commonly used password in the English speaking world is ‘123456’. Previously it was ‘password’
  • An average UK internet user has five different username and password combinations that are used over an average of 25 different sites
  • 4.5 billion compromised records, the size of the CyberVOR breach is the number of service compromised from each pair of compromised credentials
  • 1.2 billion of the CyberVOR credentials are meant to be unique, belonging to over half a billion e-mail addresses
  • In 2009 OpenID announced that there were over 1 billion OpenID enabled accounts (a number that has certainly increased) that can be used for federated authentication
  • 60% of all cases of fraud perpetrated against individuals is personal data theft
  • $12 billion: size of mobile identity infrastructure market by 2019

Single Identity Repository for Internal Staff, Partners & Customers and Security Zones of Control

Tags

,

It is not impossible to have a single user directory tree for internal users / staff, partners and customers. All that is required is unique identifiers and different levels of permission normally managed through group membership. However pretty much every organisation quite rightly separates these groups as independent trees. These independent trees are normally realised as independent directory implementations thus providing security through isolation and security zones of control. This though has not stopped me being recently asked within a large organisation if it is not possible to have a single identity management solution.

This was an evident confusion between identity management solutions and directory structures. For which I drew two examples: the first was an example directory structure (below), for ACME_Corp and my test user Chester Drawers, showing how quickly a single directory structure would become very complicated.

Single Tree Model

An Extreme Example of Single Identity Tree for Employees, Partners & External Users

Continue reading

4.5 billion CyberVor records and Trusted Identity Federation

Hold Security have announced that the CyberVor gang (dubbed by Hold Security with “vor” meaning “thief” in Russian) has amassed over 4.5 billion records, mostly consisting of stolen credentials. 1.2 billion of these credentials appear to be unique, belonging to over half a billion e-mail addresses. To get such an impressive number of credentials, the CyberVors robbed over 420,000 web and FTP sites.

In 2009 OpenID announced that there were over 1 billion OpenID enabled accounts. That number that has certainly increased even if some have migrated to OpenID Connect (e.g. Google). OpenID & OpenID Connect can be used as Identity Providers that provide trusted identities to other websites / services that are relying parties. The same would also be true for SAML based Identity Providers.

Continue reading

Considering Various Active Directory and Oracle Identity Manager Integration Options

Tags

, , , ,

There are a number of different ways of integrating different versions of Microsoft’s Active Directory (including ADFS & FIM) with different versions of Oracle’s Identity Management suite. Unfortunately for the implementer there is very little published architecture best practice covering identity migration / integration. This is surprising because of both vendors’ large market share and the annual number of organisations’ switching products or adding new features using the other vendors software. As an example the following migration / integration options are available when moving from AD to Oracle.

  • You can choose to keep the existing AD as a master identity repository and use Oracle Identity Manager connector between the two products.
    • The connector supports Active Directory and Active Directory Lightweight Directory Services (AD LDS), formerly known as Microsoft Active Directory Application Mode (ADAM) as either a managed target resource or as an authoritative (trusted) source of identity data for Oracle Identity Manager
    • Depending on this approach you may wish to synchronise user’s password from Microsoft Active Directory (AD) to Oracle Identity Manager (OIM) then you must install Microsoft Active Directory Password Synchronization connector

Continue reading

Why the Future of Identity is OpenID Connect and not SAML

Tags

, , ,

This blog is part of a series comparing the implementation of identity management patterns in SAML and OpenID Connect:

Future of Identity Federation is OpenID Connect

Identity management is an enabler for networked services whether web browser, mobile or smart-tv applications or the internet of things. The increase in services will create an increase in passwords without mechanism for sharing & trusting identities. eGovernment services require a higher level of identity verification than the social authentication capabilities of Twitter & Facebook connect. The future of eGovernment Identity is an interoperable authentication and authorisation capability that can support higher levels of identity verification.

The importance of interoperability amongst identity solutions is that it will enable individuals to choose between and manage multiple different interoperable credentials. Futhermore service providers will choose to accept a variety of credential and identification media types. “Identity Solutions will be Interoperable” is a guiding principle of the US National Strategy for Trusted Identities in Cyberspace (NSTIC) which is a White House initiative for both public & private sectors to improve the privacy, security, and convenience of online transactions.

SAML is insufficiently interoperable to be the future standard for identity management federation. SAML is limited in its ability to support mobile & smart-TV applications and requires the implementation of a complex Broker Service in order to support multi-service provider & multi-IdP use cases.

OpenID Connect will most likely supersede SAML for all eGovernment externalised identity management. OpenID Connect is a lightweight identity verification protocol built on top of modern web standards (OAuth 2.0, REST and JSON) superseding OpenID 2.0. OpenID Connect allows a service provider (Relying Party) to select between a variety of registered or discovered identity providers. OpenID Connect can satisfy all of the SAML use cases but with a simpler, JSON/REST based protocol.

SAML OpenID Connect Comparison

SAML 2.0 & OpenID Connect comparison

Continue reading

Identity Broker Service in OpenID Connect: Supporting Multiple Identity Providers & Service Providers

Tags

, , , ,

This blog is part of a series comparing the implementation of identity management patterns in SAML and OpenID Connect:

Identity Broker Service in OpenID Connect

In an earlier blog post (Identity Broker Service in SAML) described how to support connections between multiple service provides and multiple identity providers by building an Identity Broker Service. This service presents the user with a list of identity providers supported by the service provider and then forwards a <saml:AuthnRequest> to the appropriate identity provider. The broker then maintains this connection and returns a <saml:Response> from the identity provider back to the service provider. The service provider accepts the <saml:Response> and trusts the end user. In order to build this model using SAML the identity broker service requires development and deployment to the internet and the sharing of keys between all service providers and identity providers.

Using OpenID Connect the same function can be built without the need for an intermediary broker service. This is because in OpenID Connect is designed with the user being able to select their preferred identity provider. The Identity Provider, also known as the OpenID Provider, renders the authentication challenge and gains user approval before sharing user attributes. OpenID Connect performs authentication to log in the End-User or to determine that the End-User is already logged in. OpenID Connect returns the result of the Authentication performed by the Server to the Client in a secure manner so that the Client can rely on it, hence the Client is called Relying Party (RP).

OpenID Connet without Hub

Continue reading

Identity Broker Service in SAML: Supporting Multiple Identity Providers & Service Providers

Tags

, , , , ,

This blog is part of a series comparing the implementation of identity management patterns in SAML and OpenID Connect:

Identity Broker Service in SAML

A federated organisation may have multiple distinct services (service providers) where each service is protected under a distinct trust domain. The same organisation may wish to trust multiple external & internal identity providers and allow the end user to select their preferred identity provider. Furthermore the same federated organisation may require greater levels of certainty for specific services and may wish to limit the available identity providers for a specific service or enforce step-up authentication on the identity provider. This pattern is useful for governments and enterprise’s wishing to move away from a Push Model for Enterprise Identity Architecture.

In order to support multiple services and multiple identity providers and possible multiple rules an Authentication Broker Service is required. This model is often known as either a Hub Service or Chained Federation. The following sequence diagram explains how the pattern would working using <saml:AuthnRequest> (SAML 2.0) and <saml:Response> between four parties (User Agent, Service Provider, Authentication Broker Service and Identity Provider):

SAML Hub Service

 

  1. The User Agent access a specific Service (There can be N+ service providers depending on the organisation)
  2. The Service Provider sends a <saml:AuthnRequest> to the registered Authentication Broker Service (limitation that an SP must be mapped to one Broker)
  3. The Authentication Broker Service holds a list of Identity Providers trusted by the Service Provider and returns this list to the User Agent
  4. The User Agent selects their preferred Identity Provider provided as a list by the Broker
  5. The Broker service generates a new <saml:AuthnRequest> which it forward to the selected Identity Provider
  6. The Identity Provider challenges the user agent
  7. The Identity Provider authenticates the user agent
  8. The IdP returns the <saml:Response> to the Broker for the authenticated principal
  9. The Broker returns the <saml:Response> to the Service Provider (which may choose to match against any mapped identity)
  10. The Service Provider grants access to the User Agent

Note a slightly different pattern would be to pass a reference to a SAML artefact between the Broker and the SP. This would use the <saml:ArtifactResolve> element in the message passed back from the Identity Provider. This pattern would require a direct service between the SP and the IdP to resolve the attributes in the artefact. This pattern extension is only recommended when the authentication request can be deferred when multiple profile attributes are required from the identity provider.

Example: UK Government Identity Assurance Hub Service SAML 2.0 implementing the OASIS SAML V2.0 Identity Assurance Profile

Nomenclature: Terminology differences between OpenID Connect & SAML

OpenID Connect Simple Sequence Diagram

Tags

The OpenID Connect protocol, in abstract, follows the following steps.

  1. The RP (Client) sends a request to the OpenID Provider (OP).
  2. The OP authenticates the End-User and obtains authorization.
  3. The OP responds with an ID Token and usually an Access Token.
  4. The RP can send a request with the Access Token to the UserInfo Endpoint.
  5. The UserInfo Endpoint returns Claims about the End-User.

These steps are illustrated in the following diagram:

OpenID Connect Sequence Diagram

OpenID Connect & SAML nomenclature

Zepp Sensor for Golf and Tennis: An Example of a Good App Strategy

Tags

, ,

People who know mzepp unite know that I am equally bad at both golf and tennis.

Because I’m keen on gadgets (and excuse all purchases as research into the internet of things), I had to purchase the new Zepp Golf sensor. The golf sensor attaches to the back of my golf glove and tracks my slow slices and off tempo hooks. I then purchased the tennis adapter which fits to the bottom of my tennis rack to track my off tempo serves and my slow sliced backhands.

What I find most interesting is how the sensor can be used for multiple sports. According to Zepp’s own documentation it is simple to swap between sports:

Your sensor will work with all 3 Zepp Sports Apps: Baseball, Tennis, and Golf. Simply download the mobile app of choice and attach the sensor to the appropriate racket, bat, or golf mount. To use the sensor for a different sport, connect your sensor to your mobile device and open the sport app of your choice. The app will ask you if you wish to change the sensor to the new sport mode. Select OK to begin change process

I really like this simplicity. Just download the app for the sport you’re going to play to the device or devices you use. I could imagine other firms over engineering the mobile applications so that they all linked to a single user account and a single self service operation would provision each individual sport.

Zepp’s model works well because the user just downloads what they need and can then work on cranking up the power of their forehands. Just wish mine would sometimes go in.