Author Archives: manvirbasra

Amazon CloudWatch

AWS CloudWatch

  • Monitoring and management service which provides unified view of operational health

Why CloudWatch?

  • Gaining visibility across your distributed stack (servers, network, database etc.) at one place

What CloudWatch collects?

  • Collects monitoring and operational data in the form of
    • logs
      1. Vended logs – Natively published by AWS on behalf of customers e.g. AWS VPC Flow Logs and Amazon Route 53 logs
      2. Logs published by AWS services – include Amazon API Gateway, AWS Lambda, AWS CloudTrail, and many others
      3. Custom logs – Logs from application and on-prem resources.  Use AWS Systems Manager to install a CloudWatch Agent, or you can use the PutLogData API action to easily publish logs
    • metrics
      1. Built-in metrics – Default metrics are enabled by detailed. More more detailed, can be opt-in per resource
      2. custom metrics – application metrics etc. Use CloudWatch Agent or the PutMetricData API action to publish these metrics to CloudWatch
    • events
  • CloudWatch provides up to 1-second visibility of metrics and logs data, 15 months of data retention (metrics), and the ability to perform calculations on metrics

CloudWatch Integration

  • Integration with CloudWatch
    • natively integrated with AWS services
    • can use AWS Systems Manager to install a CloudWatch Agent
    • can use the CloudWatch API to easily collect, publish, and store this data in CloudWatch

Some CloudWatch use cases

Unified operational view with dashboards

  • dashboards enable you to create re-usable graphs and visualize your cloud resources and applications

Automated Actions – alarms – auto scaling

  • Amazon CloudWatch enables you to set high resolution alarms and take automated actions.
  • Example 1: This means freeing up important resources to focus on adding business value. For example, you can get alerted on Amazon EC2 instances and set up Auto Scaling to add or remove instances
  • Example 2: You can also execute automated responses to detect and shut down unused EC2 resources, reducing billing overages and improving resource optimization.

Resources

Amazon EKS

Amazon EKS

  • Managed Kubernetes Service
  • Elastic container service for Kubernetes makes it easy to deploy, manage and scale containerized applications using k8s on AWS
  • runs the Kubernetes management infrastructure for you across multiple AWS availability zones to eliminate a single point of failure

Why managed version of Kubernetes?

  • Reduces workload to manage k8s applications
  • makes it easy for you to run Kubernetes on AWS without needing to stand up or maintain your own Kubernetes control plane

Interfaces to AWS EKS

  1. AWS Console
  2. CLI
    • can use  kubectl to communicate with your cluster
  3. SDK

EKS Cluster

  1. First step is to create EKS cluster
    • which is Kubernetes Control plane
    • provision control plane instances in AWS service account (not customer account) in multiple availability zones
      • EKS is by default Highly Available (HA)
    • cluster is configurable e.g. define name of cluster, k8s version, IAM role, vpc subnets etc.
    • AWS EKS automatically detects and replaces unhealthy control plane instances, and it provides automated version upgrades and patching for them
  2. Launch EC2 worker nodes that register with the Amazon EKS cluster

AWS EKS Integrations

  • Elastic Load Balancing for load distribution (Scalability)
  • IAM for authentication (Security)
  • Amazon VPC for isolation Security)
  • use all the existing plugins and tooling from the Kubernetes community (Extensible)

Networking

EKS Security

UI Dashboard

Logging/Monitoring

  • AWS EKS is integrated with CloudTrail and logs actions taken by user and activity calls

Resources

OpenID Connect (OIDC)

OpenID Connect (OIDC) 1.0

  • Identity layer on top of OAuth 2.0
  • It allows Relying Party (RP) to verify the identity of the End-User based on the authentication performed by an OAuth 2.0 Authorization Server (OP), as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner
  • Uses REST/JSON message flows
  • (Identity, Authentication) + OAuth 2.0 = OpenID Connect
  • OpenID Connect is the third generation of OpenID technology (after OpenID and OpenID 2.0)
  • developed in an OpenID Foundation working group
  • also defines optional mechanisms for robust signing and encryption

