In today’s web environment the authentication of users is a very frequent task. Users are asked many times to enter repetitive information in order to create yet another account. But their digital identity on ad hoc systems might be only protected by a very thin security layer that is prone to online attacks and intrusions. Plus, for each website where a user creates an account, they need to remember their distinct credentials and ensure that their credentials are strong enough and not prone to brute force network attacks.
To address these concerns, the OpenID standard was created to allow users to use an existing account to sign into multiple websites, without needing to create or remember new passwords. With OpenID, you provide your password to your third-party identity provider and that OpenID provider confirms your identity to the websites that you sign into. After you create an account with your preferred OpenID provider you use it for signing on to any website which accepts OpenID authentication. By authenticating users through third-party services, this open standard eliminates the need for webmasters to provide their own systems to handle the authentication and allows users to consolidate their digital identities.
OpenID vs. oAuth
While there are some similarities between the two standards, OpenID’s role is strictly limited to being an authentication provider. As such, it simply confirms that you are who you say you are, and its responsibility stops there. On the other hand, oAuth functions as an authorization provider. That means that oAuth gives you controlled access to third-party resources that are not part of the consumer application without providing it with user name and password.
As an example, Google’s OpenId authenticated token only tells a web application that the user is who the user claims to be whereas an API provided by Google will give a third party limited access to, say, your Google Calendar API provided that you grant access to it explicitly. Other OpenId providers include Yahoo, Blogger, Flickr just to name a few.
OpenID facilitates username and password management while making it possible to ensure that users manage their logins with a trusted authority. Let’s look at an example which shows how such an authentication method can be applied to an element management system.
OpenID for Authentication: An Example
Element management (or FCAPS) applications deliver vital and high volume data at high speed to Operation Support Systems (OSS) to help network operators control cost, increase revenue and provide exceptional end customer experience.
Fault, capacity, operational measurement and billing data of a service providing node is aggregated by the dedicated element management application. The FCAPS data is then stored into files (or other formats) and forwarded to the OSS. The data exchange usually depends on simple authentication with password or sometimes no authentication.
File transfer protocols require password tokens to authenticate the FCAPS applications with the target OSS system. A secure file transfer protocol ensures data is encrypted during transfer. However, the passwords stored in the element manager disk are vulnerable to theft.
At the element management level, there is often no centralized design mechanism for storing the OSS passwords. Such passwords are only entered once into the element manager during configuration time. The passwords are stored based upon individual security requirements. The password could be encrypted while it is stored on disk. However, the element manager disk could be replaced or hot swapped out of the system. In such a scenario, the encrypted password could be deciphered with sufficient time and the OSS is then vulnerable to attack or unauthorized access. Alternatively, we can use a public/private key based authentication, however provisioning a key-based mechanism on an element manager is cumbersome. Moreover, losing the private key creates the same vulnerability as the previous scenario.
Using OpenID as an ID management protocol can eliminate the need for storing passwords of OSS systems on each element manager node in the network. The trust between the OSS and the element manager is established via an independent centralized security server. The operator security server is trusted by the OSS systems and the security server is usually security hardened against attacks.
The key advantages of implementing the OpenID protocol at the node level are:
- Reduce unwanted passwords exposure in the operator network running FCAPS applications.
- Eliminate chances of defective software design for handling password. Not all programmers and testers have the same level of awareness on how to handle OSS passwords. With OpenID, OSS passwords no longer need to be stored on the element manager disk.
- Establish trust between the network level security server and the element manager independently without being tied to a particular transfer protocol and a type of application.
By implementing the OpenID standard protocol at the element management system level, password security can be improved and the need for additional systems and processes can be eliminated.