IdM in Smart Applications on Virtual Infrastructure


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

IdM in Smart Applications on Virtual Infrastructure

  1. 1. Identity ManagerSmart Applications on VirtualInfrastructurePresenter: M. Faraji
  2. 2. Agenda• Introduction• SAVI Identity Manager• Keystone in SAVI• Goals and Contributions• Authorization • RBAC • ABAC• Federation • Authentication • Authorization
  3. 3. SAVI Clearinghouse• Clearinghouse is a system that brokers trust between C&M plane and resources. It is the only component that every entity in SAVI TB fully trusts.• Components • AAA (Authentication, Authorization, Accounting) • Intrusion Detection network • Incident Handling
  4. 4. Identity Manager Tasks• Identity establishment: Distinguishes users• Authentication: verifies identity claim• Authorization: permits user’s request• Accounting: keeps track of usage• Federation: extends resources• Complementary duties • Service Catalog: lists available services • Service Discovery: keeps up with the latest changes
  5. 5. SAVI TB Architecture
  6. 6. Openstack Overview
  7. 7. Keystone• Keystone is the identity Manager in Openstack• It is written in Python
  8. 8. How Keystone works withothers
  9. 9. Keystone work flow
  10. 10. SAVI needs Central Keystone REST REST REST REST GraphDB (neo4j) Glance-reg Keystone SAVI TB Monitoring & C&M Resource Measurement Image Service AAAFramework Registry Registry Registry services services REST RESTREST REST SOAP REST REST SOAP REST REST M&M M&M nova, Ryu cheetah whale nova, Ryu cheetah whale (OMF) (OMF) swift, swift, glance glance Network VANI Resource Network VANI Resource OpenStack Manager Enhanced Configuration OpenStack Manager Enhanced Configuration Edge NodeCloud Computing Edge Node Other SAVI Core Node Cloud Computing Resources Network Resources Resources
  11. 11. Keystone (January 2011)• Password Authentication• Token Validation• Simple rule based Access control• Middleware to Openstack components
  12. 12. Token Request Authenticated Request for Service Verification Verified Response from the service
  13. 13. Middleware Auth Token EC2 TokenRequest for SWIFT Keystone Cons • Need network to verify • Keystone becomes chockpoint • Is UUID Random Request
  14. 14. How original Keystone meets SAVIrequirements• Authentication + Password-based • Strong authentication• Authorization + Simple Match (either admin or not) • RBAC • ABAC• Accounting• Service Discovery + Simple Service Catalog • Service Information• Service Registry• Federation (OAUTH, OpenID, SAML)
  15. 15. Goals1. Integration of Keystone with SAVI TB C&M (VANI)2. Deploying Central Keystone3. Implementing fine-grained access control4. Federation with other testbeds
  16. 16. Goal (1): SAVI C&M Integration• Writing middleware to connect SAVI control service to Keystone (Wilson Project)• Writing Client library to enable user to use keystone as identity provider (Griffin Project)
  17. 17. Wilson• A java middleware that connect SAVI in-house developed components to Keystone (cheetah, HW) SAVI Control Service Wilson Keystone (Cheetah)• Now, Cheetah does authorization and authentication through Wilson•
  18. 18. Griffin• Clients can use Griffin to use Keystone as IdM if it is Java•• Tasks: • Authentication & Authorization • TenantManagement • User Management • Service Management
  19. 19. SAVI Control Service Wilson Keystone (Cheetah) Griffin Application or User
  20. 20. Goal (2): Central Keystone• Clean up Keystone source code• Implementing Central Keystone ( devstack Project)• Adding concept of domain to Keystone• Restructure role API calls to be specific to (user, project) or (user, domain)• Offline Token validation• Generalized credentials associated with a user/project combo (ec2, pki, ssh keys, etc)• Bidirectional Authentication
  21. 21. Domain• A group of project• Domains are administratively independent• User can have role in domain or project• Each domain has its own intrusion detection mechanism
  22. 22. Offline Token verfication• PKIS signed Tokens• Cryptographically signed Text • Crypto Message Syntax (SMIME) • Content of “Verify” • Signed with Keystone Private Key • Verified using • Openssl • Public certificate • Can also be verified using HTTP
  23. 23. Token verification Online Verification Offline Verification
  24. 24. Goal (3): Fine-grained AccessControl Empty Role Capability RBAC Constraint RBAC ABAC
  25. 25. Empty Role Service Admin Keystone Action 1 Action 2 Action 3 User
  26. 26. Constraint RBAC Admin User Keystone Capability User Action 1 Action 2 Action 3
  27. 27. Capability Grammar Resource: Action:[Policy] • Compute • Get resource • Rule • Object-store • Release resource • rule:admin_rule • Quantum • etc • Role • Identity • role:admin • Glance • General • Control • project_id: %(project_id) • HW • Combination • EC2
  28. 28. Capability example"admin_required": [["role:admin"], ["is_admin:1"]],"identity:get_service": [["rule:admin_required"]],"identity:list_services": [["rule:admin_required"]],"identity:get_endpoint": [["rule:admin_required"]],“compute:create”: [["rule:admin_required"]],“compute:create:attach_network”: [["rule:admin_required"]],“compute_extension:admin_actions:resetNetwork”: [["rule:admin_required"]],“network:get_all_networks”: [["rule:admin_required"]],“network:allocate_for_instance”: [["rule:admin_required"]],
  29. 29. Constraint RBAC• Resources are different• A user may have access to a resource id but not others although they have same type• Actions may be limited• Admins can write stored procedures
  30. 30. Attribute Based Access Control(ABAC) – Attributes Defined• Subject Attributes • Related to a subject (e.g. user, application, process) that defines the identity and characteristics of the subject • E.g. identifier, name, job title, role• Resource Attributes • Associated with a resource (web service, system function, or data) • E.g. Dublin Core metadata elements• Environment Attributes • Describes the operational, technical, or situational environment or context in which the information access occurs • E.g. current date time, current threat level, network security classification
  31. 31. ABAC Policy Formulation1. S, R, and E are subjects, resources, and environments, respectively;2. SAk (1 k K), RAm (1 m M), and EAn (1 n N) are the pre-defined attributes for subjects, resources, and environments, respectively;3. ATTR(s), ATTR(r), and ATTR(e) are attribute assignment relations for subject s, resource r, and environment e, respectively: ATTR (s ) SA1 SA 2 ... SA K ATTR (r ) RA1 RA2 ... RAM ATTR (e) EA1 EA 2 ... EA N
  32. 32. ABAC in SAVIResearcher SA Edge Node SOAP Msg 1 3 Resources Control Service APIs Web 1 SA 2 RA Access Service Catalog Trust Anchor EA Control (Beacon)SA Policy Attribute Admin. Policy Unit Service & Policy Identity Services Provider
  33. 33. Goal (4): Federation• Aspects • Authentication • Authorization• Federation allows • Different Smart edges users to work together • SAVI serves other testbed users • SAVI researchers use other testbed
  34. 34. Authentication InteroperabilitySecurity Assertion Markup Language - SAML Policy Policy Policy Credentials Authentication Attribute Policy Decision Collector Authority Authority Point SAML Authentication Attribute Authorization Assertion Assertion Decision Assertion System Application Policy Enforcement Entity Request Point Source: OASIS SAML Standard
  35. 35. Authorization InteroperabilityeXtensible Access Control Markup Language – XACML XACML Policy Policy Serve in SAVI XML XML XML XML XACML XACML XACML XACML Federation Layer Virtualization Openflow Switch Firewall• Policy server distributes policy changes to all network elements using XACML 35
  36. 36. SAVI Federation Architecture SAVI Federation Oversight SAVI Core node Trust Anchor (Keystone) Domain Admin Service AccountingUser 1 User 2 User 3 SAVI edge (Beacon) node Repository Testbed Identity Providers   Remote  Datacenters 
  37. 37. Other components …• Clearinghouse has two more components • Intrusion Detection Network • Incident Handling module
  38. 38. Intrusion Detection Network Resource Traffic Resource Traffic Agent Agent Policy Policy data data Swarm Intelligence Brain Brain Status , Policy Situational Awareness Sergeant Human Policy GuidanceDomain
  39. 39. Incident Types• Malicious code • Disruption of service attacks • Unauthorized use /• Unauthorized access Misuse • Attempted intrusion • Infraction of Policy • Reconnaissance • Illegal activity• System compromise/ • Espionage intrusion • Hoaxes (False• Loss of, theft of or Information) missing assets, data, etc.
  40. 40. Incident Handling