Tuesday, December 26, 2017

Lambda Architecture for Big Data

An increasing number of systems are being built to handle the Volume, Velocity and Variety of Big Data, and hopefully help gain new insights and make better business decisions. Here, we will look at ways to deal with Big Data’s Volume and Velocity simultaneously, within a single architecture solution.

Volume + Velocity

Apache Hadoop provides both reliable storage (HDFS) and a processing system (MapReduce) for large data sets across clusters of computers. MapReduce is a batch query processor that is targeted at long-running background processes. Hadoop can handle Volume. But to handle Velocity, we need real-time processing tools that can compensate for the high-latency of batch systems, and serve the most recent data continuously, as new data arrives and older data is progressively integrated into the batch framework.
Therefore we need both batch and real-time to run in parallel, and add a real-time computational system (e.g. Apache Storm) to our batch framework. This architectural combination of batch and real-time computation is referred to as a Lambda Architecture (λ).

Generic Lambda

λ has three layers:
  1. The Batch Layer  manages the master data and precomputes the batch views
  2. The Speed Layer  serves recent data only and increments the real-time views
  3. The Serving Layer is responsible for indexing and exposing the views so that they can be queried.
The three layers are outlined in the below diagram along with a sample choice of technology stacks:
lambda1
Incoming data is dispatched to both Batch and Speed layers for processing. At the other end, queries are answered by merging both batch and real-time views. Note that real-time views are transient by nature and their data is discarded (making room for newer data) once propagated through the Batch and Serving layers. Most of the complexity is pushed onto the much smaller Speed layer where the results are only temporary, a process known as “complexity isolation“. We are indeed isolating the complexity of concurrent data updates in a layer that is regularly purged and kept small in size.
λ is technology agnostic. The data pipeline is broken down into layers with clear demarcation of responsibilities, and at each layer, we can choose from a number of technologies. The Speed layer for instance could use either Apache Storm, or Apache Spark Streaming, or Spring “XD” ( eXtreme Data) etc.
How do we recover from mistakes in λ ? Basically, we recompute the views. If that takes too long, we just revert to the previous, non-corrupted versions of our data. We can do that because of data immutability in the master dataset: data is never updated, only appended to (time-based ordering). The system is therefore Human Fault-Tolerant:  if we write bad data, we can just remove that data altogether and recompute.

Unified Lambda

The downside of λ is its inherent complexity. Keeping  in sync two already complex distributed systems is quite an implementation and maintenance challenge. People have started to look for simpler alternatives that would bring just about the same benefits and handle the full problem set. There are basically three approaches:
  1. Adopt a pure streaming approach, and use a flexible framework such as Apache Samza to provide some type of batch processing. Although its distributed streaming layer is pluggable, Samza typically relies on Apache Kafka. Samza’s streams are replayable, ordered partitions. Samza can be configured for batching, i.e. consume several messages from the same stream partition in sequence.
  2. Take the opposite approach, and choose a flexible Batch framework that would also allow micro-batches, small enough to be close to real-time, with Apache Spark/Spark Streaming or Storm’s Trident. Spark streaming is essentially a sequence of small batch processes that can reach latency as low as one second.Trident is a high-level abstraction on top of Storm that can process streams as small batches as well as do batch aggregation.
  3. Use a technology stack already combining batch and real-time, such as Spring “XD”, Summingbird or Lambdoop. Summingbird (“Streaming MapReduce”) is a hybrid system where both batch/real-time workflows can be run at the same time and the results merged automatically.The Speed layer runs on Storm and the Batch layer on Hadoop, Lambdoop (Lambda-Hadoop, with HBase, Storm and Redis) also combines batch/real-time by offering a single API for both processing paradigms:
    lambdoop2
The integrated approach (unified λ) seeks to handle Big Data’s Volume and Velocity by featuring a hybrid computation model, where both batch and real-time data processing are combined transparently. And with a unified framework, there would be only one system to learn, and one system to maintain.

Wednesday, December 20, 2017

SSO login in Java

1.    Introduction
This document describes an approach to implement the Single Sing On to Product Suite.
2.    Intended Audiences
This document is indended for the developers, designers and architects who would like to understand the approach to implement the Single Sign On to a Kewill product using WSO2 Identity server and SAML 2.0 Protocol.
3.    Prerequisites
Jdk 1.5 or above
OpenSAML libraries
WSO2 Identity Server
Please note that the WSO2 IS version 5.0.0 and below does not support JAVA 8, download latest version 5.1.0 as of 13 June 2016, if you are working with JAVA 8.

4.    SSO Solutions
There are two different kind of single-sign-on solutions: delegated and federated.

4.1  Delegated Authentication

A delegated solution means that one site is simply outsourcing its authentication needs to another pre-selected site. If your site uses Facebook Connect, you are delegating your authentication facilities to Facebook. Visitors to your site cannot use any other accounts, only accounts from the vendors you have pre-selected.


4.2  Faderated Authentication
A federated solution means that visitors to your site can use any account they have, as long as it is compatible. It makes no difference to the site which account is being used, as long as it can interoperate. At its core, OpenID is a federated solution because its most important feature is the ability to use any OpenID account with any OpenID-enabled service
Delegated authentication has a few drawbacks with respect to federated authentication, Delegated authentication is inherently less secure than federated authentication.Delegated authentication requires more work for the company implementing it

