Course Outcome(CO-4)

Utilize the security protocols and standards in different levels

Module-IV-Security Protocols and Standards

Host security, Compromise response

Security standards

Message Level Security (MLS),

Transport Level Security, OAuth, OpenID, eXtensible

Access Control Markup Language (XACML)

Security Assertion Markup Language (SAML).

 Host Security in Cloud Computing

Host security describes how your server is set up for the following tasks:
 Preventing attacks.

 Minimizing the impact of a successful attack on the overall system.

 Responding to attacks when they occur.

Host Security Service (HSS) helps you identify and manage the assets on your servers;
 manage programs,

 file integrity,

 security operations, and vulnerabilities;

 check for unsafe settings; and

 defend against intrusions and web page tampering.

There are also advanced protection and security operations functions available to help you easily detect and
handle threats.
During the review process of host security and assessing risks, one should always
consider the context of cloud service delivery models(IaaS, PaaS, and SaaS) and
various deployment models(Public, Private, and Hybrid).

SaaS and Paas Host Security

Generally, the cloud service providers do not share information regarding their host

platforms, hosts OS, and the processes that are in place to secure the hosts, as hackers
might exploit that information when they are trying to break into the cloud services.

Hence, in the context of System as a service(SaaS) or Platform as a service(PaaS)

cloud services security of the host should be non-transparent with the customers and
the responsibility of securing the host is confined to the cloud service providers.
• Virtualization is a technique that improves the host’s hardware utilization, along
with other benefits, it is common for cloud service providers to employ
virtualization platforms including VMware hypervisors and XEN, in their host’s
computing platform architecture.

• Apart from this one should be aware of how his provider is using the
virtualization technology and the provider’s process for securing the
virtualization layer.

• Both the SaaS and PaaS delivery models software platforms should abstract the host
operating system from the end user with a host abstraction layer. The accessibility
of the abstraction layer is different in each one of the delivery models (SaaS and
PaaS).
• In System as a Service, the abstraction layer is hidden from the users
and only available to the developers and the cloud service provider’s
operational staff.

• Whereas in Platform as a Service users have indirect access to the

abstraction layer in the form of PaaS API(Application programming
interface) that eventually interacts with the host abstraction layer.

• Thus, the customers of System as a Service(SaaS) and Platform as a

Service(Paas) rely on the cloud service providers to provide a secure host
platform on which the application is developed and deployed.
Infrastructure as a Service(IaaS) Host Security

The customers of Infrastructure as a Service(IaaS) are primarily responsible for

securing the hosts in the cloud, Infrastructure as a Service(IaaS) employs
virtualization at the host layer, IaaS host security can be categorized as follows:

Virtualization Software Security

It provides customers to create and terminate virtual instances. Virtualization can

be achieved by using virtualization models such as:-OS-level virtualization,
paravirtualization, or hardware-based virtualization. In public, IaaS application
customers do not have access to this software layer as it is managed by cloud
service providers.
Customer Guest OS or Virtual Server Security
The virtual instance of an operating system is placed above the
virtualization layer and is visible to customers from the internet.
Customers have full access to virtual servers.
For example:- various versions of Linux, Microsoft, and Solaris are
available in amazon’s aws for creating an instance.
Virtual Server Security
The customers of Infrastructure as a Service(IaaS) have full access to the
virtualized guest virtual machines that are hosted and isolated from each
other by hypervisor technology.
Thus, customers are responsible for the security management of the guest
virtual machines.
A public Infrastructure as a Service(IaaS) offers a web service API to
perform management functions such as provisioning, decommissioning,
and duplication of virtual servers on the IaaS platform itself.
 Host Security Threats in the Public IaaS

Deployment of malware embedded in software components in the

virtual machines.
Attack on that system which is not properly secured by the host firewalls

Attacks on accounts that are not properly secured eg. weak passwords,
repetitive passwords, etc.
Stealing keys that will be used to access and manage hosts(SSH private
keys).
 Securing Virtual Servers
Ways to Secure the Virtual Servers in the Cloud require Operational
Security procedures as:-
Safeguard the private keys as they might be used to access hosts in the
public cloud.
Never allow password-based authentication at the shell prompt.

Require passwords for role-based access eg., Solaris, SELinux.

Host firewall should be available to only minimum ports which are

necessary to support the services offered by the instances.
Disable the unused services and use only required services eg., Database
services, FTP services, print services, etc.
Periodically check the logs for any kind of suspicious activities.

