Enable bring-your-own-identity authentication

Leverage security open standards using social networks to manage identity lifecycle operations

Social networking and user "identity fatigue" are forcing the enterprise to accept distributed identities as authentication avenues to its data and applications. In fact, according to ISACA, the international professional association focused on IT governance (see Related topics):

The "consumerization of IT" is one of the most important trends to impact IT organizations in recent years and is likely to increase in importance as the flood of new and more intelligent devices in the market continues and the typical worker becomes more mobile. This important trend is not just about new devices; it is about the entire relationship between IT and its user population. In addition, this trend introduces significant security issues because critical IT assets need to be available — securely — to an increasingly distributed and diverse user base that is using consumer devices of their own choosing. While the initial consumerization hype was focused on the bring your own device (BYOD) trend, we are now seeing the emergence of bring your own identity (BYOI). The rise of BYOI is being driven by users' "identity fatigue." Users have too many accounts, too many usernames and too many passwords. That makes the mere step of registering at a new site one anathema too many. When the competition is literally a click away, organizations must enable the easiest user experience possible or users migrate to sites that offer the simplest registration and login process. Thankfully, many web sites have moved quickly to accept identities from popular online identity providers like Facebook, Google and LinkedIn.

According to IDG Connect (see Related topics):

  • The primary and secondary source of identity for consumers is social media (21%).
  • 58% of European businesses currently open their applications to external users.

The result is bring-your-own-identity (BYO-ID), the ability to use and secure a user's existing social media ID within your enterprise system.

In this article, we describe a method for leveraging security open standards for identity lifecycle operations in business to consumer channels; these operations include BYO-ID authentication and user registration. You'll get an understanding of how to implement authentication and registration patterns with popular social and cloud providers by leveraging product capabilities within the IBM Security Systems solution offerings. To see a video demonstration of BYO-ID in action, see, "Self-registration and bring-your-own-identity using Tivoli Federated Identity Manager."

Background on BYO-ID

First, let's explore some of the background behind implementing BYO-ID, including how enterprise user accounts and access are managed, what the open standards for authentication and identity control are, and how authentication assurance is impacted by BYO-ID.

Internet account lifecycle management

The process for managing user accounts and access within business enterprise is well known. It normally includes the use of an identity management product, such as IBM Security Identity Manager, and focuses not just on the account management operations. The influence of cloud computing and associated online identities is changing the way enterprises view and approach account provisioning and management for business-to-consumer environments.

In Internet-based business-to-customer scenarios (B2C) in which online services mandate patterns for registration, de-registration, and account management, a much simpler, less onerous solution can be applied. Many smaller social and cloud offerings do not build their own solutions, but rather leverage larger social networks' authentication capabilities to offload password management. This trend moves away from the traditional online registration process that relies on the user filling in web forms with all of their personal details and instead, users are now becoming accustomed to the idea of working with existing social networks to bootstrap their registration process at new offerings. The social network component of BYO-ID includes allowing users to take their existing social media accounts (Google, Facebook, Twitter) with them to new services to reduce the manual tasks associated with traditional account registration.

Enterprise customers are also coming to expect these capabilities to be a part of the enterprise account registration processes. To accelerate user adoption of B2C services, enterprises are also considering how to simplify online registration processes. Although an enterprise might not trust social networks to provide single sign-on (SSO) to their internal services, B2C integration scenarios must consider catering for similar flows, even if it means asserting a lower level of trust to such authentication events.

BYO-ID open standards

Security open standards are developed primarily for vendor interoperability, and this aspect is most important in the arena of large social and cloud vendors. There would be simply no way that these services could provide the value that they do without reliable interoperability standards. Similarly, in a B2C environment, adoption increases if legal and business agreements between entities is not required.