5.    SSO Protocols
There are many protocols in the market to implement SSO like SAML, OpenId, Oauth, Higgins, Windows Cardspace, MicroId and Liberty Allowance.
There are three major protocols for federated identity: OpenID, SAML, and OAuth.

5.1  OpenID
OpenID is an open standard sponsored by Facebook, Microsoft, Google, PayPal, Ping Identity, Symantec, and Yahoo. OpenID allows user to be authenticated using a third-party services called identity providers. Users can choose to use their preferred OpenID providers to log in to websites that accept the OpenID authentication scheme
The OpenID specification defines three roles:
·         The end user or the entity that is looking to verify its identity
·         The relying party (RP), which is the entity looking to verify the identity of the end user
·         The OpenID provider (OP), which is the entity that registers the OpenID URL and can verify the end user’s identity
The following diagram explains a use case for an OpenID scenario:


Security Considerations
OpenID had a few interesting vulnerabilities in the past, for example:
1.    Phishing Attacks: Since the relying party controls the authentication process (if necessary) to the OpenID provider, it is possible for a rogue relying party to forward the user to a bogus OpenID provider and collects the user’s credentials for the legal OpenID provider.
2.    Authentication Flaws: In March 2012, three researchers presented a paper that highlighted two vulnerabilities in OpenID. Both vulnerabilities allow an attacker to impersonate any user to a website if the website doesn’t properly check whether the response from the OpenID provider contains a properly signed email address.


5.2  SAML
Security Assertion Markup Language (SAML) is a product of the OASIS Security Services Technical Committee. Dating from 2001, SAML is an XML-based open standard for exchanging authentication and authorization data between parties.

The SAML specification defines three roles:
·         The principal, which is typically the user looking to verify his or her identity
·         The identity provider (idP), which is the entity  that is capable of verifying the identity of the end user
·         The service provider (SP), which is the entity looking to use the identity provider to verify the identity of the end user

The following diagram explains a use case for a SAML scenario:


Security Considerations
1.    A group of researchers presented a paper in 2011 where they used an XML Signature Wrapping vulnerability to impersonate any user

5.3  Oauth2
OAuth is another open standard. Dating back to 2006, OAuth is different than OpenID and SAML in being exclusively for authorization purposes and not for authentication purposes.

The OAuth specifications define the following roles:
·         The end user or the entity that owns the resource in question
·         The resource server (OAuth Provider), which is the entity hosting the resource
·         The client (OAuth Consumer), which is the entity that is looking to consume the resource after getting authorization from the client

The following diagram explains a user case for an OAuth scenario


Security Considerations
1.    A session fixation vulnerability flaw was found in OAuth 1.0. An attacker can fix a token for the victim that gets authorized. The attacker then uses the fixated token.
2.    OAuth 2.0 was described as an inherently insecure protocol since it does not support signature, encryption, channel binding, or client verification. The protocol relies entirely on the underlying transport layer security (for example, SSL/TLS) to provide confidentiality and integrity.

5.4  Other Protocols
There is a growing number of other federated identity options. Here are a few examples. 
Higgins: Higgins is a new open source protocol that allows users to control which identity information is released to an enterprise.

Windows CardSpace: CardSpace is Microsoft new identity metasystem that provides interoperability between identity providers and relying parties with the user in control. This protocol is retired though and Microsoft is working on a replacement called U-Prove.

MicroID: MicroID is a new identity layer to the web and microformats that allow anyone to simply claim verifiable ownership over their own pages and content hosted anywhere.

Liberty Alliance: Liberty Alliance is a large commercially oriented protocol providing inter-enterprise identity trust. It is the largest existing identity trust protocol deployed around the world
5.5  Difference between OpenId, SAML and Oauth
The table below explains the major differences between the three protocols:


OpenID
OAuth
SAML
Dates from
2005
2006
2001
Current version
OpenID 2.0
OAuth 2.0
SAML 2.0
Main purpose
Single sign-on for consumers
API authorization between applications
Single sign-on for enterprise users
Protocols used
XRDS, HTTP
JSON, HTTP
SAM, XML, HTTP, SOAP
No. of related CVEs
24
3
17

6.    SSO Implementations
There are many SSO implementation frameworks available in the market like OpenAM, CAS, JOSSO, CloudSeal and WSO2 Identity Server. Based on the Kewill’s requirement analysis to implement SSO to Kewill Product Suite we have chose the WSO2 identity server, below are the features of it.
·         API for integrating identity management to any application
·         Multi-factor authentication
·         Single Sign-On (SSO) via OpenID, SAML2, and Kerberos KDC
·         SSO bridging between on-premise systems and cloud apps
·         Credential mapping across different protocols
·         Auditing via XDAS
·         Delegation via OAuth 1.0a, OAuth 2.0, and WS-Trust
·         Federation via OpenID, SAML2, and WS-Trust STS
·         Integration with Microsoft SharePoint with Passive STS support
·         Implement REST security with OAuth 2.0 and XACML
·         XKMS for key storage and distribution
·         Implement REST security with OpenID Connect
·         Trusted SAML2 Identity Providers per tenant
·         Out-of-the-box integration with Google Apps and Salesforce
·         Customizable login pages for OpenID, OAuth, OpenID Connect, SAML2, and Passive STS
More information can be found here http://wso2.com/products/identity-server/ .