Identity Management for Web Application Developers

Identity Management for
Web Application Developers
Prabath Siriwardena
prabath@wso2.com | prabath@apache.org
Feb 2017

Identity Landscapes and Identity Management 101
Identity Federation and SSO
Identity Provisioning
Access Control
Securing APIs
Identity Governance and Administration
Overview

● The Director of Security Architecture, WSO2
● Authored the book Advanced API Security - and three more
About Me

Login to Salesforce with SAML 2.0
Login to Google Apps with SAML 2.0
Login to AWS with SAML 2.0 (IdP initiated)
Apache module for SAML 2.0 (with a PHP app)
Apache module for OpenID Connect (with a PHP app)
Login to a Java EE web app with SAML 2.0
Login to Salesforce with Facebook
Securing access to Google Apps with FIDO MFA
Just in time provisioning
Associating workflows with user provisioning
Demos

Outbound provisioning to Google Apps
SCIM provisioning with the API
XACML TryIt
XACML API for policy evaluation
Engaging XACML policies in to the login flow
Python client to get OAuth 2.0 access tokens
Client Credentials grant type
Password grant type
Authorization code grant type
Closer look at the JWT with the Chrome plugin
Publishing and securing an API with OAuth 2.0
Demos

Identity Landscapes & Identity
Management 101
Feb 2017

Identity Constituent Types
Uniqueness of Identity Constituents
Ownership of Identity Constituents
Temporality of Identity Constituents
Environment Effect
Level of Trustworthiness
Direction
Multiple Dimensions of Identity

Attributes
Skin color / hair color / eye color / first name / email
Behaviors
The boy who always scream in the classroom.
The girl who never comes to lectures on time.
The man who always drives reckless.
The lady who always starts anything with a ‘no’
Relationships
Obama’s daughters were shopping at the Macy’s.
Osama’s son boarded to a plane.
Identity Constituent Types

Globally unique
IRIS, fingerprints?
Unique within a closed environment
SSN, driving license number, emp number, first name
Uniqueness of Identity Constituents

Self
Biometrics, DNA, first name, last name
Inherited
Via relationships, memberships
Externally endorsed
Not totally under your control
Ownership of Identity Constituents

Fixed
Bio-metrics - but not all
Near fixed
First name, citizenship
Temporarily fixed
Phone number, email address
Temporality of Identity Constituents

Identity has a magnitude as well as a direction.
Omnidirectional
Public identifiers
Facebook / LinkedIn profile
Unidirectional
Private identifiers
Directions

Identity is “people’s concepts of who they are, of what sort of people they are,
and how they relate to others” — Hogg and Abrams 1988.
“Identity is used in this book to describe the way individuals and groups
define themselves and are defined by others on the basis of race, ethnicity,
religion, language, and culture” — Deng 1995.
Identity “refers to the ways in which individuals and collectivities are
distinguished in their social relations with other individuals and
collectivities” — Jenkins 1996.
Defining Identity

“National identity describes that condition in which a mass of people have
made the same identification with national symbols — have internalized
the symbols of the nation …” — Bloom 1990.
“Social identities are sets of meanings that an actor attributes to itself while
taking the perspective of others, that is, as a social object. … [Social
identities are] at once cognitive schemas that enable an actor to determine
‘who I am/we are’ in a situation and positions in a social role structure of
shared understandings and expectations” — Wendt 1994.
Defining Identity

“By social identity, I mean the desire for group distinction, dignity, and place
within historically specific discourses (or frames of understanding) about
the character, structure, and boundaries of the polity and the economy” —
Herrigel 1993.
“The term [identity] (by convention) references mutually constructed and
evolving images of self and other” — Katzenstein 1996.
“Identities are … prescriptive representations of political actors themselves
and of their relationships to each other” — Kowert and Legro 1996.
Defining Identity