Access management open standards adoption has accelerated, largely due to the support (and development) of standards by social network giants like Twitter, Facebook and Google. The patterns described in this article refer to the following open standards:

  • SAML (1.x-2.x): Security Assertion Markup Language is a standard to achieve user identity federated SSO and provisioning. It documents on-the-wire protocol standards for exchanging authentication data between secure domains; that is, between the user or process that provides the identity (a producer of assertions) and a service provider (a consumer of the assertions).
  • OpenID: An open standard that describes how users can be authenticated in a decentralized manner. It provides a way for users to consolidate their digital identities by having a single OpenID when connecting to different websites. Effectively, it eliminates the need for services to maintain the password for an identity locally. The primary difference between SAML and OpenID is that SAML mandates a federated trust between the Identity and Service providers, prior to a system being available, whereas OpenID does not. There are other differences, but these are the major ones.
  • OAuth (Open Authorization): An open standard that provides delegated authorization. It offers a way for users to share personal resources on a resource-hosting site with a third-party entity in a delegated fashion. In this standard, a user's authentication information (for example, password) is never shared with this third-party entity.

Authentication and trust

Enterprises tend to require a high level of business and legal agreements to trust third-party services verifying users' identities. This is particularly the case when these organizations operate financial services or in other heavily regulated government fields. This is an important distinction from social business where services are provided, free or at low cost, to a large set of users. This business model focuses on increasing user interaction between services; service trust (from the user) is in some cases nonexistent.

One thing you must consider is that registration of an online social business provides no basis for trusting that a single individual is accountable for that registration. Therefore, social identities can be used to authenticate to another service provider or organization, but it may be necessary to restrict the access or operations that they can perform without requiring additional or a second form of authentication. At the very least, the service provider who trusts this model must have some pre-existing relationship with the individual so they can increase the authentication assurance (for example, username/password) if it is needed.

In this article, we will also show you how authentication mechanisms are used to transition through different registration states within a BYO-ID scenario. These mechanisms can allow an enterprise to assign an authentication level to social authentication events so that a security policy can then be used to control what access such sessions allow.

Products and services relevant to BYO-ID

Let's focus on BYO-ID integration patterns that can be implemented using the IBM Security Systems solutions, including the solution components and open standards that are leveraged to implement the BYO-ID use case. The relevant IBM Security Systems product capabilities include:

  • Point of contact for web security
  • Federated SSO
  • User self-care
  • One-time password authentication service

Let us take a further look into the relevant products and features for implementing BYO-ID.

IBM Security Access Manager Web Gateway Appliance

IBM Security Access Manager Web Gateway Appliance is a single sign-on appliance that provides web application firewall capabilities. Web Gateway Appliance provides a web reverse proxy security solution with centralized user access management to deliver highly scalable user authentication, authorization, and audit services to web applications. It provides policy-driven web application vulnerability protection by leveraging the intelligence network provided by the IBM X-Force team.

Web Gateway Appliance can also be implemented as a front-end load balancer for Web Gateway Appliance deployments. IBM Security Systems WebSEAL software provides the proxy capability within this device.

From a BYO-ID standards perspective, Web Gateway Appliance provides the point of contact for federation standards, an authorization framework that supports the OAuth standard, and delivers support for various authentication mechanisms.

IBM Tivoli Federated Identity Manager

IBM Tivoli Federated Identity Manager provides a loosely coupled model for managing identity mediation between vendors, partners, or security domains. It provides this solution by delivering to the range of open standards within WS-Security and the Federated SSO arena. The following section outlines the relevant subcomponents of Tivoli Federated Identity Manager for the BYO-ID use cases.

User Self-Care capability

The User Self-Care (USC) capability allows users to self-manage online accounts. USC provides a solution to easily provision user accounts into and subsequently allow self-service of accounts in B2C environments.

USC provides a set of operations that let users manage their own account lifecycles. Table 1 shows the operations that are supported by USC.