Isolate the decryption keys from the cloud where the data is hosted–unless
required for decryption and use only for the duration of decryption activity.
Include no authentication credentials in virtualized images except for a key
to decrypt the file system.
Install a host-based intrusion detection system(IDS).

Protect the integrity of virtualized images from unauthorized access.

 Compromise Response
 Because you should be running an intrusion detection system, you should know very quickly if and

when an actual compromise occurs.

 If you respond rapidly, you can take advantage of the cloud to eliminate exploit-based downtime in your

infrastructure.

When you detect a compromise on a physical server, the standard operating procedure is a painful, manual
process:

1.Remove intruder access to the system, typically by cutting the server off from the rest of the network.

2.Identify the attack vector. You don’t want to simply shut down and start over, because the vulnerability
in question could be on any number of servers. Furthermore, the intruder very likely left a rootkit or
other software to permit a renewed intrusion after you remove the original problem that let him in
1.Wipe the server clean and start over. This step includes patching the
original vulnerability and rebuilding the system from the most
recent uncompromised backup.

2.Launch the server back into service and repeat the process for any
server that has the same attack vector.
This process is very labor intensive and can take a long time. In the cloud, the
response is much simpler.
First of all, the forensic element can happen after you are operating. You simply
copy the root filesystem over to one of your block volumes, snapshot your block
volumes, shut the server down, and bring up a replacement.
• Once the replacement is up (still certainly suffering from the underlying
vulnerability, but at least currently uncompromised), you can bring up a
server in a dedicated security group that mounts the compromised volumes.

• Because this server has a different root filesystem and no services running
on it, it is not compromised. You nevertheless have full access to the
underlying compromised data, so you can identify the attack vector.

• With the attack vector identified, you can apply patches to the machine
images. Once the machine images are patched, simply relaunch all your
instances.
Indicators of Compromise
 Unusual Outbound Network Traffic

 Anomalies in Privileged User Account Activity

 Geographical Irregularities

 Log-In Red Flags

 Increases in Database Read Volume

 HTML Response Sizes

 Large Numbers of Requests for the Same File

 Mismatched Port-Application Traffic

 Suspicious Registry or System File Changes

 Unusual DNS Requests

 Unexpected Patching of Systems

 Mobile Device Profile Changes

 Bundles of Data in the Wrong Place

 Web Traffic with Unhuman Behavior

 Signs of DDoS Activity

 Cloud Security Standards
• With the shift towards cloud infrastructure, compliance standards had to
evolve. Cloud services and platforms are now required to maintain
compliance with different federal, international, local, and state security
laws, regulations and standards.
• Compliance standards such as ISO, PCI DSS, HIPAA, and GDPR, have
specific requirements for cloud environments. Where mandatory
government regulations are concerned, violations may result in legal
penalties such as fines.
• In addition to general compliance standards, specialized standards have
evolved, which can help organizations achieve a secure cloud
environment. These include the Center for Internet Security (CIS) Cloud
Security Benchmarks, the Cloud Security Alliance (CSA) Controls Matrix,
and the Cloud Architecture Framework.
The Need for Cloud Security Standards
As organizations continue to migrate workloads to the cloud, they must
ensure that cloud computing is the correct delivery environment for their
applications.
The main concern is security and mitigating risk.
Businesses are evaluating whether sensitive data is safe in the cloud and
how to adopt cloud services while remaining compliant with standards
and regulations.
The cloud is, by nature, an attractive target for cyberattacks, because it is
exposed to public networks by default and is a well documented
environment that attackers are learning to exploit. Cloud configurations
are complex, and the large number of moving parts — such as VMs,
serverless functions, containers and storage buckets — each represent a
threat surface.
Both cloud providers and cloud users are finding it difficult to define what
they need to do to ensure a secure environment. There are many research
bodies, security best practices, and regulatory requirements, but no clear
standard or consensus on what constitutes a truly secure cloud
environment.
This makes it more important than ever for businesses to adopt a
framework that will help them address all aspects of cloud security —
including identity and access management (IAM), network security,
virtualization security, Zero Trust Network Access (ZTNA), endpoint
security, data privacy and content security.
Cloud Compliance: How Do Major Compliance Standards Impact the Cloud?
Here are some of the important security regulations around the world, and how they
may affect cloud security.
ISO Standards
The International Organization for Standardization (ISO) 27001 created a standard to
assist organizations, helping them safeguard their information using best practices.
The ISO has created standards for many kinds of systems and technologies, such as:
ISO/IEC 17789 (2014) — this standard outlines cloud computing activities, functional
components, and roles, including the way they interact.
ISO/IEC 19944-1 (2020) — this standard specifies how data is transported via cloud
service centers and cloud service users.
ISO/IEC Technical Specification 23167 (2020) — this standard specifies techniques
and technologies employed in cloud computing, such as VMs, containers, and
hypervisors.
ISO/IEC 27018 (2019) — this document describes guidelines founded on ISO/IEC
27002, emphasising the safeguarding of personal identifiable information (PII) within
the public cloud.
 Best Practices For Cloud Security
