Software Architecture 2

Web App concept

Authentication , Authorization and Encryption

Authentication and Authorisation

. Authentication: process used to verify the identity of a user, system,
or entity. It ensures that the person or system trying to access a
particular resource or service is who or what it claims to be

• Authorisation - process of checking granted privileges of
  users/subsystems
  – access to a specific service
  – specific to a given application domain

• In multi-user systems during design: determine which services are
  shared among types of users

Authentication

Process f verifying the association between the identity of the user
or subsystem and the system. During analysis: identify the types of users (roles) interacting with
each feature

Encryption

ncryption involves the process of transforming data so that it is unreadable
by anyone who does not have a decryption key.
• A plain-text message is translated into an encrypted message (cipher text)
• Control measures for protecting passwords
– Hash (or digest) function (such as MD5 or SHA, SHA-2, SHA-3): maps the
value to be concealed to a fixed-length string called hash

Authorization - Role- based Access Control

Main concepts
– User: an individual’s account
– Role: conceptual group of authorisations
– Service: service provided by the system

Role-based access:
– One user can have
many roles
– Roles can authorise for
many services
– Users can only access
services if at least one
of their roles authorises
them for that service

Declarative Security

Declarative security configuration: access matrix

antMatchers(“/agents”, “/addAgent”).hasRole(“Supervisor”)
• To allow independent of role, e.g., to see start page: permitAll()
• To allow for a set of roles: hasAnyRole(“Supervisor”, “Agent”, …)

Imperative Security

We will use Spring Security for the level of requests, e.g., listing
agents or listing agent’s reports

However, security restrictions also apply based on the authenticated
user, e.g., an agent should see only their reports
– We will implement this programmatically (i.e., by coding it)

• Similar to parameter Model model in controller methods, the
  parameter Principal principal provides the authenticated user

Transport Layer Security (TLS)

a protocol that ensures secure communication over a
computer network
• operates at the transport layer of the Internet protocol
suite
• TLS is commonly used in HTTPS to protect sensitive
information, such as passwords and credit card details,
during transmission.

Secure Communication

Encryption is the process of transforming plain text/data into cipher
text that can only be read by the intended receiver (and the
sender)
• Data is encrypted using an encryption key: a secret numerical code
• Secure Sockets Layer (SSL) and successor Transport Layer Security
(TLS):
– Allow clients and servers to create secured sessions
– Encryption / decryption happen automatically, independently of
business logic interactions
– The browser is in charge of establishing the connection, not the
application code
– Client and server negotiate what key and security level to use
– Once a secure session is established, all messages in that session are
encrypted

HTTPS

Secure Hypertext Transfer Protocol (S-HTTP): protocol for
encrypting data over the Internet
• Limited to individual messages
• Independent of business logic
• Different methods of encryption
– symmetric key encryption
a single encryption key is shared by sender and receiver
– public key encryption

Public Key Encryption

Widely used in web applications, e.g., e-commerce
• Two keys are used
– Public key (shared): kept somewhere accessible by clients, used by
clients to encrypt messages
– Private key: kept secret, used by servers to decrypt message

Public Keys and Certification Authority

Digital certificate: data files used to establish the identity of users
and electronic assets for protection of online transactions
– uses a certification authority (CA) to validate the organisation identity
(e.g. a web app host)
– contains information about the organisation identity and the
organisation’s public key
• Establishing a secure connection
– Once the true identity of the company is verified, the digital certificate is
copied on to a CA server
– When a client accesses the web app, the CA sends the digital
certificate for establishing the secure connection
– The client uses the CA’s public key to decode the digital certificate
– Once the client verifies the company identity, it can use the companies
public key to encrypt/decrypt messages

OAuth 2.0

This is known open Authorization which is a standardized protocol for authorization that is commonly used to secure the access of application to APIs

• This is well known for scenarios where the third- part application needs to access resources on the behalf of a user without exposing their credential directly

Reasons to Adopt OAuth 2.0

• You need to handle users and roles

• you do not want to manage user accounts yourself

• you want to rely on well established - Services

• you want to streamline registration process to attract new users

• Improves UX

• More secure and scalable applications

Basic Concept

• Industry- Standard protocol for delegated authorization