Table 1. Tivoli Federated Identity Manager User Self-Care (USC) Operations
User Self-Care operationsDescriptions
User registrationUser can establish an account on the Internet by executing the enrollment workflow.
User ID existence checkOn the initial enrollment page, a button is provided for the user to click to determine whether the user ID entered in an associated field already exists in the registry.
Password changeCan be user-initiated to perform password change operation or auto-initiated due to password expiration.
Profile managementAllows customers to manage extended information specific to their account such as address or contact phone number.
Forgotten user IDTo recover the customer's forgotten user ID.
Forgotten passwordTo recover the customer's forgotten password.
Account deletionTo deactivate or delete the customer's Internet account.

To get more information about the IBM Tivoli Federated Identity Manager User Self-Care capability, see Related topics. From a BYO-ID perspective, Tivoli Federated Identity Manager USC can provide registration capabilities that let a user not only bring their identity information into a registration sequence, but also set username/password and secret questions and answers. Such registrations allow an enterprise to also apply additional authentication assurance when the customer wants to perform higher-valued transactions.

Federated SSO support

IBM Tivoli Federated Identity Manager provides support for Federated SSO. For the BYO-ID scenario, Federated SSO standards are used for both bootstrapping registration of B2C accounts as well as for authentication based on standards (and other methods). Tivoli Federated Identity Manager also supports a wide range of open standards such as SAML (1.0, 1.1, and 2.0), OpenID, OAuth, and WS-Federation. From a BYO-ID perspective, Tivoli Federated Identity Manager Federated SSO provides standards-based support for federated single sign-on from social providers into an enterprise.

One-time password authentication service

Tivoli Federated Identity Manager provides a one-time password capability (OTP) that can be implemented through configuration. This capability leverages the same integration framework as both the USC and Federated SSO capabilities, therefore minimizing the skills cost of managing and deploying different components within Tivoli Federated Identity Manager.

Common OTP integration patterns have already been implemented using email, 3G/4G Short Message Service, and HMAC, or software-based tokens such as Google Authenticator. The Tivoli Federated Identity Manager solution can be configured to assign different assurance levels to authentication events. In the case of BYO-ID, federation events (like SAML 1.x) may be assigned a lower authentication assurance level than password or OTP.

BYO-ID implementation patterns

A typical web user today has too many online accounts and too many usernames and password combinations to manage. At times, the thought of needing to register a new account for a website can be seen as one too many. Fortunately, many websites today are recognizing this and are moving quickly to embrace the pattern of BYO-ID. This pattern lets customers use their existing online identities from popular online identity providers to authenticate with little or no registration process.

Table 2 lists some popular social networks and the open standard supported by the social network provider. We'll explore BYO-ID solutions for these standards later in this article.

Table 2. Social network support for open standards
Social networkRelevant open standard
GoogleOpenID and OAuth

At the time this article was written, the listed standards were supported as documented, but they are subject to change, so refer to the social network provider's website for the most up-to-date open standards support.

For the remainder of this article, we will reference and discuss some of the listed social media providers to help illustrate the implementation pattern for BYO-ID using IBM Security products.

Authentication using social

Authenticating to a website using BYO-ID brings a range of benefits to both customers and the enterprise (or service providers):

  • By allowing consumers to utilize their existing online identity from Facebook or Twitter to authenticate to a website, it results in users needing to remember or manage one less password or one less account.
  • For service providers, BYO-ID results in having very minimal account administrative responsibility by eliminating the user account provisioning process and on-going password management operations. In cases where the enterprise wants to reduce the registration overhead, they can pre-fill information that would otherwise need to be typed. This also allows the enterprise to capture additional authentication data, such as Q&A and mobile phone number, so that the service provider may invoke higher levels of authentication.

Using IBM Security products to achieve the BYO-ID authentication pattern will help enterprises to reduce effort, time, and administrative cost by leveraging the same Federated identity management product for SSO and USC.

Figure 1 captures the high-level workflows of BYO-ID authentication pattern using IBM Security products:

Figure 1. BYO-ID authentication workflow overview
BYO-ID authentication workflow overview
BYO-ID authentication workflow overview

