Cloud Identity Management

Cloud Computing
Identity Management and Security
TECH9810 - System Architectures

Identity Management
● The term identity management describes the process of managing
individuals, entities or group authentication, authorisation, roles, privileges,
etc across the enterprise information systems suite
● The majority of enterprise applications will require the identity of their users
and entities to be verified and to restrict what actions particular users and
entities can carry out within them
● A typical enterprise user will need to access and use dozens of different
applications all of which will have this authentication and authorisation
requirement
● Same issue arises with cloud services

Centralised
● Intuitively, it makes sense that identity management would be largely
centralised within the Enterprise/Cloud for at least three compelling reasons
● The presumed tradeoff here the that the benefit of the increased complexity
and inflexibility of a centralised approach outweighs the downsides of a
looser, distributed autonomous approach
● Identity - The same user or entity (having a single identity everywhere) can be
managed and tracked across all of their application accesses and
● Security - Centralisation enforces consistency as to how privileges are applied and
standards are maintained across the enterprise IS suite; In addition, it is easier to
take remedial action in the event of a security breach
● Cost Control - Centralisation allows for the reduction or elimination of duplication
which should be more cost effective

Cloud Vendor Identity Management Systems
● All of the large providers offer, as a packaged service, some kind of identity
management tier which can be used to mediate access to cloud resources
● But cloud-based applications need to support some identity management
system at the application layer which may or may not be able to leverage the
vendor’s offering
● And anyway, there’s the lock-in consideration
● We’ll focus here on the application-layer building blocks as they pertain to
cloud-hosted application services in the enterprise context

Activation
● User identities are created using a process often known as activation
● This is a one-time event where a user is created within the identity
management system and assigned the appropriate privileges
● For example, onboarding a new employee or creating a materials supplier
account
● In the following discussion, we will assume that users are already activated
and have been provided their credentials and privileges

Authentication
● The term authenticate means to establish and verify the identity of some user
● Activated users authenticated through credentials usually comprising a
publicly-known part and one or more secrets, known only to the user
● The base assumption is that the activated user who can successfully pass a
credentials check is authenticated
● The authenticated user then assumes some preassigned identity within the
application(s) for subsequent access and actions

Authentication Strength
● Security is second only to correctness in enterprise information systems
because of the sensitivity of the data being managed and processed
● As authentication is the first line of defence of the access network and the
application software itself, enterprises increasingly employ ever more
sophisticated credential schemes to make them harder to compromise
● In general, the more secrets that are required, the more secure the scheme
will be
● Multi-factor authentication implies two or more secrets are needed
● Something you know and something you have
● Includes a so-called air-gap

Credentials Distribution
● The chicken and egg problem for authentication systems is how the would-be
authenticating user has possession of their credentials before they need to
use them (e.g. a shared secret or two-factor device)
● This is typically solved by using some out-of-band distribution mechanism, i.e.
over some other interface which is not the API itself
● Credentials distribution can be a complex problem and is the concern of the
wider identify management system itself
● We will assume, for our discussion, that the user already has somehow
obtained the necessary credentials prior to authentication

Authenticating Authority
● We will also assume the existence of some authenticating authority that we
can programmatically consult to authenticate a user
● In the context of a SOA, we can imagine this authority is just another service
that exposes a secure API allowing the users credentials to be presented and
a response as to whether that user is authenticated
● The authentication authority is itself an abstraction of the underlying identity
management system’s security mechanism and policy framework

Authenticating API Requests
● In SOA application stacks, each service makes requests of some other
service to carry out some function on its behalf
● In reality, a service request is typically carried out on behalf of some identity
(ultimately a user) which, in most cases, will require the request to be
authenticated and authorised before being executed
● There are two approaches for authenticating API requests, namely:
● In both approaches, the requesting service must possess the identity
credentials (shared secret) in advance by some out-of-band means
1. Authenticate each and every service request at request time
2. Preauthenticate in advance and use some temporary access token for each
subsequent request verified at request time