• When a client application requires access to protected resources the client sends request to an authorization server

• The authorization server validates the requests and provides an access token

• The access token is validated for every client-to-server request

Roles

• Resources Owner - The user (person) giving access to some portion of their account

• client - The application attempting to access the user's account with their
  permission

• Authorisation Server - The server that presents the interface where the user approves or
  denies the request (might be the same as the resource server)
  

• Resources Server - The API server used to access the user's information. It's where
  the user's data is stored

Grant types

• Authorisation Code - for apps running on web server, browser- based and mobile apps

• Client credentials - for application access without a user present - the client will act on the behalf of the user

• Password - for logging in with username and password (only for first party apps ) can be insecure

OpenID connect

Extension to OAuth 2.0 for Authentication
• Introduces JWT: Json Web Token
– Private information that identifies the user
– Not an access token; cannot be used to access resources
– Standard fields/claims:
• sub: subject / user, unique and non-reassignable identifier for the user
• iss: issuer - Identifies the entity that issued the JWT (e.g., Google).
• aud: audience - Specifies the intended recipients of the JWT.
• exp: expiry time - Indicates when the JWT expires.
– Standard scopes:
• openid (mandatory), profile, email, etc
– Standard endpoints:
• /login, /token, /userinfo, etc

HTTP vs URL

A URL is the address used to access resources on the internet. URL – http://www.Muhammad.com/index.html
http://www.Muhammad.com:8080/index.htm
• URL tells the web browser the address of the resource to locate and
the protocol to use to retrieve that resource (http).
– Resources can be webpages, videos, audio files etc.
• http is the transfer protocol that transfer the resource from the server
to the client

Web APIs

API stands for Application Programming Interface. A Web API allows an application to expose some specific methods.

Web APIs use web protocols (HTTP, HTTPS, JSON, XML, etc.)

• Web APIs use web protocols (HTTP, HTTPS, JSON, XML, etc.)

  A software architectural style that defines a set of rules and
  conventions for the creation of an API.
  – Principles: efficient, scalable, simple, reliable and modifiable

Rest and HTTP

Roy Fielding was also one of the authors of the HTTP specification

• The REST constraints were created with HTTP in mind

• It relies on stateless communication between the client and the
server, meaning each request from the client to the server contains
all the information needed to understand and process the request.

• Although the REST architectural style could be applied to other
protocols besides HTTP, in practice RESTful APIs are largely
HTTP-based

REST and HTTP

GET - the GET method retrieves data without the side effect or state changes, making it safe to execute repeatedly.

When you open a web page in your browser it sends a GET request to the server to fetch the HTML, CSS and other assets needed to display the page.

• POST - used to create a data record or initiate an action. it is unsafe to execute more than necessary

REST and HTTP

• PUT- Used to update an existing data record , imagine you have an online to do list and you want to edit the
  details of a task. When you make changes and save them, a
  PUT request is sent to update the task's information on the
  server

• DELETE – Used to delete a resource identified by a URI.
  Repeating the request leads to the same result/state.
  – DELETE http://www.example.com/customers/12345
  – DELETE http://www.example.com/customers/12345/orders

RESTful API convention

Every HTTP request results in a status code sent back to the client
– 1xx: Informational – Communicates transfer protocol-level
information.

– 2xx status codes indicate success; most common code: 200 OK

– 3xx status codes indicate that the client needs to do something else
to complete the request, e.g., making the request to a different
location. Status code 301 means the resource has been permanently
moved somewhere else

– 4xx status codes indicate a client error (client sent incorrect request).
404 Not Found: https://www.google.com/bad, https://le.ac.uk/bad

– 5xx status codes indicate a server error – the server is experiencing
some difficulty, e.g., 500 Internal server error

• Documentation of the HTTP status codes can be found here:
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
Request
Status Code

POST REQUEST

• used to send data to the server
  • create a new repository on GitHub using a
  POST request.

Example of Request

Retrieve information from GitHub (GET requests)
• Create repositories and issues (POST requests)
• Add comments to issues (POST requests)
• Delete repositories (DELETE requests)

Lecture 4 you need to learn more

Terminology

• HTTP has verbs(methods ): GET, POST, PUT and DELETE