1. Secure Access to the Cloud
Although the majority of cloud service providers have their own ways of
safeguarding the infrastructure of their clients, you are still in charge of protecting
the cloud user accounts and access to sensitive data for your company. Consider
improving password management in your organization to lower the risk of account
compromise and credential theft.
Adding password policies to your cybersecurity program is a good place to start.
Describe the cybersecurity practices you demand from your staff, such as using
unique, complex passwords for each account and routine password rotation.
2. Control User Access Rights
Some businesses give employees immediate access to a wide range of systems and
data in order to make sure they can carry out their tasks effectively. For
cybercriminals, these individuals’ accounts are a veritable gold mine because
compromising them can make it simpler to gain access to crucial cloud infrastructure
and elevate privileges. Your company can periodically review and revoke user rights
to prevent this.
3. Transparency and Employee Monitoring
You can use specialized solutions to keep an eye on the behavior of your staff in
order to promote transparency in your cloud infrastructure. You can spot the
earliest indications of a cloud account compromise or an insider threat by keeping
an eye on what your employees are doing while they are at work. Imagine your
cybersecurity experts discover a user accessing your cloud infrastructure from a
strange IP address or outside of normal business hours. In that situation, they’ll be
able to respond to such odd activity promptly because it suggests that a breach may
be imminent.
4. Data Protection
This involves data protection against unauthorized access, prevention of accidental
data disclosure, and ensuring ceaseless access to crucial data in the case of failures
and errors.
5. Access Management
Three capabilities that are a must in access management are the ability to identify
and authenticate users, the ability to assign access rights to users, and the ability to
develop and enact access control policies for all the resources.
 Common Cloud Security Standards
