Adding Identity Management and Access Control to your App
Download as PPTX, PDF3 likes911 views
The document discusses OAuth 2.0, a protocol allowing applications to access restricted resources without sharing user credentials, detailing its architecture, roles, and different grant types. It outlines the implementation of OAuth 2.0 in the FIWARE ecosystem, including identity management, authorization, and security measures for IoT authentication. Additionally, it contrasts Role-Based Access Control (RBAC) with Attribute-Based Access Control (ABAC), advocating for ABAC as a more flexible and scalable solution for managing complex access permissions.
Adding Identity Management and Access Control to your App
- 4. OAuth 2.0 4
- 6. OAuth 2.0 ▪ Mechanism to provide applications access to restricted resources without sharing credentials. • Applications use access tokens, issued by OAuth providers (e.g. FIWARE), to access resources. • OAuth 2.0 specification is designed for use with HTTP. ▪ Roles: • Resource Owner: Entity capable of granting access to a protected resource (e.g. end-user) • Resource Server: Server hosting protected resources. • Client: Application making protected resource requests on behalf of the resource owner. • Authorization Server: The server issuing access tokens to the client.
- 7. OAuth 2.0 Architecture Authorization Code Grant OAuth Provider account.lab.fiware.org
- 8. Using OAuth2 Authorization Code Grant
- 9. Using OAuth2 Authorization Code Grant
- 10. Using OAuth2 Authorization Code Grant
- 11. Using OAuth2 Authorization Code Grant
- 12. OAuth 2.0 Architecture Implicit Grant OAuth Provider account.lab.fiware.org
- 13. OAuth 2.0 Architecture Resource Owner Password Credentials Grant OAuth Provider account.lab.fiware.org
- 14. OAuth 2.0 Architecture Resource Owner Password Credentials Grant OAuth Provider account.lab.fiware.org
- 15. OAuth 2.0 Libraries ▪ http://oauth.net/2/ • PHP, Cocoa, iOS, Java, Ruby, Javascript, Python. ▪ Example using Node.js • https://github.com/ging/oauth2-example-client 15
- 16. OAuth2 credentials in FIWARE Account
- 17. Getting protected user info 17 Web App Account OAuth2 requests flow access-token OAuthLibrary Request user info using access-token GET /user?access_token={token}
- 18. Web Applications and GEs 18 Generic Enabler Account Request+ access-token Oauth2 flows access-token OK + user info (roles) Web App OAuthLibrary access_token GET https://GE_URL HTTP/1.1 Host: GE_hostname X-Auth-Token: access_token
- 19. Securing your back-end 19 Back-end Apps Account Request+ access-token Web App OauthLibrary PEP Proxy access-token OK + user info (roles) Oauth2 flows access_token GET https://PEP_PROXY HTTP/1.1 Host: PEP_PROXY_hostname X-Auth-Token: access_token
- 20. PEP Proxy in FIWARE Lab Account
- 21. Securing your back-end ▪ Level 1: Authentication • Check if a user has a FIWARE account ▪ Level 2: Basic Authorization • Checks if a user has permissions to access a resource • HTTP verb + resource path ▪ Level 3: Advanced Authorization • Custom XACML policies
- 22. Level 1: Authentication 22 Back-end Apps Account Request+ access-token Web App OauthLibrary PEP Proxy access-token OK + user info (roles) Oauth2 flows access_token
- 23. Level 2: Basic Authorization 23 Back-end Apps Account Request+ access-token Web App OauthLibrary PEP Proxy access-token OK + user info Oauth2 flows access_token Authz PDP GE XACML <Request>: roles + verb + path OK Basic RBAC policies in XACML (simple role permissions)
- 24. Level 2: Basic Authorization
- 25. Level 3: Advanced Authorization 25 Back-end Apps Account Request+ access-token Web App OauthLibrary PEP Proxy extension Oauth2 flows access_token Auth PDP GE access-token OK + user info XACML <Request>: roles + verb + path OK More generic ABAC policies in XACML (custom XACML Rules)
- 26. Level 3: Advanced Authorization
- 27. IoT Authentication ▪ Context Broker • IoT Management • Publish / subscribe model □ Context producers □ Context consumers ▪Sensors Authentication • Sensor registration in IdM applications • Each sensor has its own account □ Token creation and validation
- 28. IoT Authentication 28 Context Broker Account OK + user info (roles) Context Producer / Consumer access-token update / query Token creation
- 29. IoT Sensors in FIWARE Account
- 30. Security GEs ▪ Identity Management – Keyrock ▪ Authorization PDP – AuthZForce ▪ PEP Proxy - Wilma
- 31. Security GEs – IdM - KeyRock ▪ Keystone + Horizon +Extensions ▪ APIs • OAuth2 • Keystone v3 • SCIM 2.0 ▪ Source Code • https://github.com/ging/fi-ware-idm ▪ Documentation • http://catalogue.fiware.org/enablers/identity-management-keyrock ▪ FIWARE OAuth2 Demo: • https://github.com/ging/oauth2-example-client 31
- 32. Security GEs – PEP Proxy - Wilma ▪ Policy Enforcement Point ▪ Compatible with OAuth2 and Keystone tokens ▪ Source code: • https://github.com/ging/fi-ware-pep-proxy ▪ Documentation • http://catalogue.fiware.org/enablers/pep-proxy-wilma ▪ Global instance 32
- 33. Security GEs – Authorization PDP – AuthZForce (1/2) ▪ Single Open Spec (Authorization PDP GE) & Open Source implementation (GEri Authzforce) of 100% XACML-3.0 standard- compliant and cloud-ready RESTful ABAC framework with XML optimization ▪ Multi-tenant REST API for PDP(s)/PAP(s) ▪ Standards: • OASIS: XACML 3.0 + Profiles (REST, RBAC, Multiple Decision) • ISO: Fast Infoset ▪ Extensible: attribute providers (PIP), functions, etc. ▪ PDP clustering 33 By 2020, the majority of enterprises will use ABAC as the dominant mechanism to protect critical assets, up from less than five percent today. (Gartner, 2013) IBAC ABAC RBAC
- 34. Security GEs – Authorization PDP – AuthZForce (2/2) ▪ FIWARE catalogue: https://catalogue.fiware.org/enablers/authorization-pdp-authzforce ▪ FIWARE Lab image: authzforce-5.4.1 ▪ Authorization PDP GE’s APIary: http://docs.authorizationpdp.apiary.io/# ▪ AuthzForce (GEri) source code: • API spec in WADL: https://github.com/authzforce/rest-api-model • Implementation: https://github.com/authzforce/server/ ▪ AuthzForce distribution • Ubuntu/Debian-like: .deb / others: .tar.gz on Maven Central: http://central.maven.org/maven2/org/ow2/authzforce/authzforce-ce-server-dist/ • Docker: https://hub.docker.com/r/fiware/authzforce-ce-server/ ▪ Global instance for testing: https://az.lab.fiware.org/authzforce-ce/ ▪ Documentation: http://catalogue.fi-ware.org/enablers/access-control-tha-implementation/documentation 34
- 35. Thank you! http://fiware.org Follow @FIWARE on Twitter
- 36. RBAC vs. ABAC ▪ Role explosion example: • Roles in a bank: Teller, Supervisor, Branch director • Many bank agencies: Paris, London, Berlin • What about Teller in Paris, Teller in London, Teller in Berlin, Supervisor in Paris, Supervisor in London…? → 9 roles! ▪ RBAC ☹ / ABAC ☺: Doctor-patient and patient-record relationships • Doctor may only access medical records of his/her own patients If resource.type = ‘MEDICAL_RECORD’ AND action.id in {‘read’,’write’} AND user.id = medical_record.doctor_id, then Permit • A patient may only access medical records about him/herself If resource.type = ‘MEDICAL_RECORD’ AND action.id =‘read’ AND user.id = medical_record.patient_id, then Permit ▪ RBAC ☹ / ABAC ☺: Dynamic separation of duties • User may approve purchase order only if not assigned to him/herself (approver ≠ assignee) • ABAC-style (deny unless permit): If resource.type = ‘PURCHASE_ORDER’ AND action.id = ‘approve’ AND user.id ≠ purchase_order.assignee, then Permit
- 38. XACML Request XACML Request …. Category subject Category x Attribute Y Attribute Type (string, date, integer, …) Category resource Category action Attribute Y Attribute Value (romain, 1970-01-01, …) Attribute ID (subject-id, subject-role, …) Category n
- 39. XACML v3.0 vs. v2.0: upgrade! ▪ More advanced and flexible Target matching capabilities ▪ Custom attribute categories (limited to Resource, Action, Environment and a few Subject categories in v2.0) ▪ Dynamic Obligations using variables evaluated at runtime (limited to static values in v2.0) from request context after possible transformations by XACML functions ▪ Obligations in Rules (limited to Policies and PolicySets in v2.0)