• REST is resource -oriented. A resources is an object or representation of something , which has some associated data with it and there can be set of methods that operates on it and a set of relationship to other resources

• A resource is represented by a URI: /hotels.
  • A collection is a set of resources, e.g. Companies are the collection
  of Company resources.
  • An endpoint is the combination of a verb and a URI, e.g. GET
  /hotels
  – This endpoint is designed to retrieve a list of hotels. Here, "GET" is the
  HTTP verb indicating that we want to retrieve data, and "/hotels" is the
  URI specifying the resource we are interested in, which, in this case, is a
  list of hotels.
  • A response's status is specified by its status code: 1xx for
  information, 2xx for success, 3xx for redirection, 4xx for client errors
  and 5xx for server errors

Naming Conventions

• Use nouns instead of verbs for endpoints (when naming your endpoints, focus on describing the accessed resource rather
  than the action being performed. For example, instead of "addHotel" or
  "deleteHotel", use "hotels" to represent the collection of hotels)

• Name collections using plural nouns

• Correct naming

  • GET /hotels/42
    – DELETE /hotels/43
    – POST /hotels (collection; passing JSON document for a hotel)
    – PUT /hotels/42

  • Incorrect
    – GET /addHotel42 (GET should be only used to read data)
    – GET /DeleteHotel/42 (Verb used in the endpoint, which is not recommended.)
    – POST /DeleteAllHotels (Inappropriate use of verbs and pluralisation)
    – POST /hotels/42/delete (Action should not be part of the endpoint; use appropriate HTTP
    methods for actions.)

    
    

Resource Nesting

Resource objects often have some kind of functional hierarchy or
relationships with other resources

For example, a room always belongs to some hotel therefore we
may have the following endpoints structure:
– GET /hotels/42/rooms – all the rooms in hotel 42
– GET /hotels/42/rooms/123 – room 123 in hotel 42
– DELETE /hotels/42/rooms/123
– POST /hotels/42/rooms (with JSON document for a room)
– PUT /hotels/42/rooms/123
• Generally, it is a good idea to limit nesting to one level
– GET /hotels/42/hotels/{hotel_id}/rooms - Incorrect double nesting

API Documentation

API documentation should provide information about the available
endpoints and methods
– With request/response examples, information about authorisation,
request limits

API Documentation Structure

Introduction – What exactly does the API provide?
Authentication – What types of authentication are supported, e.g.,
HTTP Basic Authentication? API Key Authentication?
Errors – Describe every error message users may come across when
using API
Endpoints and available parameters – Endpoints show the way to
access resources (one resource may have multiple endpoints).
Endpoints show only the end path (not the complete resource URL).
Four types of parameters: header, path, query, and request body.
Examples – Provide lots of them! Make it really easy for a new user to
integrate with your API
Limitations – Request limits? Throttling?

API documentation with Swagger

Rest API in Spring Boot

Lecture 5 go back

Software Testing

the selection of inputs for a system
with the intention of causing
failures in the system, and thereby
revealing the presence of faults”
• Concepts:
• Fault: Defect in the code (bug)
• Failure: manifestation of a fault
• Error: difference between actual output and expectation

Testing during Development

Unit Testing

White-box Testing
– Tests are based on implemented code (internal structure/ design).
– Tests aim to cover as much implemented behaviour as possible
– Coverage criteria are used, eg Branch Coverage
• Detect bugs at unit frontiers
• Typically written by developers, as opposed to dedicated testers
• Usually automated → regression testing
• xUnit Frameworks for most languages
– JUnit for Java, xUnit.net for.NET, … Lecture 6

Application Framework

Provides access to device hardware, location information,
background services, alarms, notifications, etc
• Designed for component reuse and interplay between apps; apps
can publish and reuse capabilities (subject to security constraints)
• Underlying all apps is a set of services and systems, including:
– Views, used to build apps, e.g., lists, grids, text boxes, buttons, browser
– Content Providers enable apps to interchange data with other
applications (e.g. Contacts)
– Resource Manager providing access to non-code resources such as
localised strings, images, and layout files
– Notification Manager enables apps to display custom alerts
– Activity Manager manages app lifecycle and navigation