“My identity is defined by the commitments and identifications which
provide the frame or horizon within which I can try to determine from
case to case what is good, or valuable, or what ought to be done, or what I
endorse or oppose” — Taylor 1989.
“Yet what if identity is conceived not as a boundary to be maintained but as a
nexus of relations and transactions actively engaging a subject?” — Clifford
1988.
“Identity is any source of action not explicable from biophysical regularities,
and to which observers can attribute meaning” — White 1992
Defining Identity

“Indeed, identity is objectively defined as location in a certain world and can
be subjectively appropriated only along with that world. … [A] coherent
identity incorporates within itself all the various internalized roles and
attitudes.” — Berger and Luckmann 1966.
“Identity emerges as a kind of unsettled space, or an unresolved question in
that space, between a number of intersecting discourses. … [Until recently,
we have incorrectly thought that identity is] a kind of fixed point of
thought and being, a ground of action … the logic of something like a ‘true
self.’ … [But] Identity is a process, identity is split. Identity is not a fixed
point but an ambivalent point. Identity is also the relationship of the Other
to oneself” — Hall 1989
Defining Identity

How close we can model one’s real identity in the digital world?
Most of the successful businesses try to model human behaviors from the
real world in the digital world.
Facebook, Uber
What are the benefits?
Map identities across different disconnected environments.
Know exactly who you talk to
Identify fake user accounts
Make context aware decisions
Personalized user experience
Weighted endorsements : LinkedIn?
Make knowledge based authentication more effective
Lead to password-less authentication
Make account recovery more effective
Fraud detection
Real Identity vs Digital Identity

Understand the dynamics causing digital identity systems to
succeed or fail in various contexts, expressed as the Laws of
Identity.
How we can prevent the loss of trust and go forward to give
Internet users a deep sense of safety, privacy, and certainty
about whom they are relating to in cyberspace.
Community effort initiated by Kim Cameron from Microsoft.
Seven Laws of Identity

User Control and Consent
Identity systems must only reveal information identifying a
user with the user's consent.
OpenID user consent
OAuth 2.0 scopes
UMA access control policies

Minimal Disclosure for a Constrained Use
The solution that discloses the least amount of identifying
information and best limits its use is the most stable long-
term solution.
Bartender only needs to know whether his customer’s age is
greater than 21, not the age.
Uber drivers need to call its passengers, only within a given,
limited time period, but they do not want to know the
passenger's’ phone numbers.

Justifiable Parties
Digital identity systems must be designed so the disclosure of
identifying information is limited to parties having a
necessary and justifiable place in a given identity
relationship.
Relying party information should be revealed to the user.
Microsoft Passport

Pluralism of Operators and Technologies
A universal identity system must channel and enable the
interworking of multiple identity technologies run by
multiple identity providers.
No single identity system is going to suffice in all contexts, and
no single identity provider is going to be justifiable in all
contexts.

Human Integration
The universal identity metasystem must define the human user
to be a component of the distributed system integrated
through unambiguous human-machine communication
mechanisms offering protection against identity attacks.
The last couple of feet between the computer console and the
human is where most bad things happen.
Phishing and other social engineering attacks exploit the user.
A stable identity system mitigates these threats.

Consistent Experience Across Contexts
The unifying identity metasystem must guarantee its users a
simple, consistent experience while enabling separation of
contexts through multiple operators and technologies.
A stable identity system presents an easy-to-understand
abstraction to the end user that is consistent no matter
what underlying technology or identity provider is
involved.

Directed Identity
A universal identity system must support both "Omni-directional" identifiers for
use by public entities and "unidirectional" identifiers for use by private
entities, thus facilitating discovery while preventing unnecessary release of
correlation handles.
Many public entities need to behave like beacons, broadcasting their identities to
the world. However, expect them to use a private identifier to track user’s
personal activity, so stable identity systems must support both
omnidirectional identity (beacons) and unidirectional identity (my private
relationship).
SAML NameID Policy
Persistent Pseudonym Identifiers
Transient Pseudonym Identifiers

Identity and Access Management (IAM) is the security discipline
that enables the right individuals (or things) to access the right
resources at the right times for the right reasons. (Gartner)
Business benefits
Business oversight
Business relationships
Business agility
Service delivery
User productivity
Cost reduction
Security
Regulatory compliance
Identity and Access Management