Problem solved by OICD

  • Authenticate without taking responsibility of storing/managing passwords
  • Delicate authentication to third party OAuth 2.0 Authentication Server

Why use OICD?

  • Interoperable
  • Secure
  • Ease of deployment
  • Flexible
  • IoT support
  • Separation of concerns: Enabling Claims Providers to be distinct from Identity Providers

OAuth 2.0 vs OIDC

OAuth 2.0

OIDC

 Framework designed to support the development of authentication and authorization protocols OpenID Connect uses OAuth 2.0 to provide Identity services (using JSON messages)

OICD vs SAML

OICD

SAML

 JSON/REST based Security Assertion Markup Language (SAML) is an XML-based
 OpenID Connect was designed to also support native apps and mobile application  SAML was designed only for Web-based applications

Abstract OICD Workflow

  1. The RP (Client) sends a request to the OpenID Provider (OP).
  2. The OP authenticates the End-User and obtains authorization.
  3. The OP responds with an ID Token and usually an Access Token.
  4. The RP can send a request with the Access Token to the UserInfo Endpoint.
  5. The UserInfo Endpoint returns Claims about the End-User.

OpenID Connect Roles

OICD as Provider (OP)

  • OAuth 2.0 Authentication Servers implementing OpenID Connect are also referred to as OpenID Providers (OPs)
  •  Provides endpoints such as
    • Authorization Endpoint: Performs authentication of the user using request parameters defined by OAuth 2.0 and additional parameters and parameter values defined by OpenID Connect. Returns an authorization code.
    • Token Endpoint: Issues an access_token, id_token and refresh_token to the RP
    • Introspection Endpoint: Used for determining the status of a current access_token (valid or invalid)
  • 5 types
    • Basic OP
    • Implicit OP
    • Hybrid OP
    • Config OP
    • Dynamic OP

OICD as Relying Party (RP)

  •  OAuth 2.0 Clients using OpenID Connect are also referred to as Relying Parties (RPs)
  • Relying Party can obtains Authorization Endpoint and Token Endpoints from OICD provider  using  OpenID Connect Discovery
  • 5 types
    • Basic RP
    • Implicit RP
    • Hybrid RP
    • Config RP
    • Dynamic RP

OpenID Connect Discovery 1.0

  • Relying Party can obtain configuration information about the OpenID Provider, including its Authorization Endpoint and Token Endpoint locations using OICD Discovery 1.0

OpenID Connect Dynamic Client Registration 1.0

  • Relying Party can obtain sufficient credentials and provided information needed to use the OpenID Provider using OICD dynamic client registration 1.0

OAuth 2.0 Flows

  • Provides three flows

Authorization Code Flow

The Authorization Code Flow goes through the following steps.

  1. Client prepares an Authentication Request containing the desired request parameters.
  2. Client sends the request to the Authorization Server.
  3. Authorization Server Authenticates the End-User.
  4. Authorization Server obtains End-User Consent/Authorization.
  5. Authorization Server sends the End-User back to the Client with an Authorization Code.
  6. Client requests a response using the Authorization Code at the Token Endpoint.
  7. Client receives a response that contains an ID Token and Access Token in the response body.
  8. Client validates the ID token and retrieves the End-User’s Subject Identifier.

Implicit Flow

  • OAuth 2.0 flow in which all tokens are returned from the Authorization Endpoint and neither the Token Endpoint nor an Authorization Code are used

The Implicit Flow follows the following steps:

  1. Client prepares an Authentication Request containing the desired request parameters.
  2. Client sends the request to the Authorization Server.
  3. Authorization Server Authenticates the End-User.
  4. Authorization Server obtains End-User Consent/Authorization.
  5. Authorization Server sends the End-User back to the Client with an ID Token and, if requested, an Access Token.
  6. Client validates the ID token and retrieves the End-User’s Subject Identifier.

Hybrid

  • OAuth 2.0 flow in which an Authorization Code is returned from the Authorization Endpoint, some tokens are returned from the Authorization Endpoint, and others are returned from the Token Endpoint