The Security Access Manager component in Figure 1 incorporates Web Gateway Appliance, a User registry, and Tivoli Federated Identity Manager. The presented workflow is based on the concept of allowing customers to indirectly authenticate to their target website (service provider) with their existing account from a chosen identity provider. Effectively, the authentication process is delegated to the chosen identity provider.

As far as the user is concerned, they are only aware of using their online social identity to log in. Consequently, the credential issued by the selected identity provider lets them seamlessly authenticate to the targeted enterprise website. More technically astute users would be aware that under the covers there are registries that exist within the service provider that stores the account information (but not the password); this provisioning aspect is not shown in Figure 1.

There are a number of open standards that can be used to achieve this solution pattern. We will briefly discuss some of the appropriate open standard profiles that may be used.

Federated SSO authentication with SAML just-in-time provisioning

Security Assertion Markup Language (1.x/2.x) supports just-in-time provisioning, allowing new regular customer accounts to be created on the fly when they first log in to a service provider website. The need to create or pre-provision user accounts in advance is eliminated. This reduces the time and effort with on-boarding accounts because the account creation process occurs automatically when the user first signs in.

Using SAML requires an explicit trust between the enterprise site and the online identity provider. SAML offers a strong support for XML signature and XML encryption for message-level security. Typically, it requires a high level of trust or pre-configurations between parties exchanging authentication and authorization data. BYO-ID authentication with SAML just-in-time provisioning is the act of achieving Federated SSO using SAML through BYO-ID. Should you be interested in implementing a solution using SAML Just In time Provisioning, refer to Related topics to find the article that explains how you may achieve this with IBM products.

Using OpenID for BYO-ID authentication

OpenID is a popular open standard that can be used to achieve BYO-ID authentication to enterprise websites. It allows customers to use their existing account to authenticate to multiple target websites (replying parties) without needing to create a new password for each endpoint.

It provides a way to consolidate a customer's digital identities by having a single OpenID and being able to connect to the different websites with that single entity. A key aspect with OpenID is there is no need for a pre-configured trust relationship between the relying party and the identity provider. To achieve BYO-ID authentication, customers simply select their preferred OpenID identity provider to authenticate to the enterprise website.

  • SAML is recognized more as an industry open standard to serve customer cross domain authentication and authorization between identity and service providers.
  • OpenID may be considered more convenient and flexible to customers as it lets them select an identity they already have and authenticate to a web environment that supports the standard.

In Related topics, you'll find an article that will help you investigate how to implement a solution utilizing OpenID as an alternate means to authentication to an enterprise website using IBM products.

Federated single sign-on with OAuth

Another well-known open standard that can be used to achieve social network authentication to enterprise websites is OAuth. This is an open standard for authorization in which users can delegate to an application, access to their resources without the need to share their credential with the application. Popular social providers such as Facebook implement authentication workflows based upon the OAuth protocol. In this article, we are focusing more on how the OAuth standard can be utilized for self-registration bootstrap scenarios rather than social authentication. However, social authentication using OAuth follows the pattern shown in Figure 1.

Bootstrapping registration with social

Apart from authenticating using BYO-ID, another benefit BYO-ID can offer is a mechanism to fast-track the on-boarding process to enterprise websites for customers without having to manually work through a web form to enroll.

With BYO-ID, enterprise website customers may choose to establish their new enterprise website account by bootstrapping identity information with their existing social network account. The self-registration process is fast-tracked by allowing the social site information to pre-fill field attributes needed for registration.

There are various open standards that offer the mechanism to achieve BYO-ID bootstrapping for enterprise website self-registration. The choice of which open standard to exploit is dependent on the enterprise and the social network vendor you wish to support. In this article, we'll explore in detail the self-registration pattern using the OAuth open standard.

Figure 2 presents an example of a self-registration workflow with a popular OAuth online identity provider, Facebook, using IBM Security products.

Figure 2. Security Access Manager Self-registration using Facebook OAuth provider
ISAM Self-registration using Facebook OAuth provider
ISAM Self-registration using Facebook OAuth provider