Identity and Access Management

Identity Federation & Single Sign-On
Feb 2017

Single Sign On - login once - access a set of services without further
login.
Federated identity management enables identity information to be
developed and shared among several entities and across trust
domains.
Single Sign On can be within a single trust domain and between
multiple trust domains.
Overview

SAML 2.0 Web SSO
OpenID Connect
WS-Federation
OpenID
CAS
Standard Based Identity Federation

Identity Provider
The authority behind user identities
Makes assertions about users (authentication, authorization,
attribute)
Relying Party / Service Provider / Client
Relying on an assertion provided by the identity provider.
Provides services to end users
Can be a mobile app / web app
Trusts one or more identity providers
Definitions

An XML standard for exchanging authentication and authorization data
between entities which is a product of the OASIS Security Services
Technical Committee.
SAML 1.0 was adopted as an OASIS standard in Nov 2002
SAML 1.1 was ratified as an OASIS standard in Sept 2003
SAML 2.0 became an OASIS standard in Mar 2005
Liberty Alliance donated its Identity Federation Framework (ID-FF)
specification to OASIS, which became the basis of the SAML 2.0
specification.
Thus SAML 2.0 represents the convergence of SAML 1.1, Liberty ID-FF 1.2,
and Shibboleth 1.3.
SAML 2.0 - Overview

Extensible Markup Language (XML)
XML Schema
XML Signature
XML Encryption (SAML 2.0 only)
Hypertext Transfer Protocol (HTTP) -
SOAP
SAML 2.0 - Base Standards

Assertions
Authentication, Attribute and Authorization information
Protocol
Request and Response elements for packaging assertions
Bindings
How SAML Protocols map onto standard messaging or communication
protocols
Profiles
How SAML protocols, bindings and assertions combine to support a
defined use case
SAML 2.0 - Components

SAML is XML based while OIDC is JSON based
SAML has multiple bindings while OIDC has one binding
Both are enterprise ready
In last couple of years - there were more OIDC implementations
than SAML
OIDC is more mobile and SPA friendly
Build a new app today? Use OIDC!
SAML 2.0 vs. OpenID Connect

Login to Salesforce with SAML 2.0
Login to Google Apps with SAML 2.0
Login to AWS with SAML 2.0 (IdP initiated)
Apache module for SAML 2.0 (with a PHP app)
Apache module for OpenID Connect (with a PHP app)
Login to a Java EE web app with SAML 2.0
Login to Salesforce with Facebook
Securing access to Google Apps with FIDO MFA
Demo Time!!!

Identity Provisioning
Feb 2017

Standard-based Provisioning
SCIM 2.0

SPML 1.0 Request / Response

SPML 2.0 Request / Response [DSML]

SPML 2.0 Request / Response [XDS]

SCIM 1.1
{"schemas":[],
"name": {"familyName":"siriwardena",
"givenName":"prabath"},
"userName":"prabath",
"password":"prabath123",
"externalId":"prabathext",
"emails":[ {"primary":true,
"value":"prabath@wso2.com",
"type":"home"},
{"value":"prabathsiriwardena@yahoo.com",
"type":"work"}]
}
curl -k --user admin:admin -d @add-user.json --header "Content-Type:application/json"
https://localhost:9443/wso2/scim/Users

SCIM 1.1
{"schemas":["urn:scim:schemas:core:1.0"],
"displayName" : "OSDC",
"externalId" : "OSDC",
"members": [
{
"value": "f64e6507-756d-4a14-ac43-c9d02167f411",
"display": "prabath"
}
]
}
curl -k --user admin:admin -d @add-group.json --header "Content-Type:application/json"
https://localhost:9445/wso2/scim/Groups

Authenticating SCIM Requests
• HTTP Basic Authentication
• OAuth 2.0

