MAGAZINE
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
establish his identity. An authenticator<br />
always uses a device that has an MSISDN<br />
(that’s the phone number in plain English).<br />
This is the first clever bit of Mobile<br />
Connect. The MSISDN can be considered<br />
as a unique attribute or identifier.<br />
Online services connect to an operator<br />
Identity Gateway using the standardized<br />
Mobile Connect protocol. The Identity<br />
Gateway connects to the authentication<br />
server. The authentication server takes care<br />
of the actual authentication event by<br />
sending the authentication request to the<br />
authenticator and validating the response.<br />
The type of authenticator(s) selected by the<br />
operator defines what kind of<br />
authentication servers are required.<br />
Sometimes the Identity Gateway and the<br />
authentication service come from different<br />
vendors. The selection of authenticators is<br />
a local issue.<br />
As the communication between the online<br />
service provider and the identity gateway<br />
is standardized, it is straightforward to<br />
connect online services and identity<br />
gateways on a global scale.<br />
Mobile Connect is federated<br />
The second clever part of Mobile Connect<br />
is in the federation. Federation is a<br />
technology (and agreements) that allow<br />
users to move between independent<br />
domains without re-authentication. In the<br />
Mobile Connect concept, it allows a<br />
subscriber of an operator in India for<br />
example, to log into an online service in<br />
the UK. The key to this capability is<br />
something called the discovery service.<br />
The normal scenario is that the online<br />
service provider is connected to the GSMA<br />
Discovery Service (and the Identity<br />
Gateway). This discovery service provides<br />
the login screen for the end user where the<br />
phone number will be typed in by the user.<br />
Now for the magic part. The discovery<br />
service will check the phone number<br />
and… erm… discover that it belongs to an<br />
India based operator and routes the<br />
authentication request to the home<br />
operator of the user. The home operator<br />
then pushes the authentication request to<br />
the user's mobile device and the user<br />
authenticates Simple.<br />
Enabling the Subscriber<br />
When the operator decides to deploy<br />
Mobile Connect they will first have to<br />
build the infrastructure. So they<br />
acquire/build an identity gateway and<br />
choose appropriate authenticators for their<br />
subscribers. Deploying the hub of the<br />
solution, the identity gateway can be done<br />
the easy or the hard way. The easy way<br />
could be for example using Global Sign<br />
Identity Gateway as a managed solution.<br />
This can be up and running in two hours<br />
after we receive the call. The hard way is<br />
to do it in-house and create a development<br />
team, try to pass the conformance tests and<br />
maintain the in-house solution as the<br />
protocol develops and new features are<br />
added over time.<br />
Then it’s a question of selecting the<br />
authenticator(s). The chosen authenticator<br />
is dependent on the market situation and<br />
what the subscribers can utilize. There are<br />
authenticators options that rely on SMS<br />
based technologies and won’t require<br />
anything extra to be installed to the user’s<br />
phone. The next category would be an<br />
authenticator that involves an installation<br />
of a small SIM based application, but still<br />
using SMS based communication. The<br />
larger SIM applications, for example PKI<br />
based operations, typically require a new
Change language