731-235-3686

Unfortunately “Proof of Concept” (POC), “Prototype”, and “Pilot” are used interchangeably, though I think they mean different things and serve very different functions.

Successful projects should implement all of these consciously/deliberately. There should be a process around how we apply them, how we collect results from them and how we apply the results in the decisions we make.

prototype-vs-poc-vs-pilot

Proof of Concept (PoC)

A Proof of Concept (POC) is a small exercise to test a discrete design idea or assumption.

For example, If we have two systems which need to communicate with each other through a developer might develop a simple “Hello World” type application to test if this communication works.  The focus is not performance, scalability or fault tolerance.

in PoC just test the viability of an idea!

Prototype

A Prototype is a more fleshed out system that tries to simulate the full system.  Prototypes are used to test the viability or usefulness of a system or subsystem. The idea is to provide an experience to the end user to be able to visualize the experience of using the complete system

Depending on what you are testing, you will have prototypes with different level of capabilities.

Key point about building prototypes is that if you have spent time and money building it then you got to use it.  Take it to customers, take their feedback, incorporate it!

Pilot

Pilot, is often a full production system with a goal to see how the product will be used by users and to refine the product before a broad market push. Pilot should be all about Metrics Metris Metrics!!!

Before starting a pilot, you should know why you are doing it, what do you want to measure, how will you measure it, how will you collect the data.  A good product manager should have a plan to incorporate enhancement ideas based on the data coming back from the pilot.

POCs, Prototypes, and Pilots are all important part of implementing a good product. With the right process and clear goals a good product manager should incorporate POCs, Prototypes, and Pilots in their product roadmaps.

Patent Granted – A Method and System for Click-Thru Capacity in Electronic Media

Better Late Than Never!!!

img_3742
Patent Target: Content Systems and products (Data transparency and auditability for content – from raw data collection to customer desktop delivery)

Executive Summary: Data (numbers) customers often see on our products have gone through significant amount of calculations. Complex calculation using data taken from different documents are required to come up with the correct results. Using this patent customer can click on a number on our product and see the formula with actual values used – if the number used in the formula was also derived through a calculation they customer can that formula as well (recursively), until customer gets to the raw data. (The raw data could be a set of numbers from multiple 1,000+ page documents like annual report, research report, court filing etc.)

Technology Implementation Summary: Standardized a way for content systems to represent complex proprietary formulas by extending MathML and integrating it in the content and product delivery systems.

patent

9542792568

Google Machine Intelligence research organization’s Google Brain Team just open sourced TensorFlow. TensureFlow is a machine learning library used across Google to apply deep learning to different areas.  Its very good at perceptual and language understanding tasks – designed to facilitate research in machine learning, and to make it quick and easy to transition from research prototype to production system.

TensorFlow was originally developed by researchers and engineers at Google but the entire library was open sourced yesterday.  Not only was the code released under Apache 2.0 open source license, Google moved internal development efforts over to use a public repository so that day-to-day changes made by the team at Google are available to public – this is HUGE!

This open source release already supports machines (desktop/servers) and mobile devices, and is already used in Google products.  Standardizing on a library and common tool set will help accelerate development in this field.  My prediction is that in 3 years, we along with our customers and competitors will be using this in some form or the other.

But don’t ask me if I can build a robot butler by just importing this library – that will take a little longer.

Radical and Incremental Innovation

Yes, Old topics die hard! I was re-reading about some old articles about types of innovations, and measuring effectiveness of different project investments and thought of posting this to wider community to get some help & feedback.

Radical / Disruptive Innovation Incremental / Sustaining Innovation
Provides entirely new set of usage features and experience, and/or provides significantly better performance and/or significantly reduces cost Relates to enhancements or small improvements in the existing products or services
Example:  Zipcar car sharing service Example:  Avis car rental preferred members can skip lines and go straight to a car
Radical change can significantly change the basis of competition in the favor of the innovator Incremental innovation can be small cost cutting or adding content or feature improvements in existing products or services

