Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Identity Management for Web Application Developers

360 views

Published on

Identity Management for Web Application Developers

Published in: Software
  • Be the first to comment

Identity Management for Web Application Developers

  1. 1. Identity Management for Web Application Developers Prabath Siriwardena prabath@wso2.com | prabath@apache.org Feb 2017
  2. 2. ● Identity Landscapes and Identity Management 101 ● Identity Federation and SSO ● Identity Provisioning ● Access Control ● Securing APIs ● Identity Governance and Administration Overview
  3. 3. ● The Director of Security Architecture, WSO2 ● Authored the book Advanced API Security - and three more About Me
  4. 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. 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. 6. Identity Landscapes & Identity Management 101 Feb 2017
  7. 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. 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. 9. ● Globally unique ○ IRIS, fingerprints? ● Unique within a closed environment ○ SSN, driving license number, emp number, first name Uniqueness of Identity Constituents
  10. 10. ● Self ○ Biometrics, DNA, first name, last name ● Inherited ○ Via relationships, memberships ● Externally endorsed ○ Not totally under your control Ownership of Identity Constituents
  11. 11. ● Fixed ○ Bio-metrics - but not all ● Near fixed ○ First name, citizenship ● Temporarily fixed ○ Phone number, email address Temporality of Identity Constituents
  12. 12. Environment Effect
  13. 13. Trustworthiness
  14. 14. ● Identity has a magnitude as well as a direction. ● Omnidirectional ○ Public identifiers ○ Facebook / LinkedIn profile ● Unidirectional ○ Private identifiers Directions
  15. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 30. Identity and Access Management
  31. 31. Identity and Access Management
  32. 32. Identity Federation & Single Sign-On Feb 2017
  33. 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. 34. ● SAML 2.0 Web SSO ● OpenID Connect ● WS-Federation ● OpenID ● CAS Standard Based Identity Federation
  35. 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. 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. 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. 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. 39. OpenID Connect
  40. 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. 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. 42. Identity Provisioning Feb 2017
  43. 43. Synchronization
  44. 44. Synchronization
  45. 45. Sharing
  46. 46. Single Sign On
  47. 47. Provisioning
  48. 48. Standard-based Provisioning SCIM 2.0
  49. 49. Standard-based Provisioning SPML 1.0 Request / Response
  50. 50. Standard-based Provisioning SPML 1.0 Request / Response
  51. 51. Standard-based Provisioning SPML 2.0 Request / Response [DSML]
  52. 52. Standard-based Provisioning SPML 2.0 Request / Response [XDS]
  53. 53. Standard-based Provisioning
  54. 54. SCIM 1.1
  55. 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. 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. 57. SCIM 1.1
  58. 58. Authenticating SCIM Requests • HTTP Basic Authentication • OAuth 2.0
  59. 59. Authenticating SCIM Requests
  60. 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. 61. Authenticating SCIM Requests
  62. 62. Federated Provisioning Patterns
  63. 63. Federated Provisioning Patterns
  64. 64. Federated Provisioning Patterns
  65. 65. Federated Provisioning Patterns
  66. 66. Federated Provisioning Patterns
  67. 67. Federated Provisioning Patterns
  68. 68. ● Just in time provisioning ● Associating workflows with user provisioning ● Outbound provisioning to Google Apps ● SCIM provisioning with the API Demo Time!!!
  69. 69. Access Control Feb 2017
  70. 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. 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. 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. 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. 74. XACML - Reference Architecture
  75. 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. 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. 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. 78. ● XACML TryIt ● XACML API for policy evaluation ● Engaging XACML policies in to the login flow Demo Time!!!
  79. 79. Securing APIs Feb 2017
  80. 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. 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. 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. 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. 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. 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. 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. 87. OAuth 2.0
  88. 88. Authorization Code Grant Type
  89. 89. Implicit Grant Type (I)
  90. 90. Implicit Grant Type (II)
  91. 91. Client Credentials Grant Type
  92. 92. Password Grant Type
  93. 93. SAML Grant Type Federated API Access
  94. 94. JWT Grant Type Federated API Access
  95. 95. Federated API Access Self-Contained Access Tokens
  96. 96. Self-Issued Access Tokens Federated API Access
  97. 97. Token Exchange Chained APIs
  98. 98. API Gateway Pattern
  99. 99. XACML Fine-grained Access Control
  100. 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. 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. 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. 103. Identity Governance & Administration Feb 2017
  104. 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. 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. 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. 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. 108. Thank You! Feb 2017

×