1. NIST (National Institute of Standards and Technology)
NIST is a federal organization in the US that creates metrics and standards to boost competition in the scientific and
technology industries. The National Institute of Regulations and Technology (NIST) developed the Cybersecurity Framework
to comply with US regulations such as the Federal Information Security Management Act and the Health Insurance
Portability and Accountability Act (HIPAA) (FISMA). NIST places a strong emphasis on classifying assets according to their
commercial value and adequately protecting them.
2. ISO-27017
A development of ISO-27001 that includes provisions unique to cloud-based information security. Along with ISO-27001
compliance, ISO-27017 compliance should be taken into account. This standard has not yet been introduced to the
marketplace. It attempts to offer further direction in the cloud computing information security field. Its purpose is to
supplement the advice provided in ISO/IEC 27002 and various other ISO27k standards, such as ISO/IEC 27018 on the
privacy implications of cloud computing, and ISO/IEC 27031 on business continuity.
3. ISO-27018
The protection of personally identifiable information (PII) in public clouds that serve as PII processors is covered by this
standard. Despite the fact that this standard is especially aimed at public-cloud service providers like AWS or Azure, PII
controllers (such as a SaaS provider processing client PII in AWS) nevertheless bear some accountability. If you are a SaaS
provider handling PII, you should think about complying with this standard.
4. CIS controls
Organizations can secure their systems with the help of Internet Security Center (CIS) Controls, which are open-source
policies based on consensus. Each check is rigorously reviewed by a number of professionals before a conclusion is reached.
To easily access a list of evaluations for cloud security, consult the CIS Benchmarks customized for particular cloud service
providers. For instance, you can use the CIS-AWS controls, a set of controls created especially for workloads using Amazon
Web Services (AWS).
5. FISMA
In accordance with the Federal Information Security Management Act (FISMA), all federal agencies and
their contractors are required to safeguard information systems and assets. NIST, using NIST SP 800-53, was
given authority under FISMA to define the framework security standards (see definition below).
6. Cloud Architecture Framework
These frameworks, which frequently cover operational effectiveness, security, and cost-value factors, can be
viewed as best parties standards for cloud architects. This framework, developed by Amazon Web Services,
aids architects in designing workloads and applications on the Amazon cloud. Customers have access to a
reliable resource for architecture evaluation thanks to this framework, which is based on a collection of
questions for the analysis of cloud environments.
7. General Data Protection Regulation (GDPR)
For the European Union, there are laws governing data protection and privacy. Even though this law only
applies to the European Union, it is something you should keep in mind if you store or otherwise handle any
personal information of residents of the EU.
8. SOC Reporting
A form of audit of the operational processes used by IT businesses offering any service is known as a
“Service and Organization Audits 2” (SOC 2). A worldwide standard for cybersecurity risk management
systems is SOC 2 reporting. Your company’s policies, practices, and controls are in place to meet the five
trust principles, as shown by the SOC 2 Audit Report. The SOC 2 audit report lists security, availability,
processing integrity, confidentiality, and confidentiality as security principles. If you offer software as a
service, potential clients might request proof that you adhere to SOC 2 standards.
9. PCI DSS
For all merchants who use credit or debit cards, the PCI DSS (Payment Card Industry Data
Security Standard) provides a set of security criteria. For businesses that handle cardholder
data, there is PCI DSS. The PCI DSS specifies fundamental technological and operational
criteria for safeguarding cardholder data. Cardholders are intended to be protected from
identity theft and credit card fraud by the PCI DSS standard.
10. HIPAA
The Health Insurance Portability and Accountability Act (HIPAA), passed by the US Congress
to safeguard individual health information, also has parts specifically dealing with
information security. Businesses that handle medical data must abide by HIPAA law.
The HIPAA Security Rule (HSR) is the best choice in terms of information security. The
HIPAA HSR specifies rules for protecting people’s electronic personal health information
that a covered entity generates, acquires, makes use of or maintains.
Organizations subject to HIPAA regulations need risk evaluations and risk management
plans to reduce threats to the availability, confidentiality, and integrity of the crucial health
data they manage. Assume your company sends and receives health data via cloud-based
services (SaaS, IaaS, PaaS). If so, it is your responsibility to make sure the service provider
complies with HIPAA regulations and that you have implemented best practices for
managing your cloud setups.
11. CIS AWS Foundations v1.2
Any business that uses Amazon Web Service cloud resources can help
safeguard sensitive IT systems and data by adhering to the CIS AWS
Foundations Benchmark. Intelligence analysts developed a set of objective,
consensus-driven configuration standards known as the CIS (Center for
Internet Security) Benchmarks to help businesses improve their
information security. Additionally, CIS procedures are for fortifying AWS
accounts to build a solid foundation for running jobs on AWS.
12. ACSC Essential Eight
ACSC Essential 8 (also known as the ASD Top 4) is a list of eight
cybersecurity mitigation strategies for small and large firms. In order to
improve security controls, protect businesses’ computer resources and
systems, and protect data from cybersecurity attacks, the Australian Signals
Directorate (ASD) and the Australian Cyber Security Centre (ACSC)
developed the “Essential Eight Tactics.”
 Message-Level Security
Message-level security allows you to digitally sign or encrypt documents
exchanged between systems or business partners.
 It improves communication-level security by adding security features
that are particularly important for inter-enterprise communication.
Message-level security is recommended and sometimes a prerequisite for
inter-enterprise communication.
A digital signature authenticates the business partner signing the message
and ensures data integrity of the business document carried by a message.
Signatures are used in two scenarios:
○ Non-repudiation of origin
The sender signs a message so that the receiver can prove that the sender
actually sent the message.
○ Non-repudiation of receipt
The receiver signs a receipt message back to the sender so that the original
sender can prove that the receiver actually received the original message.
Message-level encryption is required if message content needs to be
confidential not only on the communication lines but also in intermediate
message stores.
 Configuring Message-Level Security
Message-level security applies security checks to a SOAP message after a Web services client
establishes a connection with an AquaLogic Service Bus proxy service or business service and before
the proxy service or business service processes the message.

To provide message-level security, AquaLogic Service Bus implements the features that are defined
in the OASIS standard for Web Services Security (WS-Security).

Inbound message-level security applies to messages between clients and AquaLogic Service Bus
proxy services. It applies security to both the request from the client and the response message back
to the client.