04-radical-and-incremental-innovation

The diagram shows the cycle of the Radical and Incremental Innovations.

Incremental innovation is most common form of innovation in most companies, the reason it’s so popular is because it has reduced risk and faster time to market in comparison to radical innovation. I think, once a company has an established product it usually has built up considerable amounts of human capital and competencies so it continues to devote time to making it better or reducing costs. Which in turn opens doors for new competitors/innovators.

  • How do you protect your firm/product from new competition?
  • As we are doing 2016/17 planning what split are you seeing in investments in the two innovation types?
  • Do you have process to track and measure ROI from Radical and Incremental innovation investments?

Lastly if you don’t mind can you share an example of a radical innovation in your group/company.

Identity Federation Design Patterns: 6 – Integration with a Central IAM

Like previous post, let’s assume that a Product 1 user is given access to Product 2 (product or services) and we want to provide this customer with an integrated product experience. In this design pattern we enable this single sign-on experience by leveraging a central IAM system in between the two systems

The high level data flow will be similar to the flow shown below:

03-fedwithiam_new

IAM Data Flow: Data from order processing systems  continues to interact directly with each application’s Identity Provider . The data is synchronized from each Identity Provider into the IAM solution – where the user’s central profile is maintained. In addition to user-based information, the central IAM solution maintains a mapping of accounts in between the application-specific Identity Providers and flags indicating inter-application data sharing.

  1. Product 1 users that have been permitted access to Product 2 data will see a link for Product 2 once they authenticate into Product 1. (When the user clicks on the Product 2 link, they would like to have access to their Product 2 screens/data).
  2. The Product 1 application connects to IAM to retrieve the user id (or token) that grants the Product 1 application access to their Product 2 account.
  3. IAM returns the requested user id (or token).
  4. Product 1 calls (passes control) to Product 2 with necessary assertion/token requesting user access to Product 2 services.
  5. The Product 2 application verifies the assertion/token with the IAM solution.
  6. The IAM solution verifies the security of the request and returns the information to Product 2.
  7. Product 2 provides access to the services that the customer is entitled to.

Using the data flow mentioned above (or a variant) the Product 1 user can be granted access to Product 2 services. Once this flow is implemented the user who logs in to Product 1 will be provided access.

  1. The user’s identity will remain different between Product 2 and Product 1 until such time as those applications begin using the central Identity Provider included in the IAM solution
    • A common interface can be implemented to allow users to maintain their profile data from a central location.
    • Bi-directional synchronization of data can be implemented until such time as these applications decide to migrate.
  2. Implementing SSO across multiple products requires integration to the central IAM solution – not each individual application
    • Minimizes the complexity and reuses existing interactions
  3. Users will experience single sign on across web-based or fat clients

————–

This is a broad topic, so I have split this content in different blogs to help focus discussion on sub topics in different blogs.

Also if you liked this blog then you might also like my previous blog “302-444-3897“

Identity Federation Design Patterns: 5 – Integration without IAM

Let us assume that a Product 1 user is given access to Product 2 (product or services) and we want to provide this customer an integrated product experience. There are multiple design patterns which can enable this single sign-on experience. These can range from placing a layer (IAM or other service) between the two systems to enable this federation or we can try to directly connect the applications.

If we provide a user access to Product 1 content from within the Product 2 application by directly connecting Product 2 and Product 1, the high level data flow will be similar to the diagram shown below:

03-fedwoiam_new