The Hybrid Flow follows the following steps:

  1. Client prepares an Authentication Request containing the desired request parameters.
  2. Client sends the request to the Authorization Server.
  3. Authorization Server Authenticates the End-User.
  4. Authorization Server obtains End-User Consent/Authorization.
  5. Authorization Server sends the End-User back to the Client with an Authorization Code and, depending on the Response Type, one or more additional parameters.
  6. Client requests a response using the Authorization Code at the Token Endpoint.
  7. Client receives a response that contains an ID Token and Access Token in the response body.
  8. Client validates the ID Token and retrieves the End-User’s Subject Identifier.

Privacy

  • OpenID Connect identifies a set of personal attributes that can be exchanged between Identity Providers and the apps that use them, and includes an approval step so that users can consent (or deny) the sharing of this information.

Terminology

  • Authentication: Process used to achieve sufficient confidence in the binding between the Entity and the presented Identity
  • Authentication Request: OAuth 2.0 Authorization Request using extension parameters and scopes defined by OpenID Connect to request that the End-User be authenticated by the Authorization Server, which is an OpenID Connect Provider, to the Client, which is an OpenID Connect Relying Party
  • Authentication Context: Information that the Relying Party can require before it makes an entitlement decision with respect to an authentication response. Such context can include, but is not limited to, the actual authentication method used or level of assurance such as entity authentication assurance level
  • Authentication Context Class: Set of authentication methods or procedures that are considered to be equivalent to each other in a particular context
  • Authentication Context Class Reference: Identifier for an Authentication Context Class
  • Authorization Code Flow: OAuth 2.0 flow in which an Authorization Code is returned from the Authorization Endpoint and all tokens are returned from the Token Endpoint
  • Claim: Piece of information asserted about an Entity. Information asserted about a user, such as a first name or phone number
  • Claim Type: Syntax used for representing a Claim Value. This specification defines Normal, Aggregated, and Distributed Claim Types
  • Claims Provider: Server that can return Claims about an Entity
  • Credential: Data presented as evidence of the right to use an identity or other resources
  • End-User: Human participant
  • Entity: Something that has a separate and distinct existence and that can be identified in a context. An End-User is one example of an Entity
  • Essential Claim: Claim specified by the Client as being necessary to ensure a smooth authorization experience for the specific task requested by the End-User
  • Hybrid Flow: OAuth 2.0 flow in which an Authorization Code is returned from the Authorization Endpoint, some tokens are returned from the Authorization Endpoint, and others are returned from the Token Endpoint
  • ID Token: JSON Web Token (JWT)  that contains Claims about the Authentication event. It MAY contain other Claims
  • Identifier: Value that uniquely characterizes an Entity in a specific context
  • Identity: Set of attributes related to an Entity
  • Implicit Flow: OAuth 2.0 flow in which all tokens are returned from the Authorization Endpoint and neither the Token Endpoint nor an Authorization Code are used
  • Issuer: Entity that issues a set of Claims.
  • Issuer Identifier: Verifiable Identifier for an Issuer. An Issuer Identifier is a case sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components
  • Message: Request or a response between an OpenID Relying Party and an OpenID Provider
  • OpenID Provider (OP): OAuth 2.0 Authorization Server that is capable of Authenticating the End-User and providing Claims to a Relying Party about the Authentication event and the End-User
  • Request Object: JWT that contains a set of request parameters as its Claims
  • Request URI: URL that references a resource containing a Request Object. The Request URI contents MUST be retrievable by the Authorization Server
  • Pairwise Pseudonymous Identifier (PPID): Identifier that identifies the Entity to a Relying Party that cannot be correlated with the Entity’s PPID at another Relying Party
  • Personally Identifiable Information (PII): Information that (a) can be used to identify the natural person to whom such information relates, or (b) is or might be directly or indirectly linked to a natural person to whom such information relates
  • Relying Party (RP): OAuth 2.0 Client application requiring End-User Authentication and Claims from an OpenID Provider
  • Sector Identifier: Host component of a URL used by the Relying Party’s organization that is an input to the computation of pairwise Subject Identifiers for that Relying Party
  • Self-Issued OpenID Provider: Personal, self-hosted OpenID Provider that issues self-signed ID Tokens
  • Subject Identifier: Locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client
  • UserInfo Endpoint: Protected Resource that, when presented with an Access Token by the Client, returns authorized information about the End-User represented by the corresponding Authorization Grant. The UserInfo Endpoint URL MUST use the https scheme and MAY contain port, path, and query parameter components.ValidationProcess intended to establish the soundness or correctness of a construct
  • Verification: Process intended to test or prove the truth or accuracy of a fact or value
  • Voluntary Claim: Claim specified by the Client as being useful but not Essential for the specific task requested by the End-User.