Outbound message-level security applies to messages between AquaLogic Service Bus proxy
services and SOAP-HTTP or SOAP-JMS business services. It applies security to both the request and
the response.
 Configuring Inbound Message-Level Security
You can configure a proxy service to support one of the following techniques for inbound message-level security:
Active-Intermediary
The proxy service processes the header in the client's SOAP messages and enforces the message-level access control
policy on the messages.
For example, a client encrypts and signs its SOAP message and sends it to a proxy service. The proxy service decrypts
the message and verifies the digital signature, then routes the message. Before the proxy service sends the response
back to the client, the proxy service signs and encrypts the message. The client then decrypts the message and
verifies the proxy service's digital signature.
Pass-Through
Instead of processing the header in the client's SOAP messages, the proxy service passes the message untouched to a
business service. Although the proxy service does not process the secured sections of the SOAP message, it can route
the message based on values in the header.
When the business service receives the message, it processes the security header and acts on the request. Note that
the business service must use the Web Services Policy (WS-Policy) framework to describe which of its operations are
secured with message-level security. The business service sends its response to the proxy service, and the proxy
service passes the response untouched to the client.
 Configuring Outbound Message-Level Security: Main Steps
Outbound message-level security applies to messages between AquaLogic Service
Bus proxy services and SOAP-HTTP or SOAP-JMS business services. It applies security
to both the request and the response.
To configure outbound message-level security for a business service that represents a
SOAP-HTTP or SOAP-JMS Web service:
In the AquaLogic Service Bus Console, import the Web service's WSDL document into
the AquaLogic Service Bus WSDL repository and resolve any WSDL dependencies.
In the AquaLogic Service Bus Console, do one or more of the following depending on
whether the WSDL document contains WS-Policy statements that
secure requests from a proxy service to the business service:
If any operation response policy in the business service requires encryption (that is,
the business service encrypts the response with the proxy service's encryption public
key), configure a proxy service provider and assign an encryption credential to the
proxy service provider.
 Transport Layer Security (TLS)
Transport Layer Security, or TLS, is a widely adopted security protocol
designed to facilitate privacy and data security for communications over
the Internet.
A primary use case of TLS is encrypting the communication between web
applications and servers, such as web browsers loading a website. TLS can
also be used to encrypt other communications such as email, messaging,
and voice over IP (VoIP).
In this article we will focus on the role of TLS in web application security.
TLS was proposed by the Internet Engineering Task Force (IETF), an
international standards organization, and the first version of the protocol
was published in 1999.
The most recent version is TLS 1.3, which was published in 2018.
 What does TLS do?

There are three main components to what the TLS protocol accomplishes:
Encryption, Authentication, and Integrity.
Encryption: hides the data being transferred from third parties.

Authentication: ensures that the parties exchanging information are who

they claim to be.
Integrity: verifies that the data has not been forged or tampered with.
What is a TLS certificate?

For a website or application to use TLS, it must have a TLS certificate