API Authentication Independence
● It is generally good practice to decouple the API authentication specification
from the API specification itself
● The principal advantage is that different mechanisms (or none) can used with
the same API in different contexts
● By implication, the API call syntax is therefore not directly polluted with
authentication syntax but rather as a wrapper around API messages
● In context of HTTP-based API like REST, the authentication data would
generally be carried in one or more specialised header fields
Auth Data
API Data

Authentication Methods
● We mentioned already, that there are two approaches for authenticating API
requests, namely:
● (1) is usually done using Hashing, and (2) is usually done with tokens (that
may or may not be encrypted.
1. Authenticate each and every service request at request time
2. Preauthenticate in advance and use some temporary access
token for each subsequent request verified at request time

Pre-authentication
● JSON web tokens (JWTs) are an example of a pre-authentication and token
scheme
● In pre-authentication schemes, the API caller performs the authentication
steps in advance and then uses some issued token to make subsequent API
requests
● The issued token, usually temporary in nature, acts as a cheaper-to-
implement proxy for having to authenticate each request separately
● In addition to being less resource-intensive, JWT pre-authentication, being
stateless, can also be easier to distribute, allowing for better performance and
scalability characteristics of the API system

How JWTs Work
● JWT is a simple idea which is based on secure message signing
1. The client issues an authentication request which includes the requester
credentials, called claims
2. The server verifies the claims for the requester with the authenticating authority
3. Assuming verified, the server then builds a BASE64-encoded token, which includes
caller identity information and an expiry timestamp
4. The token is then signed using a secure MAC by the authenticating authority using
its secret private key
5. The server responds to the client with the signed token to indicate success
6. In subsequent API requests, the client includes this token (called a bearer token) in
the request header
7. The server verifies the token signature using the public key and un-bundles the
token information to determine the user identity and token expiry timestamp
8. If successful, the server allows the request forward for further verification and
processing

● The logical view of JWT authentication looks like something like this:
JWT Authentication
Authenticating
Authority
API Server
Client Tier
Public Key
Private Key

RFC 7519
● At the time of writing the JWT authentication scheme is covered by an RFC
proposed standard which sets out the format of messages and the expected
behaviour of participating parties
● The standard describes the format of a token as follows (dot-separated)
Header Payload Signature
{
"typ": "JWT",
"alg": "HS256"
}
{
"sub": "user:12345",
"iat": "1300819380",
"exp": "1300829380"
}
Hashed and signed over the
previous parts:
● Header
● Payload
eyJhbGciOiJIUzI1NiIsI
nR5cCI6IkpXVCJ9...
eyJleHAiOjE0ODgxMzMzMjcsImlhdCI
6MTQ4Nzg3NDEyNywic3ViIj...
03f329983b86f7d9a9f5fef853
05880101d5e302afaf...
base64

Signing Method
● The JWT specification allows for different crypto technologies to be used in
the signing process
● The authenticating authority can include a field in the token specifying which
hashing and encryption algorithm was used to create the token signature (e.g.
HMAC-SHA256 or RSA-SHA256)
● If symmetric key signing is used, then both the issuer and the verifier need to
possess the same shared secret
● If asymmetric key signing is used, then the issuer can hold the private key
and the verifiers can use the public key

JWT Security Properties
● Operationally, it should be noted that the cryptography described in the RFC
7519 mechanism is used for signing tokens which establishes two important
facts about a token
● Importantly, RFC 7519 does not provide for token encryption so it is expected
that services using JWTs would independently implement some token or
transmission encryption system such as TLS
● The token must not be publicly divulged as an attacker could gain the same
access as the compromised user
1. The issuer’s identity because of the secret key in its possession
2. The token’s integrity (i.e. that it has not been altered in any way)

Javascript API
● Install crypto packages and tools with NPM
● Example usage in JS
npm install jsonwebtoken
var jwt = require('jsonwebtoken');
// sign with RSA SHA256 (i.e. using HMAC256 hashing)
var cert = fs.readFileSync('private.key'); // get private key from
disk
var token = jwt.sign({
sub: 'user:12345',
iat: Math.floor(Date.now() / 1000)
}, cert, { algorithm: 'RS256'});

Bearer Token
● Once created, signed and distributed by the server, the token can then be
used by the client to authenticate a particular identity (i.e. user)
● The client does this by including the token in each API request in a header
field
Authorization: BEARER
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE0ODg0NjQ5NTAsImlhdCI6MTQ4ODIwNTc1MC
wic3ViIjoiOWJhNGRlYWItMDdiMy00NTVjLTk1YTMtMDhkYmQ4MGFkMmUwIn0.NShG3qC2I_LBxZoKX-
8UBz_kFkWKSzJs6JrgDc27P9Lbd-OR9nIsV35Jk2uNvspJH2VyZ7bHS3RR-
8CtTexRqcsozrkZsicBWbauX4ph3DULGST5ju3tVNXi-NsQoFHij-
4BPGNMjjr4DftwnKmJeGA0dI4exZ0Q33AHJVjXNAEVA16x9FOBMkBfXXDQFKIyJtg46GB3hd7IX8Di4WB8i
V-
99bsb911UmSb1FKrZQ32zhpFQ0ybms2RGxN1MeMfYeZLjB4c3BpkrV84ucl3VoXd6qxWzuvWF9r6EyGa9kK
xgtGIDOZB0kYCSLLKef9i2EDxyTCRmOK8HJvYwNdH-Vg

Expiry and Revocation
● It is common and a good practice to set some expiry time for server-issued
tokens to force the API client to periodically reauthenticate
● This can be done including an expiry timestamp in the token which the client
is free to read
● In other circumstances, the server may want to revoke a token altogether
which can happen if:
● To implement revocation, the server (authenticating authority) must keep
track of issued tokens and their status - less flexible and less scalable in
practice
● The token is only intended to be user a fixed number of times (e.g. once)
● The associated identity credentials have been changed since the token was issued

Hash-based Message
Authentication

Authenticate Every Request
● An alternative to pre-authentication (and tokens) is to authenticate each
request individually
● Ideally we’d like to be able do this without having to incur any additional API
calls
● The context here is that the API calls are being made on behalf of some
identity which needs to be authenticated
● And we assume that client and server possess identity credentials (including
a shared secret) distributed in advance by some out-of-band means

A Note on Hashing
● A hash function is any function that can be used
to map data of arbitrary size to fixed-size values
● Use of hash functions relies on statistical
properties of key and function interaction: worst-
case behaviour is intolerably bad with a
vanishingly small probability, and average-case
behaviour can be nearly optimal (minimal
collision).
● A hashed value cannot be de-hashed, it’s a one-
way operation, unlike encryption.

Message Authentication
● A simple scheme which allows API calls to be authenticated with more extra
messages is to securely authenticate each request using the shared key
which works as follows:
1. The client generate a secure signature using on a HMAC (symmetric key) over the
API message contents
2. This signature is sent along with the API request and a unique key to identify which
user is making the request
3. On message receipt, the server, which also knows the shared secret key, generates
the signature for the API call and compares it with the one being sent
4. If they match, then the server can assume that the client was in possession of the
secret for the associated user (unique key) and is therefore authenticated

Security Properties
● It is assumed the the shared secret key is known only to the client and server
and would be “hard” to guess (e.g. 320 bits)
● The signature is based on a known-secure hashing algorithm with a
extremely low probability of collisions (e.g. SHA256)
● The hash is encrypted using a shared key symmetric-key algorithm (e.g.
HMAC-SHA256)
● It is impossible for an attacker to generate the MAC of message and a secret
key without knowing the secret key
● The message cannot be altered by an attacker and also pass the message
integrity and signature check

Security Guidelines
● There is no standard which dictates how hash-based message authentication
should be implemented but there are some good practice guidelines:
● In practice, enterprise solutions will provide for bespoke application-specific
implementations of these guidelines
1. Use known-secure crypto algorithms (hashing and encryption for signature)
2. Include the message body (if any), the query parameters (if any), the resource path
(assuming REST) and the unique key in the bytes block to be hashed
3. Randomise the request message signature to guard against replay attacks by, for
example, including a variable component such as a timestamp
4. Independently encrypt the message (e.g. TLS) for transmission
5. Periodically reissue new secret keys and invalidate old ones

HTTP Message Authentication
● Let’s consider an HTTP-based API request (e.g. REST) being authenticated
using HMAC-SHA256
● Keeping with the principle of separating authentication metadata from API
message data, we would see the authentication data being placed into a
HTTP header field as in the following example:
● The encoding can be implementation specific - (e.g. could use base64
instead of hexadecimal)
Authorization: HMAC-SHA256 Key=7e96106333af9110bc50d4f3cbfc806b76cf1a3a
Signature=d44869e9bb60c5696dc72199388f96d89739a800891242509fbb827b9fee6
40988eafc7db540283d

Considerations
● Hash-based message authentication (when done properly) is secure and
provides a high degree of confidence for authentication
● In theory, the per-request checking steps are no more expensive than pre-
authentication and token verification schemes
● However, the HMAC verification may need to consult the authenticating
authority each time so this can be more expensive and be less flexible and
scalable in practice - (i.e. only the authority has a copy of the shared secret
key)
● Generating signatures for API requests is non-trivial (a complex computation)
and this adds some logical complexity to the client-side in terms of signing
and solution testing

Authorization
● The term authorise will means to grant or reject access to specific operations
on behalf of an API requester
● A prerequisite for authorisation (usually) is that the requester identity has
already been verified, that is the requester has been authenticated
● By operation, we mean a query or an update of one or more service-managed
resources
● Authorisation asks the question “does this identity have rights to carry out this
operation on this resource?”
● For example, can a specific user add a new product to a catalog or change
the attribute value of a product item?

Authorisation Authority
● In the context of an enterprise application stack, the authorisation checking
would likely be carried out centrally within some component of the overall
identity management system
● The benefit of centralisation of authorisation is similar to the benefit of
centralised management of the authentication function, namely:
● Identity - The same user or entity (having a single identity everywhere) can be
managed and tracked across all of their application accesses
● Security - Centralisation enforces consistency as to how privileges are applied and
standards are maintained across the enterprise IS suite; In addition, it is easier to
take remedial action in the event of a security breach
● Cost Control - Centralisation allows for the reduction or elimination of duplication
which should be more cost effective

Granularity and Control
● At a high level, authorization is a mechanism for protecting assets from
unauthorised access or modification
● Depending on the application, some assets may be open for reading and
writing by anyone whereas others would be restricted to a small number of
privileged users
● Authorisation schemes are characterised by the level of granularity and
control they offer
● These range from crude CRUD-level checking to specific named operations
on specific attributes of a resource

Granularity Illustration
● Suppose there exists a products table describing items for sale
● Users could be authorised at the level of creating new products, reading
product descriptions, changing product descriptions or removing products
● Or alternatively, the authorisation could go down to the level of authorisation
reads and update to a specific product attribute or could include rights to carry
out other operations on the resource such as commenting on a product or
sharing the product with a third-party
● In general, the more sophisticated the sets of operations support on a
resource, the more granularity and control that is required

Rights and Privileges
● Rights (or privileges) are what determine what allowed to be carried out on a
resource
● An authorisation is essentially a conferral of zero or more rights (associated
with a resource) to a particular identity
● Resource rights can be granted or revoked and the managing services are
expected to honour these rights contracts in their API implementations

Role-Based Access Control
● A popular way to model and implement authorisation schemes is to control
access to resources and operations through a role abstraction
● A role is a convenience grouping of set of rights associated with an identity
● An identity may be assigned one or more roles
● The benefit of a role-based approach is that it simplifies the mapping of rights
to identities
● Roles recognise the reality that many of the same kinds of users will want
similar rights so the role acts as a convenience shorthand, albeit at the cost of
an extra level of indirection

Authorisation Failures
● From an API perspective there is a question as to how to handle authorisation
failures, i.e. requests for which the caller has insufficient rights to carry out,
including, say, read operations
● There are two popular approaches each with different security characteristics
1. Return an “not authorised” status code to the caller (e.g. HTTP 403). This has the
side-effect of validating the existence of the resource(s) but reporting that the
attempted operation is not allowed
2. Return a “not found” status code to the caller (e.g. HTTP 404). This has the
benefit of not leaking confirmation of the existence or non-existance of the
resource(s) but is indistinguishable from either

The Good, the Bad, and
the Interesting of
Identity Management

Identity Management: The Benefits
● Peace of mind
● The primary benefit of implementing it is simply
peace of mind.
● When the relevant people know precisely who
can access a business’s data, when they can
access it, and how much of it they can access, a
great sense of security is achieved.

● Boost in productivity
● By simply implementing IAM into any business,
productivity trends upwards by a fairly significant
amount. This can be traced back to IAM’s ability
to simplify sign-ins, signups, or processes related
to user management for end-users, systems
administrators, and app owners themselves.

● Reduced IT costs
● By utilizing IAM to free up time spent on role changes
or employee onboarding/offboarding, businesses can
slash costs by a surprising amount. Not only this, with
the inclusion of SSO (Single Sign-On), IT resources
are freed up due to a reduction in help desk calls and
service tickets.

● Information or data sharing
● By providing a platform for any information related to
access and ID management, businesses are able to
apply preset, customized security policies across all
the company’s devices, which ensures no
differentiation arises from one to the other (unless of
course the business wants this).

● Remote access
● As the possibilities of remote work among
businesses become more common,
employees and/or clients need access to
certain information, databases, webpages,
etc., regardless of their physical location.
SSO is a key feature in making this happen.

Identity Management: The Weaknesses
● Cloud security breaches
● If a business is committed to the cloud, access
management and user identities must be secure
to ensure minimal risk to the company’s and
clients’ data. If a company’s IAM is unsecure, it
has the potential to result in serious damage,
which could be detrimental to the business.

● Infrequent audits
● While IAM makes business policy implementation a
simple, streamline process, we need to update audit
practices so they pertain to the access policies
currently in place. It’s advised that businesses
continue to schedule regular audits to allow for the
potential discovery of vulnerabilities as well as for
defining what can and should be automated.

● Business scaling issues
● With the possibility of new technologies, staff, policies, or
other elements businesses may add as they grow, the IAM
framework must scale to keep up with any of these changes.
IAM, in some scenarios, can limit how these implementations
scale. This is not always the case, but for many businesses
that wish to scale as fast as possible, this is certainly
something to consider.

● Incorrect definition of roles or attributes
● With somewhat of a vague idea of what access is
required for certain user groups, many businesses
often include too many users in a single group. Based
on how permissions are defined, whether it’s by roles
or attributes, business leaders must take into account
why a person needs access to a particular resource.

● Offboarding of staff
● Believe it or not, offboarding employees can, at times,
pose serious threats to a business in the long run.
Though this is rarely a concern and only in some
cases amounts to anything serious, the chance for a
former employee to utilize their old business
permissions with malicious intent always exists.

Identity Management: Interesting
● Single sign-on capabilities are a must since
having too many passwords tends to lead to
insecure password management practices.
Recent research reported by Dark Reading
shows that 61% of people use the same
password for multiple accounts and
applications.

● Installing an IAM solution in place helps the
organization to cease manual privileges and
permission settings that can sometimes lead
to errors. Because of IAM, the IT team does
not have to manage access rights to user or
employee accounts manually – the process
will be automated.

● Security tools like IAM solutions come
with modern technologies like machine
learning (ML) algorithms to identify the
internal threats and notify the security
professionals for prompt actions.

Cloud Identity Management

Recommandé

Recommandé

Contenu connexe

Similaire à Cloud Identity Management

Similaire à Cloud Identity Management (20)

Plus de Damian T. Gordon

Plus de Damian T. Gordon (20)

Dernier

Dernier (20)

Cloud Identity Management