Current Data flow: Data from order processing systems is loaded directly into each application’s Identity Provider. Product 2 and Product 1 then interact with their corresponding Identity Provider for authentication and authorization purposes.

  1. Prerequisite: Current and new customer data will be sent from Product 1 order processing system to product 2 identity provider so that product 2 identity provider can keep a mapping of product 2 user identity  to product 1 user identity; product 2 identity provider or Product 1 DB must also be modified to keep track of which users have access to Product 2 services.
  2. Product 1 users that have been permitted access to Product 2 data will see a Product 1 link for Product 2 once they authenticate into Product 1. (When the user clicks on the Product 2 link, they would like to have access to their Product 2 screens/data.)
  3. The Product 1 application connects to its internal identity system database to retrieve the user id (or token) for their Product 2 account.
  4. Product 1 identity system (or its internal database) returns the requested user id (or token)
  5. Product 1 calls (passes control) to Product 2 with necessary assertion/token requesting user access to Product 2 services.
  6. The Product 2 application calls product 2 identity system to verify received assertion/token.
  7. Product 2 identity system verifies the security of the request, maps the provided Product 2 user identity ID to the internal Product 2 user identity, and grants access and returns to Product 2 the product 2 user ID.
  8. Product 2 provides access to the services that the customer is entitled to.

Using the data flow mentioned above (or a variant) the Product 1 user can be granted access to Product 2 services. Once this flow is implemented the user who logs in to Product 1 will be provided access but:

  1. The user’s identity will be different between Product 2 and Product 1 (i.e. different user id/password on both systems).
    • If the user changes their password on Product 2, the change won’t reflect in their Product 1 credentials.
    • Different profiles in different products may cause an “awkward” user experience. (In one product a user may be referred to as “William” but in the other they may go by “Bill”.)
  2. If the user first logs in to Product 2, they will not experience single sign on when attempting to connect to Product 1.
    • For this access a reverse flow will also need to be implemented
  3. Any two applications between which we want to enable a SSO experience will need to implement the above flow two times
    • Need for SSO customer experience between 5 systems will require 20 flows shown above (multiplicative growth in complexity), making it error prone and very hard to manage

————–

This is a broad topic, so I have split this content in different blogs to help focus discussion on sub topics in different blogs.

Also if you liked this blog then you might also like my previous blog “Benefits of Identity and Access Management as­ Corporate Service“

Identity Federation Design Patterns: 4 – “OAuth” – Open Authorization

The OAuth protocol version 2.0 (“OAuth2”) was mainly created to remove the need for users to share their passwords with third-party applications. OAuth2 is mainly used for delegating access to some external entity. You are basically allowing someone to “act” on behalf of you. Its most common industry application is to grant access APIs that can do something on your behalf.

Let us assume you have a Twitter and Facebook account and every time you post on Twitter, you want that post to be sent to your Facebook page. OAuth2 allows Twitter the ability to post on your Facebook page without you providing your Facebook user name and password to Twitter. OAuth2 does not end with authentication but provides an access token to gain access to additional resources provided by the same third-party service. However, since OAuth2 does not support discovery, it requires pre-selecting and hard-coding the providers you decide to use.

OAuth2 process consists of three steps:

  1. Generation of the Authorization Grant
  2. Obtaining of the Access Token (based on the Authorization Grant)
  3. Using the Access Token to make requests

OAuth2 Terminology:

  • Resources
  • Resource Owner
  • Resource Server
  • Client
  • Authorization Server
    • Authorization Grants
    • Access Token
    • Scope
    • Refresh Token

The OAuth2 standard defines multiple “flows” for the Client to obtain an Access Token from an Authorization Server.

Authorization Code Flow:

  1. The Client requests an Authorization Grant from the Resource Owner.
  2. The Resource Owner is redirected to the Authorization Server. The Scope of the request is included in the redirection.
  3. The Authorization Server authenticates the Resource Owner.
  4. The Authorization Server asks the Resource Owner if they want to grant access based on the Scope of the request.
  5. The Resource Owner approves the request.
  6. The Resource Owner is redirected back to the Client along with an Authorization Code.
  7. The Client presents the Authorization Code to the Authorization Server.
  8. The Authorization Server validates the Authorization Code and issues an Access Token (and optional Refresh Token).
  9. The Authorization Server gives the Access Token to the Client.

03-oauth_new

Implicit Grant Flow:

Similar to the Authorization Code Flow, except the Authorization Server does not issue an Authorization Code to the Resource Owner. Instead, the Authorization Server issues an Access Token (and optionally a Refresh Token) directly to the Resource Owner. The Resource Owner presents this to the Client directly.

Resource Owner Password Credentials Flow:

The Resource Owner presents the Client with its credentials (username/password) on the Authorization Server. The Client presents the Authorization Server with the Resource Owner’s credentials which are then exchanged for an Access Token/Refresh Token.

Client Credentials Flow:

In this case, the Client and the Resource Server are often the same server. The Client is acting on its own behalf or is requesting access to protected resources base on an authorization previously arrange with the Authorization Server.

Extension Mechanism: SAML2 Token Insertion

The Client presents a SAML2 token to the Authorization Server in exchange for an OAuth2 token.

Additional information on OAuth2: /tools.ietf.org/html/rfc6749 Internet Engineering Task Force (IETF)

Key advantages of OAuth are:

Controlled sharing of resources – OAuth is an authorization protocol that allows Resource Owners to specify the Scope of the access (which Resources are accessed by the Client and for how long).

Flexible (“just in time”) access granting – Unlike SAML, which requires an existing relationship between the Identity Provider and Service Provider, OAuth does not require pre-arranged negotiation between the Client, Resource Server, or Authorization Server. Resource Owners can grant or revoke access to one or more Resources any time they like.

Lightweight implementation – While SAML is based on XML (which can be very heavy), OAuth is based on REST and JSON and as such is very lightweight. This makes it ideal for mobile applications.

Areas that OAuth does not address are:

Authentication – OAuth DOES NOT implement authentication; it is strictly an authorization protocol and while some implementations have chosen to use OAuth for authentication, this is not entirely secure. OAuth requires the addition of OpenID Connect to combine authentication and authorization in the same negotiation.

Note: SAML and OAUTH are not mutually exclusive. While there may be similarities between the two, each protocol addresses very different use cases within corporate federation architecture. It most cases both are implemented in the central IAM solution in addition to other functionality not directly available in these protocols (though, OAuth should be the preferred method in most cases)

————–

This is a broad topic, so I have split this content in different blogs to help focus discussion on sub topics in different blogs.

Also if you liked this blog then you might also like my previous blog “979-400-4882“

Identity Federation Design Patterns: 3 – SAML

SAML is an OASIS standard used to exchange authentication and authorization data between two parties. SAML uses an XML format to share information about who a user is and what they are allowed to do. Authorization data is included in a set of attributes provided in a SAML “assertion” (along with other identifying information); the assertion is generated by a trusted entity called the Identity Provider. An application that receives the assertion can then grant or deny access to resources based on the assertion attributes.

SAML 2.0 Terminology

  • Entity
  • Identity Provider
  • Service Provider
  • Assertion
  • Circle of Trust
  • Metadata

SAML based Single Sign-On (SSO) works with systems hosted internally or externally and allows you to using the existing authentication system with your application. Authorization is still maintained within your remote application, so you can determine which users should have what level of access.

Overview of SAML Steps

  1. The user makes a request to a Service Provider for a specific resource. This request may happen in a variety of ways or reasons. For example, the user may be following a bookmark or clicking on a link from an email.
  2. The Service Provider detects that the user needs to authenticate and redirects them to the SAML Identity Provider. Along with a SAML Request, an HTTP parameter called RelayState is passed to the Identity Provider. This parameter captures the location of the resource the user originally requested.
  3. The user accesses their IDP and authenticates. This authentication is performed by the IDP giving the customer complete control over the authentication process. A variety of popular techniques may be used to authenticate; this includes basic authentication using an LDAP directory server, a web access management system, Integrated Windows Authentication, or a 2-factor system such as SecurID.
  4. Once authenticated, the IDP generates an assertion about the user indicating that they have successfully authenticated. The assertion is sent to the Service Provider. This response is relayed through the user’s browser, and includes the RelayState originally sent by the Service Provider. The echoing of RelayState is critical to the success of the protocol, as this is what allows the user to be returned to the originally requested resource.
  5. The Service Provider processes the SAML assertion and logs the user in. The digital signature included in the SAML assertion allows verification that the message is from the Identity Provider, at which point the user is authenticated. They are granted a session and redirected to their original request