Figure 2 illustrates the self-registration process for a user, Eric John Smith, who initiates a request to register on an enterprise website using his Facebook account. There are a number of key IBM Security Systems components to become familiarized with for this OAuth-based BYO-ID self-registration implementation:

  • Tivoli Federated Identity Manager USC: Product-based framework allowing enterprises to exercise USC workflows for customer account access and provisioning management process.
  • Security Access Manager Web Gateway Appliance: Tivoli Federated Identity Manager integrates with the Security Access Manager Web Gateway Appliance (WebSEAL) component to provide authentication and authorization for business-to-consumer transactions.
  • Social Login App: This is an OAuth client servlet application that is responsible for interacting with OAuth providers such as Facebook. It can be recognized as the integration point between Facebook and enterprise websites to provide appropriate redirects to let the customer authenticate. It is the application that possesses the OAuth token that can be used to make authorized RESTful APIs to retrieve identity information from Facebook.
  • Landing servlet: A servlet responsible for redirecting the customer to the appropriate location for the USC workflows. It is also used for pre-filling available user identity information extracted from their online identity account into the registration form.
  • Facebook OAuth Provider: The Facebook OAuth Provider that is responsible for giving the Social Login App scoped access to the set of protected customer identity attributes that will be used for self-registration. An access token is granted to the Social Login App after the customer has successfully logged in.

The BYO-ID self-registration process begins when a customer logs into the enterprise website with a social network credential (representative icon in this example is Facebook, Figure 3):

Figure 3. Eric signs in with Facebook
Eric signs in with Facebook
Eric signs in with Facebook

The initiated request to sign in with Facebook is forwarded to the Social Login App. The Social Login App responds by redirecting the customer's browser to Facebook for authorization. The customer, Eric, is presented with a Facebook login form where he enter his username and password credentials.

Steps 4 and 5 set up the OAuth token that lets the Social Login App access user information from Facebook. In this example, the Social Login App uses the Facebook Graph API to retrieve the user data information from Eric's Facebook account.

Other OAuth providers (such as Twitter and LinkedIn) have their own REST APIs that support this implementation pattern as well.

The code snippet in Listing 1 shows how the Social Login App initiates the authorization workflow and does token exchange using OAuth with Facebook.