Extra

  • To verify google access token
    • https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=
  • Google Client libraries  – to take care of many of the implementation details of authenticating users and gaining access to Google APIs. Authenticating users properly is important to their and your safety and security, and using well-debugged code written by others is generally a best practice – https://developers.google.com/identity/protocols/OpenIDConnect#libraries
  • Google API scopes https://developers.google.com/identity/protocols/googlescopes
  • OpenID Connect response sample from Google
{
  "stat": "ok",
  "profile": {
    "displayName": "xyz",
    "email": "xyz@gmail.com",
    "gender": "male",
    "googleUserId": "xyz",
    "identifier": "https://www.google.com/profiles/xyz",
    "name": {
      "familyName": "xyz",
      "formatted": "xyz",
      "givenName": "xyz"
    },
    "photo": "https://lh6.googleusercontent.com/-xyz/xyz/AAAAAAAAPIk/Ivgln2e27iY/photo.jpg?sz=50&sz=400",
    "preferredUsername": "xyz",
    "providerName": "Google+",
    "providerSpecifier": "googleplus",
    "provider_id": "114164066252810302501",
    "url": "https://plus.google.com/+xyz",
    "verifiedEmail": "xyz@gmail.com"
  },
  "accessCredentials": {
    "accessToken": "ya29.GlufBZGH9hZhqe60ij_YwJ4lSeAQeKexyzxyzxyzxyz",
    "clientId": "xyzxyz-xyzxyzxyzxyzxyz.apps.googleusercontent.com",
    "expires": 1523908723,
    "refreshToken": "1/QrxWKVPnVyxyzxyzxyzxyzxyzL4WbxCjrN5xwzXnQ",
    "scopes": "openid",
    "type": "openidconnect",
    "uid": "114164123456810302501"
  }
}

Resources

SAML 2.0

Security Assertion Markup Language (SAML 2.0)

  • XML-based framework that enables exchange of identities/access (authentication and authorization) information in a safe, secure and standard way
  • It is used to provide Single Sign-on (SSO) and Single Logout (SLO) between security domains
  • enables web-based, cross-domain single sign-on (SSO)
  • uses security tokens that contain assertions, which are used to  pass data between a SAML Identity Provider (IdP) and a Service Provider (SP)
  • Documents – SAMLCore, SAMLBind, SAMLProf, and SAMLMeta
  • SAML specification was developed and is maintained by the Security Services Technical Committee of OASIS.
  • SAML 2.0 became an OASIS Standard in March 2005

Why SAML?

  • Interoperable – SAML provides a set of interoperable standard interfaces. Standardizing the interfaces between systems allows for faster, cheaper, and more reliable integration
  • 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.
  • 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) with 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.
  • 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.

Roles

Principal

  • Requests a service from Service Provider

Identity Provider (IdP)

  • Asserting party – Authenticates the identity

Service Provider (SP)

  • requests and obtains an authentication assertion from the identity provider

SAML Components

Source

SAML Core

SAML Bindings

SAML SOAP binding

SAML MetaData

SAML Profiles

  • Specification [SAMLProf] provides a baseline set of profiles for the use of SAML assertions and protocols to accomplish specific use cases or achieve interoperability when using SAML features
  • Combinations of assertions, protocols and bindings to support a defined use case
  • concrete manifestation of a defined use case using a particular combination of assertions, protocols and bindings
  • https://www.oasis-open.org/committees/download.php/56782/sstc-saml-profiles-errata-2.0-wd-07.pdf

SSO Profiles

Web Browser SSO Profile

Enhanced Client or Proxy (ECP) Profile