installed on its origin server (the certificate is also known as an "
SSL certificate" because of the naming confusion described above).
A TLS certificate is issued by a certificate authority to the person or
business that owns a domain.
The certificate contains important information about who owns the
domain, along with the server's public key, both of which are important for
validating the server's identity.
 How does TLS work?

A TLS connection is initiated using a sequence known as the TLS handshake. When
a user navigates to a website that uses TLS, the TLS handshake begins between the
user's device (also known as the client device) and the web server.
During the TLS handshake, the user's device and the web server:

Specify which version of TLS (TLS 1.0, 1.2, 1.3, etc.) they will use

Decide on which cipher suites (see below) they will use

Authenticate the identity of the server using the server's TLS certificate

Generate session keys for encrypting messages between them after the handshake
is complete
 OAuth 2.0
OAuth 2.0, which stands for “Open Authorization”, is a standard designed
to allow a website or application to access resources hosted by other web
apps on behalf of a user.
It replaced OAuth 1.0 in 2012 and is now the de facto industry standard for
online authorization.
OAuth 2.0 provides consented access and restricts actions of what the
client app can perform on resources on behalf of the user, without ever
sharing the user's credentials.
 Principles of OAuth2.0
OAuth 2.0 is an authorization protocol and NOT an authentication
protocol. As such, it is designed primarily as a means of granting access to a
set of resources, for example, remote APIs or user data.
OAuth 2.0 uses Access Tokens.

 An Access Token is a piece of data that represents the authorization to

access resources on behalf of the end-user.
OAuth 2.0 doesn’t define a specific format for Access Tokens. However, in
some contexts, the JSON Web Token (JWT) format is often used.
 OAuth2.0 Roles
The idea of roles is part of the core specification of the OAuth2.0 authorization
framework.
These define the essential components of an OAuth 2.0 system, and are as
follows:
Resource Owner: The user or system that owns the protected resources and
can grant access to them.
Client: The client is the system that requires access to the protected resources.
To access resources, the Client must hold the appropriate Access Token.
Authorization Server: This server receives requests from the Client for Access
Tokens and issues them upon successful authentication and consent by the
Resource Owner.
Resource Server: A server that protects the user’s resources and receives
access requests from the Client. It accepts and validates an Access Token from
the Client and returns the appropriate resources to it.
 How Does OAuth 2.0 Work?
At the most basic level, before OAuth 2.0 can be used, the Client must acquire its own
credentials, a _client id _ and client secret, from the Authorization Server in order to
identify and authenticate itself when requesting an Access Token.

Using OAuth 2.0, access requests are initiated by the Client, e.g., a mobile app, website,
smart TV app, desktop application, etc. The token request, exchange, and response
follow this general flow:

1.The Client requests authorization (authorization request) from the Authorization

server, supplying the client id and secret to as identification; it also provides the
scopes and an endpoint URI (redirect URI) to send the Access Token or the
Authorization Code to.
2.The Authorization server authenticates the Client and verifies that the
requested scopes are permitted.

3.The Resource owner interacts with the Authorization server to grant

access.

4.The Authorization server redirects back to the Client with either an

Authorization Code or Access Token, depending on the grant type, as it will
be explained in the next section. A Refresh Token may also be returned.

5.With the Access Token, the Client requests access to the resource from the
Resource server.
 OpenID

OpenID Connect or OIDC is an identity protocol that utilizes the

authorization and authentication mechanisms of OAuth 2.0. The OIDC
final specification was published on February 26, 2014, and is now widely
adopted by many identity providers on the Internet.
OIDC was developed by the OpenID Foundation, which includes
companies like Google and Microsoft
 How Does OpenID Connect Fit with OAuth2?

OIDC utilizes OAuth 2.0 as an underlying protocol.

The principal extensions are a special scope value (“openid”), the use of
an extra token (the ID Token, which encapsulates the identity claims in
JSON format), and the emphasis on authentication rather than
authorization.
 Also, in OIDC, the term “flow” is used in place of OAuth2 “grant”
 Principles and Definitions in OpenID Connect
 The OIDC provider (generally called the OpenID Provider or Identity Provider or IdP) performs user

authentication, user consent, and token issuance. The client or service requesting a user’s identity is
normally called the Relying Party (RP). It can be, for example, a web application, but also a JavaScript
application or a mobile app.

 Being built on top of OAuth 2.0, OpenID Connect uses tokens to provide a simple identity layer integrated

with the underlying authorization framework. This integration implies the use of the following types of
token:

 ID Token: Specific to OIDC, the primary use of this token in JWT format is to provide information about the

authentication operation’s outcome. Upon request, it may provide the identity data describing a user profile.
The data about the authentication result and the user profile information are called claims. The user profile
claims may be any data that is pertinent to the Relying Party for identification purposes, such as a persistent
ID, email address, name, etc.
Access Token: Defined in OAuth2, this (optional) short lifetime token provides access
to specific user resources as defined in the scope values in the request to the
authorization server.

Refresh Token: Coming from OAuth2 specs, this token is usually long-lived and may
be used to obtain new access tokens.

ID Tokens should be digitally signed to prevent tampering. They may also be
encrypted to provide additional privacy, although, in many cases, transport layer
security (HTTPS) is sufficient. For SPAs and mobile apps, ID Token encryption is not
useful, as the decryption key can be discovered easily.
 XACML (Extensible Access Control Markup Language)

Extensible Access Control Markup Language is an attribute-based

access control policy language or XML-based language, designed to
express security policies and access requests to information.
XACML can be used for web services, digital rights management, and
enterprise security applications. XACML is sometimes referred to as
Extensible Access Control Language.
 What are XACML use cases?
XACML is used to promote interoperability and common terminology for
access control implementations, where access attributes associated with a
user are used to decide whether a user may have access to a specific
resource.

Instead of an attribute-based access control, XACML can also be used as a

role-based access control (RBAC). To be clear, though, XACML does not
handle user access, approval, or password management.
 XACML terminology

The following are terms used with XACML policies.

Policy Administration Point (PAP). PAP is the point which manages
access authorization policies.
Policy Decision Point (PDP). This is the point where access requests are
evaluated against authorization policies before issuing access decisions.
Policy Enforcement Point (PEP). The PEP is where user access requests
are intercepted to make a decision request to the PDP.
The typical flow of an XACML request is as follows:

A user sends a request which is intercepted at the PEP.

The PEP converts the request into an XACML request.

The PEP transmits the request to the PDP.

The PDP evaluates the authorization request against the access policies it
has configured. Those policies are managed at thePAP. If necessary,
attribute values from Policy Information Points can also be retrieved.
Finally, at the PDP a decision is made, which will either be "Permit," "Deny,"
"NotApplicable," or "Indeterminate," and returned in boolean to the PEP.
XACML policy elements
The following is a high-level overview of the various elements that make up
an XACML policy.
Structure
The structure of XACML is split into the following three sections:
PolicySet
Policy
Rule (ruleID)
Attributes

All policy sets, requests and sets of rules use resources, subjects, environments and actions.
These are typically denoted in XACML syntax as "attributeID."

The subject (access-subject) is the entity requesting access.

The resource can be a service, data or a system component.

An action (action-ID) refers to the type of access requested.

The environment refers to an element that can provide additional information if necessary.

Targets

XACML language defines a target, which is the conditions for a resource, subject, resource or
action that are necessary to meet access requirements and provide an authorization decision.
XACML Architecture
 XACML policy language structure

Three top-level policy elements

<Rule>: contains a Boolean expression that can be evaluated in isolation, but that is not

intended to be accessed in isolation by a PDP. So, it is not intended to form the basis of an
authorization decision by itself. It is intended to exist in isolation only within an XACML PAP,
where it may form the basic unit of management

<Policy>: contains a set of <Rule> elements and a specified procedure for combining the

results of their evaluation. It is the basic unit of the policy used by the PDP, and so it is
intended to form the basis of an authorization decision

<PolicySet>: contains a set of <Policy> or other <PolicySet> elements and a specified

procedure for combining the results of their evaluation.

 Security Assertion Markup Language (SAML)
Security Assertion Markup Language (SAML) is an open standard that allows identity
providers (IdP) to pass authorization credentials to service providers (SP).
What that jargon means is that you can use one set of credentials to log into many
different websites.
It’s much simpler to manage one login per user than it is to manage separate logins to
email, customer relationship management (CRM) software, Active Directory, etc.
SAML transactions use Extensible Markup Language (XML) for standardized
communications between the identity provider and service providers.
SAML is the link between the authentication of a user’s identity and the authorization to
use a service.
What is a SAML Provider?
A SAML provider is a system that helps a user access a service they need. There
are two primary types of SAML providers, service provider, and identity provider.
A service provider needs the authentication from the identity provider to grant
authorization to the user.
An identity provider performs the authentication that the end user is who they say
they are and sends that data to the service provider along with the user’s access
rights for the service.
Microsoft Active Directory or Azure are common identity providers. Salesforce and
other CRM solutions are usually service providers, in that they depend on an
identity provider for user authentication.
 SAML Assertion
A SAML Assertion is the XML document that the identity provider sends to the service
provider that contains the user authorization. There are three different types of SAML
Assertions – authentication, attribute, and authorization decision.
Authentication assertions prove identification of the user and provide the time the user
logged in and what method of authentication they used (I.e., Kerberos, 2 factor, etc.)
The attribution assertion passes the SAML attributes to the service provider – SAML
attributes are specific pieces of data that provide information about the user.
An authorization decision assertion says if the user is authorized to use the service or if
the identify provider denied their request due to a password failure or lack of
rights to the service.
 How Does SAML Work?
SAML works by passing information about users, logins, and attributes between the
identity provider and service providers.
Each user logs in once to Single Sign On with the identify provider, and then the identify
provider can pass SAML attributes to the service provider when the user attempts to
access those services.
 The service provider requests the authorization and authentication from the identify
provider. Since both of those systems speak the same language – SAML – the user only
needs to log in once.
Each identity provider and service provider need to agree upon the configuration for
SAML.
 Both ends need to have the exact configuration for the SAML authentication to work.