Listing 1. How the Social Login App initiates the authorization workflow and does token exchange using OAuth with Facebook
protected void doGet(HttpServletRequest request, HttpServletResponse response) 
                throws ServletException, IOException {

  String appid = "xxxxxxxx"; //Set with obtained Facebook App ID when registering application
   String appsecret = "xxxxxxxxxx";  //Set with obtained App secret when registering application
  String redirectURL = "https://your-enterprise-application/jct/unprotected/fblogin";
  String email = null;
    String code = request.getParameter("code");

  if (code == null) {               
               // initiate authorization flow
String authorizeURLStr = ""
                    + appid + "&redirect_uri=" + redirectURL + "&scope=email";
         } else {
               // we have an authorization code - first swap it for an access token
String accessTokenURLStr =
             + appid
     + "&redirect_uri="
      + redirectURL
                                          + "&client_secret=" + appsecret + "&code=" + code
               AccessTokenRetriever atr = new AccessTokenRetriever(accessTokenURLStr);
               String accessToken = atr.getAccessToken();

After the token exchange is complete, using the Facebook Graph API, the Social Login App uses the exchanged access token to obtain profile information from Eric's account. The code snippet in Listing 2 presents an example on how to achieve this.

Listing 2. Using the exchanged access token to obtain profile information from the account
//construct the URL for where to retrieve the user information from
	String resourceURLStr = ""accessToken;

try {
		 * Facebook will return a JSON string like:
		 * {"id":"1234567890","name":"Eric Smith","first_name":"John",
		 * "last_name":"Smith","link":"http:\/\/\/Eric.smith",
		 * "gender":"male","email":"","timezone":10,
		 * "locale":"en_US","verified":true,
		 * "updated_time":"2013-06-25T22:50:14+0000"}
		_jObject = new JSONObject(this.getResult(resourceURLStr));

     //Using the JSON object, one can retrieve user information such as 
     //firstname, lastname and email address
} catch (JSONException e) {
		throw new ServletException(e);

A technical example on how to create a Facebook OAuth client application and using Facebook for authentication in an Security Access Manager environment can be found in Related topics.

After a returned response populated with user attributes is received, a check is made to the internal user registry to determine whether this user is registered. Because a registered account for Eric is not found, the next phase is to set up Eric in such a state that will have him ready for registration.

Using Security Access Manager and Tivoli Federated Identity Manager, a way to preserve a pre-registration state for Eric is to employ a special intermediate user session within the Web Gateway Appliance. In this example, the intermediate Security Access Manager account is known as SocialUser. SocialUser is an account that has no password, but Web Gateway Appliance sessions are created with this account name during registration events only. These sessions are filled with attributes that represent Eric and his social attributes, such that a registration process can be completed efficiently. It's important to note that SocialUser sessions do not have any permission to access the website content. Step 6 of Figure 2 shows SocialUser employed as Eric's temporary pre-registration state.

Figure 4 shows the SocialUser credentials as logged in within Web Gateway Appliance.

Figure 4. Using SocialUser as a customer's pre-registration state
Using SocialUser as a customer's pre-registration state
Using SocialUser as a customer's pre-registration state

A key aspect to note in the Security Access Manager credential presented is the set of extended attributes defined as part of the SocialUser credential. All the attributes beginning with social_jk_ are set with a value provided from Eric's Facebook profile user information. This credential is created by the Social Login App leveraging the Security Access Manager's External Authentication Interface (EAI) capability, by setting both the username as SocialUser and the attributes to those mentioned previously.

The request is then forwarded to a Landing servlet. A set of user attributes from the credential (for example, social_jk_firstname=Eric, social_jk_surname=Smith) are sent through to this landing servlet as Security Access Manager tag values. The Landing servlet simply takes these headers and presents a USC registration form that is pre-populated with these attributes. Figure 5 presents an example of the tag value attributes being sent to the Landing servlet.

Figure 5. Pre-filled self-registration form using special Security Access Manager attributes
Pre-filled self-registration form using special Security Access Manager attributes
Pre-filled self-registration form using special Security Access Manager attributes

Figure 6 shows the resulting self-registration form pre-filled with fields from Eric's Facebook account. Note that the POST target of this page is the pre-configured Tivoli Federated Identity Manager USC end point for the create account operation. Hence, from this step onward, core product capabilities assume control.

Figure 6. resulting self-registration form pre-filled with fields from Eric's Facebook account
resulting self-registration form pre-filled with fields from Eric's                 Facebook account
resulting self-registration form pre-filled with fields from Eric's Facebook account

The enrollment form has been pre-populated with attributes that are available, but not necessarily all of them. This example indicates that Eric's first and last name and email address were retrieved from his Facebook profile account. More attributes may be obtained, though this is dependent on whether the information is available from the RESTful service endpoints and how much data the user agreed to share. The user may still be required to edit the populated fields, to update other required fields in the registration form such as secret questions, address, and so on.

Notice on the web form presented in Figure 6 that there are input fields for a new password and confirm password. This password field is enforcing customers to register their enterprise account so this alternate authentication mechanism could be used on the enterprise website. This is normally required to complete an enterprise registration, and in this example, where the registration form is being submitted to Tivoli Federated Identity Manager, this is mandatory.

After the required fields are provided, the user may then proceed to submit the enrollment form (Step 9, Figure 2). Tivoli Federated Identity Manager receives the submitted enrollment request. As a final step, it will send an email to the user with an account verification URL. After Eric opens this URL in a browser, this completes the verification process.

Upon completion of this BYO-ID self-registration, Eric has a registered account for the enterprise website. Having now registered an account, Eric may authenticate into the enterprise website with his username as the email address. Because Eric has registered using the enterprise site BYO-ID User Self Care Registration with Tivoli Federated Identity Manager, Eric will have two mechanisms to authenticate:

  • One is with his Facebook Social account
  • One is with his enterprise username and password

Given Tivoli Federated Identity Manager USC collected the user's email address and mobile phone numbers, the enterprise may also choose to extend their supported authentication schemes by leveraging Tivoli Federated Identity Manager OTP for higher-risk transactions (for example, password changes or high-value transactions).

Figure 7 now illustrates the high-level authentication workflow using Eric's Facebook account.

Figure 7. Authenticating using Facebook OAuth provider after self registration
Authenticating using Facebook OAuth provider after self registration
Authenticating using Facebook OAuth provider after self registration

Similar to the workflow shown in Figure 2, Eric initiates the authentication request using the enterprise website's authentication form. The Social Login App responds by redirecting the user to the appropriate online identity provider—in this case, Facebook. A returned response from Facebook is received from the Social Login App with an authorization code (Step 4, Figure 7), which leads to further access token exchange so that the Social Login App can access the user's profile information (Step 5).

With the user profile information retrieved from Facebook, a registry check is performed to determine that Eric does have a registered account. The Social Login service creates the Security Access Manager user session for Eric (because it's configured as an external authentication interface). In addition, Eric's authentication mechanism reflects that of a social login. Figure 8 shows an example of Eric's Security Access Manager authenticated session credential using a social login.

Figure 8. Security Access Manager authenticated session using social login
Security Access Manager authenticated session using social login
Security Access Manager authenticated session using social login

Alternatively, Eric may choose to authenticate using his enterprise username and password credentials specified at registration time. This authentication is processed using standard IBM Security Access Manager Web Gateway Appliance capabilities. Figure 9 shows Eric's Security Access Manager authenticated session credential using his enterprise username and password credentials.

Figure 9. Security Access Manager authenticated session using enterprise login
Security Access Manager authenticated session using enterprise login
Security Access Manager authenticated session using enterprise login

Notice in Figure 9 that Eric's authentication level is higher than when he was employing his social login. In this example, the enterprise account is considered to be a higher trusted authentication mechanism than the social login.

The example above shows that Tivoli Federated Identity Manager USC can be used to complete a registration process for Enterprise scenarios. It takes advantage of social site integration by simplifying the registration process, while allowing registration of data that lets other authentication mechanisms be configured.

Risk in using BYO-ID

Adopting BYO-ID is convenient and flexible for users. However, it does come with certain risks. Using BYO-ID relies on the online provider to be highly available for authenticate delegation to grant access to the enterprise. Should the identity provider, for some reason, become unavailable this will lead to a single-point of failure.

Another major issue occurs should the online identity become compromised. The user may need to undergo certain measures to recover and reestablish their identity on enterprise websites where they have used BYO-ID. The potential time, cost, and effort to rectify the situation and rebuild a new identity can be high for both users and the enterprise.

In conclusion

Regardless of the risks, BYO-ID is a growing consumer demand. Customers have become accustomed to the concept of using social credentials to register and authenticate to online services. The questions for enterprises now is one of security (how much access should be granted to these users) and policy implementation (which authentication and registration implementation suits the requirements, levels of access, and the users).

IBM Security Systems products provide a framework for applying standard deployment patterns across complex and evolving access management patterns. In this article, you have seen that BYO-ID use case aspects range from consideration of user registration processes and authentication considerations, as well as an ever-evolving set of open standards. In this article, we've provided a set of integration patterns that leverage the IBM Security Systems products to successfully implement a set of the customer requirements. It is a challenge for any access management product to handle such a large array of open standards, and to evolve and adapt as these standards mature, and IBM Security Access Manager has been successful in fulfilling this need.

Downloadable resources

Related topics

ArticleTitle=Enable bring-your-own-identity authentication