03-saml_new
Identity Provider performs user authentication and the underlying product after calling the Identity Provider performs the authorization. A goal of the central IAM system is to be similar to Identity Provider and authenticate customers globally (while the products manage authorizations locally). Some customers could act as the Identity Provider in this relationship and in fact, some Businesses already support this growing requirement. The central IAM system should also allow customers to act as Identity Providers, but rather than associating the user’s identity with a Business-specific account, their identity would be tied back to a centrally managed user identity that will be consistent across all Businesses.

Key advantages of SAML are:

Platform neutrality – SAML abstracts the security framework away from platform architectures and particular vendor implementations. Making security more independent of application logic is an important tenet of Service-Oriented Architecture.

Loose coupling of directories – SAML does not require user information to be maintained and synchronized between directories. (Although there are benefits associated with the creation of a common identity that cannot be experienced with loosely coupled identities.)

Improved online experience for end users – SAML enables single sign-on by allowing users to authenticate at an Identity Provider and then access Service Providers without additional authentication. In addition, identity federation (linking of multiple identities) through SAML allows for a better-customized user experience at each service while promoting privacy.

Reduced administrative costs for Service Providers – Using SAML to “reuse” a single act of authentication (such as logging in with a username and password) multiple times across multiple services can reduce the cost of maintaining account information. This burden is transferred to the Identity Provider. (This will reduce the complexity of our infrastructure and operating costs associated with managing and maintaining dozens of identity systems).

Risk transference – SAML can act to push responsibility for proper management of identities to the Identity Provider, which is more often compatible with its business model than that of a Service Provider.

Areas that SAML does not address are:

SAML does not require identities maintained by different Identity Providers be federated – only that the Service Providers trust the assertion created by the Identity Provider. Companies are often unable to obtain a corporate-wide view of a user’s activity across businesses, is unable to enforce corporate-wide security measures (such as authentication methods or security policies), and does nothing to move us towards a consolidated user directory for collaboration.

SAML DOES NOT help us move to a common interface for allowing customers to maintain their profile data. Customers may have multiple profiles both across products as well as within the products themselves (i.e. they may have multiple profiles in the same product created due to different relationships). Customers that end up having multiple profiles must maintain them separately – often across multiple product account management interfaces. Identities in the central IAM data store will consist of information that has been replicated from Business-specific Identity Providers; this will create a central identity about what we currently know about a customer and provide customers with a central interface they can use to update certain data.

While SAML allows multiple Identity Providers to coexist in the same environment, SAML DOES NOTHING to eliminate the multiple sets of credentials that a customer must maintain – oftentimes across multiple products. As products migrate, the IAM system will become the central Identify Provider for products. Customer will authenticate against the central IAM system using one set of credentials, the central IDP will then generate a product-specific assertion consisting of the data needed for the product to determine access, and the product will evaluate the customer data and grant or deny access accordingly.

SAML is not a complete solution. SAML DOES NOT, for instance work with non-Web based applications (Desktop applications).

Additional information on SAML: /wiki.oasis-open.org/security/FrontPage

————–

This is a broad topic, so I have split this content in different blogs to help focus discussion on sub topics in different blogs.

Also if you liked this blog then you might also like my previous blog “516-354-3969“

(317) 202-5528

Across the industry, many companies are implementing new, hosted Identity and Access Management Service (“IAM”) that will be used by all the products to authenticate customers accessing our services.

