Identity Management for Web Application Developers

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

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

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

4. ● 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

5. ● 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

6. Identity Landscapes & Identity
Management 101
Feb 2017

7. ● 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

8. ● 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

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

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

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

12. Environment Effect

13. Trustworthiness

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

15. ● 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

16. ● “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

17. ● “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

18. ● “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

19. ● “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

20. ● 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

21. ● 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

22. ● 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
Seven Laws of Identity

23. ● 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.
Seven Laws of Identity

24. ● 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
Seven Laws of Identity

25. ● 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.
Seven Laws of Identity

26. ● 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.
Seven Laws of Identity

27. ● 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.
Seven Laws of Identity

28. ● 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
Seven Laws of Identity

29. ● 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

30. Identity and Access Management

31. Identity and Access Management

32. Identity Federation & Single Sign-On
Feb 2017

33. ● 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

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

35. ● 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

36. ● 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

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

38. ● 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

39. OpenID Connect

40. ● 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

41. ● 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!!!

42. Identity Provisioning
Feb 2017

43. Synchronization

44. Synchronization

45. Sharing

46. Single Sign On

47. Provisioning

48. Standard-based Provisioning
SCIM 2.0

49. Standard-based Provisioning
SPML 1.0 Request / Response

50. Standard-based Provisioning
SPML 1.0 Request / Response

51. Standard-based Provisioning
SPML 2.0 Request / Response [DSML]

52. Standard-based Provisioning
SPML 2.0 Request / Response [XDS]

53. Standard-based Provisioning

54. SCIM 1.1

55. 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

56. 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

57. SCIM 1.1

58. Authenticating SCIM Requests
• HTTP Basic Authentication
• OAuth 2.0

59. Authenticating SCIM Requests

60. 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

61. Authenticating SCIM Requests

62. Federated Provisioning Patterns

63. Federated Provisioning Patterns

64. Federated Provisioning Patterns

65. Federated Provisioning Patterns

66. Federated Provisioning Patterns

67. Federated Provisioning Patterns

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

69. Access Control
Feb 2017

70. ● 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

71. ● 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.
Role Based Access Control (RBAC)

72. ● 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.
Role Based Access Control (RBAC)

73. ● 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

74. XACML - Reference Architecture

75. ● 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

76. ● 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

77. ● 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

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

79. Securing APIs
Feb 2017

80. 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

81. ● 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

82. ● 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
Think About the Audience

83. ● 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
Think About the Audience

84. ● 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

85. ● 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

86. ● 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

87. OAuth 2.0

88. Authorization Code Grant Type

89. Implicit Grant Type (I)

90. Implicit Grant Type (II)

91. Client Credentials Grant Type

92. Password Grant Type

93. SAML Grant Type
Federated API Access

94. JWT Grant Type
Federated API Access

95. Federated API Access
Self-Contained Access Tokens

96. Self-Issued Access Tokens
Federated API Access

97. Token Exchange
Chained APIs

98. API Gateway Pattern

99. XACML
Fine-grained Access Control

100. ● 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

101. ● 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

102. ● 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!!!

103. Identity Governance & Administration
Feb 2017

104. ● 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

105. ● 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

106. ● 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

107. ● 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

108. Thank You!
Feb 2017