Authenticating SCIM Requests
curl -v -X POST
--basic -u XQi6DUDPnMW_FH_VK3f1gBetNAsa:VfKb7MHzH7Q0U6YdNV6ehhetCpka
-H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" -k
-d "grant_type=password&username=admin&password=admin"
https://localhost:9445/oauth2/token
curl -k
-H "Authorization: Bearer ea7f76f134eb9bbb12d4b06b93e1d0a3"
-d @add-user.json
--header "Content-Type:application/json”
https://localhost:9445/wso2/scim/Users
Get the Access Token from the OAuth Authorization Server
Add a user with via SCIM

Federated Provisioning Patterns

Just in time provisioning
Associating workflows with user provisioning
Outbound provisioning to Google Apps
SCIM provisioning with the API
Demo Time!!!

Permission
A capability
Negative permissions are hard
Role
A set of permissions
Group
A set of users
Role Based Access Control (RBAC)
Make access control decisions based on roles
Attribute Based Access Control (ABAC)
Make access control decisions based on attributes
Overview

Flat RBAC
Permissions are assigned to a role and a role is assigned to user (a group
of users)
Many to many relationship between user to role.
Many to many relationship between permission to role.
Hierarchical RBAC
Senior role and Junior roles.
A senior role acquires all the permissions belong to its junior roles.
A user can perform a given task if he/she inherits the required
permissions, either from a role he/she belongs to or from any other
juniors roles.

Constrained RBAC
Enforce Separation of Duties (SoD)
Separation of Duties (SoD) spreads authority and responsibility for an
action or a task over multiple users.
Symmetric RBAC
Supports permission-role review.

Fine-grained Access Control
Requirements from Health Care, DRM, Registry, Financial, Online Web
XACML 1.0 - OASIS Standard – 6 February 2003
XACML 1.1 – Committee Specification – 7th August 2003
XACML 2.0 – OASIS Standard – 1 February 2005
XACML 3.0 – OASIS Standard – 10th Aug 2010
XACML - Overview

XACML - Reference Architecture

XML based
Represents access control logic in rules
A given XACML policy can have multiple rules
A XACML engine can have multiple XACML policies
Only the XACML policies applicable to a given XACML request will
be evaluated.
XACML - Policy Language

The smallest execution unit in a XACML policy is a Rule
A Rule can return back Permit or Deny
Rule combining algorithms decide how to combine multiple
decisions from multiple Rules
The policy combining algorithms decide how to combine multiple
decisions from multiple policies.
Obligations and Advices
XACML - Policy Language

The XACML core specification defines XML based schema for the
XACML request and response.
JSON Profile for XACML define XACML request and response in
JSON
The REST profile XACML define how to invoke the XACML PDP in a
RESTful manner.
Multiple decisions
XACML - Request/Response Protocol

XACML TryIt
XACML API for policy evaluation
Engaging XACML policies in to the login flow
Demo Time!!!

Managed APIs
● The definition of the API has evolved over the time.
● It’s not just about the Application Programming
Interface.
● Hosted, web-centric and public facing.
● Public facing does not always mean it’s outside your
enterprise.
● Expose business functions to the rest of the world.
● Managed APIs
○ Secured
○ Monitored
○ Throttled

● Who’s going to access your API and from where?
○ Employees, within the domain or outside the domain or both.
○ Partners
○ Suppliers
○ Customers
○ General Public
Think About the Audience

● Is it a human or another system?
○ A user logs into a web app and the web app accesses an API on
behalf of the end user.
○ Web app does not worry about the who the end user is when talking
to an API

● Who is having control over the system, which talks to the APIs
○ Mobile app talks to an API - the end user has the total control
○ Web app talks to an API the end user has no control
○ SPA talks to an API the end user has no control
○ Trusted clients / public clients

● Direct Authentication
○ Trust the user directly - user could validate the trust by presenting
a token known to the user and the service provider (API) both.
○ User credentials are under the control of the service provider.
○ Authenticate to Github API with username/password.
● Brokered Authentication
○ Do not trust each and individual users - but some entity who can
assert a legitimate user to access the API.
○ User credentials are not under the control of the service provider.
○ The identity of the asserting entity can be validated by signature
verification.
○ Login with Facebook
Bootstrap Trust