Identity Provider Discovery Profile

Single Logout Profile

Name Identifier Management Profile

Artifact Resolution Profile

Assertion Query/Request Profile

Name Identifier Mapping Profile

SAML Attribute Profiles

SAML Assertion

  • package of information that supplies zero or more statements made by SAML Authority (asserting party) and received by relying party
  • <Subject> – Not necessarily but usually a human about which something is being asserted. subject and principal are used interchangeably sometimes
  • 3 types of assertion statements
    1. Authentication – assertion subject was authenticated by particular means at particular time
    2. Attribute – assertion subject is associated with supplied attributes
    3. Authorization Decision – allow assertion subject to access specific resource (grant or deny)

SAML Protocols

  • What is transmitted?
  • Requests and responses for obtaining assertions and doing identity management

Authentication Context

  • Detailed data on types and strengths of authentication

SAMLV2 Design Standards

XML

  • SAML exchanges encoded in XML
  • Use XML namespaces [XMLNS]
    Prefix XML Namespace
    saml: urn:oasis:names:tc:SAML:2.0:assertion (Assertion Namespace)
    samlp: urn:oasis:names:tc:SAML:2.0:protocol (Protocol Namespace)
    ds: http://www.w3.org/2000/09/xmldsig#
    xenc: http://www.w3.org/2001/04/xmlenc#
    xs: http://www.w3.org/2001/XMLSchema
    xsi: http://www.w3.org/2001/XMLSchemainstance
  • Assertions and protocols specified in XML Schema (XSD)
  • XML Signature used for digital signatures for message integrity
  • XML Encryption provides elements for encrypted

Common XML Elements in SAML

 <Assertion>

 Basic information common to all assertions. It further includes elements and attributes. Some of them are:

Version Required. SAML version e.g. “2.0”
ID Required. unique identifier for the assertion
IssueInstant Required. The time instant of issue in UTC
<Issuer> Required. SAML authority making claim in the assertion
<ds:Signature> Optional. XML signature. If it is present, relying party MUST verify that signature is valid
<Subject> Optional. Required in case of assertion with no statements
<Conditions>

XSD

<element name="Assertion" type="saml:AssertionType"/>
<complexType name="AssertionType">
   <sequence>
     <element ref="saml:Issuer"/>
     <element ref="ds:Signature" minOccurs="0"/>
     <element ref="saml:Subject" minOccurs="0"/>
     <element ref="saml:Conditions" minOccurs="0"/>
     <element ref="saml:Advice" minOccurs="0"/>
     <choice minOccurs="0" maxOccurs="unbounded">
       <element ref="saml:Statement"/>
       <element ref="saml:AuthnStatement"/>
       <element ref="saml:AuthzDecisionStatement"/>
       <element ref="saml:AttributeStatement"/>
     </choice>
 </sequence>
 <attribute name="Version" type="string" use="required"/>
 <attribute name="ID" type="ID" use="required"/>
 <attribute name="IssueInstant" type="dateTime" use="required"/>
</complexType>

HTTP

  • SAML uses HTTP as communication/transport protocol
  • SAML assertions are typically embedded in other structures for transport such as HTTP POST requests or XML encoded SOAP messages

Source: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html

SAML Security

  • TLS 1.0+ for transport level
  • XML Signature and XML Encryption for message-level security

Terminology

  • Assertion Queries
    • To load back assertion from cache
  • Attribute Queries
    • Lazy load user claims. Say user is part of 100s of groups. Not a good idea to pass all the attributes in single assertion. This feature can be used to load other information by making back channel call
    • something like /userinfo endpoint in OIDC
  • Artifact Resolution
    • Get assertion without browser agent
    • Get artifact from IdP
    • Exchange attributes with artifact with IdP
  • RelayState
    • maintains state

Resources

Spring Boot

 Spring Boot

  • Easy to create standalone applications
  • Handles predictable setup for developer e.g. If JPA implementation is on the classpath, it will automatically create JPA Entity Manager Factory
  • Embed containers (Tomcat, Jetty etc)
  • Automatically configure Spring components wherever possible
  • Very useful for rapid development
  • It is NOT code generator or IDE plugin