The Identity service will provide a central user profile that can be shared across products. Customers will manage their profile from a central location; thus ensuring the accuracy and timeliness of their data across all products. The central identity will have the effect of increasing customer satisfaction (a benefit to the customer), but use of this central identity will give organization better abilities to track customers throughout their product lines over a period of time; which will provide better insight into how our products are used (a benefit to the company).

The Authentication service provides a single login that can be used by products across the company (in a fashion similar to Google, Amazon, Facebook, Apple, Microsoft and other technology companies). This will allow our customers to log in once across all products, rather than into each product separately. As corporate security policies change, modifications are made centrally at the Authentication service rather than individually in various products across businesses. As a result, security polices can be made (and enforced) consistently across the organization.

The Identity and the Authentication services should include graphical, web-based interfaces that allow clients and administrators to interact directly with these services. Additionally, Identity and Authentication services should be exposed via web services and implemented using architectural styles such as representational state transfer (“REST”). This will allow products to easily interact with the central IAM solution programmatically.

Companies often have dozens of different systems that contain customer identity data and these systems are used by hundreds of products. Having multiple identity systems not only limits the ability to leverage assets easily across the organization but it also provides sub­optimal customer experience and prevents us from tracking customers across products.

By consolidating on a central IAM service, it will improve the ability to integrate existing products within the organization, provide better user management for our largest customers, increase our ability to scale and support identity and access management services, and bring us closer to our customers so that we can better market and sell to them.

SAML & OAuth are often mentioned as methods of connecting various products using different identity systems. In this document we will briefly discuss what SAML & OAuth are, and how they can help in the identity landscape of an organization. We will also look at design patterns with and without a central IAM and perform an objective analysis of pros and cons of various methods of identity federation.

Before we start talking about the key protocols used for identity, it is important to understand that these are broad standards and there are many ways that you can implement them. Next couple blogs will review commonly used implementations and those that have direct applicability in most systems.

————–

This is a broad topic, so I have split this content in different blogs to help focus discussion on sub topics in different blogs.

Also if you liked this blog then you might also like my previous blog “Benefits of Identity and Access Management as­ Corporate Service“

Identity Federation Design Patterns: 1 – Executive Summary

Companies have dozens of different systems that contain customer identity data and these systems are used by more than hundreds of
products. Having multiple identity systems not only limits the ability to leverage assets easily across the organization but it also provides sub­optimal customer experience and prevents us from tracking customers across products.

Consolidating the different identity systems will take multiple years, during which there often is a need to provide value added services
to customers by leveraging system across business boundaries and by reusing existing product widgets. These value added services will require identity federation, so that products can understand various IDs users have across different products.

SAML & OAuth are terms (protocols) often mentioned as methods of connecting various products using different identity systems. There are many challenges associated with implementing SAML and OAuth in most current product environments. To overcome these challenges we will have to make significant changes to our current systems and in many cases implement complex new data flows. Even a handful of such implementations will result in a significantly more complex system, which can be error prone and very difficult to maintain.

By leveraging a central IAM solution as a middle layer for federation, the complexity around user ID mapping across different systems and
user life cycle management (user provisioning/de­provisioning) is isolated away from products to the central layer. User mapping performed once
in the central IAM solution can be leveraged by all business units for federation. Moreover standard design patterns & APIs offered by the
central IAM will significantly simplify the management of systems, and provide enhanced security across Thomson Reuters. Finally, theunified identity provided by an IAM solution facilitates methods for monitoring a user’s activity as they interact with Thomson Reuters’ products.
This information can then be used to better understand our customer’s habits and offer additional services.

Identity alone cannot solve our content sharing problems, final solution will require coordination with backend entitlement systems too but
centralized identity mapping makes federation easier. This blog is first part of a 7 blog series of my brain dump around federation with a goal of
driving conversation about identity with my friends and colleagues across business units.

————–

This is a broad topic, so I have split this content in different blogs to help focus discussion on sub topics in different blogs.

Also if you liked this blog then you might also like my previous blog “Benefits of Identity and Access Management as­ Corporate Service“