● Direct Authentication
○ Username/password based authentication (basic auth)
○ OAuth 2.0
■ Authorization server and the resource server under the same
domain.
■ OAuth for authentication?
○ TLS mutual authentication
■ Trusts each certificate
○ JSON Web Token (JWT)
■ Self-issued JWT
○ Kerberos/NTLM
○ Custom API keys
Identify the Audience

● Brokered Authentication
○ OAuth 2.0
■ SAML 2.0 grant type
■ JWT grant type
■ ….
○ TLS mutual authentication
■ Trusts the issuer
○ JSON Web Token (JWT)
■ Trusts the issuer
Identify the Audience

SAML Grant Type
Federated API Access

JWT Grant Type

Self-Contained Access Tokens

Self-Issued Access Tokens

XACML
Fine-grained Access Control

● Use TLS in all the flows (bearer tokens)
● Store access tokens/refresh tokens/client credentials in a secure
storage (at the client side)
● Store hashed access tokens/refresh tokens/client credentials in a
secure storage (at the server side)
● Make sure access tokens/refresh tokens have the proper length to
tolerate brute-force attacks.
○ The token value should be >=128 bits long and constructed from
a cryptographically strong random or pseudo-random number
sequence
● Use strong client credentials
○ Use short-lived assertions as the client_secret
● Use OAuth state parameter to tolerate CSRF attacks.
● Use scoped access tokens.
● Use PKCE to tolerate authorization code interception attacks
(native mobile apps)
Security Considerations

● Enable throttling by user by application
● Use TLS token binding to tolerate token exports
● Restrict clients by grant types
● Avoid using the same client_id/client_secret for each instance of a
mobile app - rather use the Dynamic Client Registration API to
generate a key pair per instance.
● Short-lived access tokens
● Long-lived refresh tokens
● The token expiration time would depend on the following
parameters.
○ risk associated with token leakage
○ duration of the underlying access grant
○ time required for an attacker to guess or produce a valid token
● One time access tokens (based on the use case)
● Client should validate the token audience
Security Considerations

Python client to get OAuth 2.0 access tokens
Client Credentials grant type
Password grant type
Authorization code grant type
Closer look at the JWT with the Chrome plugin
Publishing and securing an API with OAuth 2.0
Demo Time!!!

Identity Governance & Administration
Feb 2017

Identity governance and administration (IGA) solutions manage
identity and access life cycles across multiple systems.
Automated provisioning of accounts among heterogeneous
systems.
Fulfillment of access requests (including self-service)
Password management Governance over user access to target
systems via workflows and automated policies.
Risk scoring of a user's combined entitlements Segregation of
duties (SOD) enforcement
Overview

Role management & role mining
Configuring a Role-Based Access-Control (RBAC) system, i.e.,
creating roles and assigning users to roles and permissions to
roles.
The term “role mining” is used in a more narrow sense to refer to
automated approaches to role engineering.
The role mining process discovers relationships between users
based on similar access permissions that can logically be
grouped to form a role.
Role engineers can specify the applications and attributes that will
return the best mining results.
Overview

Role consolidation
Prevents the creation of new roles with almost the same
membership and entitlements of existing role
Role Consolidation tells how similar two roles are based on the
two criteria: role membership and entitlements
Audit case incident management and analytics
Historical change, performance, recommendations for
entitlements or certifications, and so on.
Overview

User and Entity Behavior Analytics (UEBA)
UEBA is separate area of study, which focuses on analyzing the
behaviors of organizations’ insiders (employees), outsiders
connected to their networks (such as third party
contractors) and flagging security vulnerabilities across
organizations’ assets that hold sensitive data.
Overview

Identity Management for Web Application Developers

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (19)

Semelhante a Identity Management for Web Application Developers

Semelhante a Identity Management for Web Application Developers (20)

Mais de WSO2

Mais de WSO2 (20)

Último

Último (20)

Identity Management for Web Application Developers