What does @SpringBootApplication do?

It adds following annotations

  • @Configuration tags the class as a source of bean definitions for the application context
  • @EnableAutoConfiguration tells Spring Boot to start adding beans based on classpath settings, other beans, and various property settings
  • It automatically adds @EnableWebMvc when it sees spring-webmvc on the classpath. This flags the application as a web application and activates key behaviours such as setting up a DispatcherServlet
  • @ComponentScan tells Spring to look for other components, configurations, and services in the package, allowing it to find the controllers

Spring Boot Parent POM and common starter dependencies

Parent POM

<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>

Common Starter Dependencies

<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>

  • spring-boot-starter
  • spring-boot-starter-web
  • spring-boot-starter-test
  • spring-boot-starter-jdbc
  • spring-boot-starter-jpa
  • spring-boot-starter-batch

Resources

Java 8 Stream API

Why Streams

  • If you are looping collection to run specific operation, streams is the solution
  • Process computations on large collections with less code, in parallel and efficiently

Streams

  • Stream is like pipeline of sequence of elements from a source (e.g. collections) that supports aggregate operations (e.g. filter, map, reduce, find, sorted, match)
  • Most of Stream operations returns Stream. Therefore multiple operations can be chained
  • Stream library uses internal iteration during on demand computation

Example

Extract even numbers; times 2 each; and order in descending order
List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8);
List<Integer> computedNumbers = numbers.stream()
		.filter(n -> {
			return n % 2 == 0;
			})
		.map(n -> {
			System.out.println("mapping " + n);
			return n * 2;
			})
		.sorted((a, b) -> b.compareTo(a))
		.collect(Collectors.toList());
System.out.println(computedNumbers);

Output
mapping 2
mapping 4
mapping 6
mapping 8
[16, 12, 8, 4]
  • stream() makes pipeline
  • .filter(Predicate<?>) extracts according to Lambda expression and returns Stream
  • .sorted(Predicate<?>) sorts according to Comparator provided as Lambda expression
  • Finally, used collect to retrieve as List. It is one of terminal operation used to close Stream pipeline

Resources

Lambda Expressions in Java 8

Functional Interface

  • A functional interface is any interface that contains only one abstract method
  • It may contain extra default or static methods

 Lambda Expressions

    • Treat functionality as method argument
    • It adds Functional behaviour to Java
    • It is basically an implementation of single abstract method in functional interface
    • Lambda expressions is preferred over Anonymous classes because later is bulky
    • JDK also has predefined standard Functional Interfaces e.g. Predicate

Example

Java predefined generic Predicate Interface (Functional Interface)

interface Predicate<T> {
    boolean test(T t);
}
  • Below method accepts Functional interface as input (Predicate in this case)
  • It then invokes one and only abstract method defined in the interface (test in this case)
  • Implementation of this abstract method is given by Lambda expression in following section
public static void displayStudentsOnCondition(
    // Predicate is generic interface
    List<Student> students, Predicate<Student> condition) {
    for (Student s : students) {
        // test method is declared in Predicate interface
        if (condition.test(s)) {
            System.out.println(s.toString());
        }
    }
}
  • Lambda expression is passed as parameter
  • Implementation of single abstract method in the functional interface is provided in Lambda expression
  • Arguments provided in the lambda expression are basically arguments to functional interface method (Predicate test in this case)
displayStudentsOnCondition(
    students,
    p -> p.getGender() == Person.Sex.MALE
        && p.getAge() >= 18
        && p.getAge() <= 25
)

Resources

Generics in Java

Generics

  • Introduced in JDK 1.5
  • Provide compile-time type safety
  • Enable developer to declare generic class or method

Some problems solved by Generics

Problem 1 – No compile-time safety

List list = new ArrayList();
list.add("oneness");
Integer i = (Integer)list.get(0); // throws run time ClassCastException
  • Generics provides compile-time safety and avoid run time errors like above
List<String> list = new ArrayList<>();
list.add("oneness");
// compile-time error Cannot cast from String to Integer
Integer i = (Integer) list.get(0);