Role-based Access Control June09 GeoSOA Workshop

3,367 views

Published on

Overview of Role-based Access Control project for 2009 Geospatial SOA and Cloud Computing Workshop

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,367
On SlideShare
0
From Embeds
0
Number of Embeds
72
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Role-based Access Control June09 GeoSOA Workshop

  1. 1. Role-based Access Control Framework for Geospatial Cloud Services NSDI Cooperative Agreements Program (CAP) 2008 Best Practices in Geospatial Service Oriented Architecture (SOA) Project Contacts: Joel Schlagel, US Army Corps of Engineers, [email_address] Jeff Harrison, CubeWerx USA, [email_address] This work is 3.0
  2. 2. Topics <ul><li>Why Role-based Access Control? </li></ul><ul><li>Project Overview </li></ul><ul><li>General Scenarios (Disaster & SSO) </li></ul><ul><li>Regulatory Demos (w/John, Paul & George) </li></ul><ul><li>Best Practices </li></ul><ul><li>Questions? </li></ul>
  3. 3. Introduction <ul><li>Geospatial SOA based on OGC®/ISO influencing Federal Enterprise Architecture (FEA) Geospatial Profile. Efforts have matured to point where broad acceptance is dependent on capacity to secure data resources. Organizations like USACE participating in NSDI must also consider how to establish distributed security frameworks for role-based access control to SOA resources. </li></ul>
  4. 4. Why Role-based Access Control? <ul><li>Geospatial SOA supporting NSDI, Enterprise GIS, … </li></ul><ul><li>Moving from on-premise computing to access, discovery, processing & collaboration services on Internet cloud </li></ul><ul><li>Transforming into agile frameworks driven by collaborative partnerships </li></ul>
  5. 5. Service Providers Service Consumers Geospatial SOA … Regulatory … Infrastructure … other needs Access Processing Discovery Collaboration Security
  6. 6. Project Participants <ul><li>US Army Corps of Engineers, Water Resources Institute </li></ul><ul><li>CubeWerx USA </li></ul><ul><li>The Carbon Project </li></ul><ul><li>Collaboration with EPA, Image Matters, Montana Dept of IT, USGS Framework Data Services </li></ul>
  7. 7. Project Scope <ul><li>Design, deploy and document reusable services and applications for one of the most important (but least understood) areas of Geospatial SOA – Role-based Access Control. </li></ul><ul><li>Satisfy multi-agency requirements through modeling business processes and related service components. </li></ul><ul><li>Advance technology for regulatory data interoperability between organizations like USACE and EPA. </li></ul>
  8. 8. Project Objectives <ul><li>Define Best Practices in Geospatial SOA for Role-based Access Control as a key component of USACE and NSDI Business Process requirements. </li></ul><ul><li>Leverage CubeWerx’s investment in developing solutions to solve this important security challenge. </li></ul><ul><li>Demonstrate capabilities that have value across all application and spatial data stewardship domains, including development of Access Control Rules. </li></ul><ul><li>Collaboratively document Best Practices . </li></ul>
  9. 9. Geospatial SOA Access Security Project Design Outreach & Collaboration Scenarios & Business Processes Develop DT&E Lab Document Best Practices Services DT&E Lab
  10. 10. SDI Access Control Service NSDI Data Access Service and SDI Access Control Service WFS WMS SACS Role-based Access Control DT&E Lab WFS Request & Response Client Authentication Login Cookie WFS Response Access Control WFS Request
  11. 11. Virtual SACS Other Client SDI Access Control Service NSDI Data Access Service and SDI Access Control Service Other NSDI Service with Virtual SACS WFS WMS SAC WFS WMS SAC Role-based Access Control DT&E Lab WFS Request & Response Client Authentication Login Cookie WFS Response WFS Request & Response WFS Request Access Control Federation Fine-grained A ccess C ontr ol Rules : SDI Client : Feature Constraints Geographic Constraints Role-based Contstraints Operations Constaints Access Control
  12. 12. So what does that mean?
  13. 13. Disaster Scenario <ul><li>Texas Coast Hurricane </li></ul><ul><li>Roles </li></ul><ul><ul><li>Public User – ‘Jeff’ </li></ul></ul><ul><ul><li>EOC User – ‘Keith’ </li></ul></ul><ul><ul><li>NSDI Service Provider – ‘Edric’ </li></ul></ul><ul><li>Access Control by </li></ul><ul><ul><li>Geography </li></ul></ul><ul><ul><li>Role </li></ul></ul><ul><ul><li>Feature </li></ul></ul><ul><ul><li>Service Operation </li></ul></ul>Island of Galveston Jeff Edric Keith
  14. 14. Geographic Access Control
  15. 15. Geographic Access Control
  16. 16. Geographic Access Control Jeff
  17. 17. Geographic Access Control Jeff
  18. 18. Geographic Access Control Jeff
  19. 19. Geographic Access Control Jeff
  20. 20. Geographic Access Control Jeff
  21. 21. Geographic Access Control
  22. 22. Geographic Access Control
  23. 23. Geographic Access Control
  24. 24. EOC Users – Access by Role, Geography, Feature, Operations Public Users – May be limited by Role, Geography, Feature, Operations
  25. 25. Access Control Rules for Cloud-based Services Established by Service Providers
  26. 26. Free Secure SDI client available at www.thecarbonportal.net Feature Level Security Jeff
  27. 27. Feature Level Security Jeff
  28. 28. Feature Level Security Keith
  29. 29. Feature Level Security Keith
  30. 30. By OGC Operation
  31. 31. By OGC Operation
  32. 32. By OGC Operation
  33. 33. By OGC Operation
  34. 34. Free Secure SDI client available at www.thecarbonportal.net By OGC Operation
  35. 35. Established by Service Providers Access Control Rules for Cloud-based Services
  36. 36. NSDI WFS in DT&E Lab
  37. 37. <ul><li>International Planning Commission reviewing plans for new oil pipeline. </li></ul><ul><li>Carry crude oil from western Canada provinces to refineries in US. </li></ul><ul><li>Planning Corridor crosses Montana/Saskatchewan border. </li></ul><ul><li>Review infrastructure in Planning Corridor & rapidly develop a report. </li></ul>Single Sign-On Scenario
  38. 38. The following takes place between 10 AM and 10:15 AM… … events happen in real time. Canada US
  39. 39. Keith and Brenda are on the staff of the Commission Keith Brenda Roles
  40. 40. The commission just sent us a package by email Keith Brenda 10:00 AM
  41. 41. OK, let me zoom & connect to the Cross-Border SDI Network 10:00 AM
  42. 42. Got it, lets connect to the Cross-Border SDI Network 10:01 AM
  43. 43. Oops, forget to log-in… 10:01 AM
  44. 44. No problem, I got it, logging in now… Me too, with my account… 10:02 AM
  45. 45. OK, let me zoom & connect to the Cross-Border SDI 10:03 AM
  46. 46. Got it, Montana done… Just got a note, they want gas storage, comm towers in report 10:04 AM
  47. 47. Accessing NRCAN WFS with the single-sign on 10:04 AM
  48. 48. Canada done 10:04 AM
  49. 49. Got it, accessed Montana and NRCAN WFS, done They say add schools to report 10:05 AM
  50. 50. Done… 10:09 AM
  51. 51. NRCan Service* Montana Service* NSDI Data Services CGDI Services SACS with Single Sign-On* Geospatial SOA
  52. 52. <ul><li>Public – demonstrates unprotected access to a subset of data elements on issued permits to all </li></ul><ul><li>EPA Region II - demonstrates providing jurisdictional information on Pending Actions to EPA Region II </li></ul><ul><li>State of California - demonstrates authenticated access to consistent view of USACE data in State of California, across 3 USACE districts </li></ul><ul><li>USFWS Region IV - demonstrates providing permanent wetland impact data to USFWS Region IV </li></ul>USACE Regulatory Scenarios
  53. 53. Demos illustrate role-based access to USACE regulatory data, using four different scenarios, four roles and four demo users – one Cloud-based Service. Each user belongs to one role – Public : ‘Public’ California : ‘Paul’ EPA Region II : ‘John’ USFWS Region IV : ‘George’ (the password for each user is the same as the username) Each role's access rules demonstrates a different spatial & non-spatial filter (details for each scenario appear in the bottom panel). USACE Regulatory Demos
  54. 54. USACE Public Scenario
  55. 55. USACE - California Scenario
  56. 56. USACE-EPA Region II Scenario
  57. 57. USFWS Region IV Scenario
  58. 58. USACE - California Rules
  59. 59. USACE - California Rules
  60. 60. USACE - California Rules
  61. 61. Questions on Demos?
  62. 62. Before – Many Roles, Many Services Datastore HTTPS Username/PW WFS WMS Datastore HTTPS Username/PW WFS WMS Datastore HTTPS Username/PW WFS WMS
  63. 63. Datastore HTTPS SACS WFS WMS SDI Access Control Rules After – Many Roles, One Service
  64. 64. USACE Data Provider Portal Provider Security Manager NSDI Data Provider USACE End User NSDI End User (Public) Manage Users Manage Roles Manage Credentials Manage Groups Manage SDI Access Control Rules Authorize Users Access by Feature Access by Role Deploy Data Access by Geography Update by Feature Update by Role Update by Operation Type Access by Operation Type Use Cases… NSDI End User (Govt)
  65. 65. SDI Access Control Rules <ul><li>SACR - an XML file that defines SDI Access Control Rules. </li></ul><ul><li>SDI Access Control Service applies these rules when someone tries to access data or services under its control. </li></ul><ul><li>XACML/geoXACML is a standard for expressing access control rules in XML. </li></ul><ul><li>SACR is a simple, functional subset of XACML/geoXACML - specifically focused on the requirements of OGC SDI (WMS, WFS, WCS, GSS, CS-W, etc.). </li></ul><ul><li>May be beneficial for this type of simple Access Control Rules encodings to advance for NSDI. </li></ul>
  66. 66. User Relying Party Identity Provider Relying Party Identity Provider Security Token Service WS-SecurityPolicy Security Token Service WS-SecurityPolicy Identity Selector SDI Access Control Rules (SACR) Framework… WS-Trust, WS-MetadataExchange Kerberos SAML SACS X.509
  67. 67. Level of Maturity and Implementation <ul><li>The referenced SOA/Cloud solutions are mature and viable, suitable for deployment in a governmental computing environment – either internally or via Cloud. </li></ul><ul><li>Services, Web-based and Desktop Clients have been deployed in multiple operational settings – and are effective for Role-based Access Control. </li></ul><ul><li>Greatest challenge may not be the technical solution – </li></ul><ul><ul><li>May be identifying specific Access Control Rules in coordination with multiple stakeholders – this challenge can be overcome, it is only a matter of working collaboratively to define them. </li></ul></ul><ul><ul><li>In addition, importing and adapting Roles from existing databases takes Enterprise commitment </li></ul></ul><ul><ul><li>Education to help stakeholders realize it is not “all or nothing” </li></ul></ul>
  68. 68. Project Deliverables <ul><li>Distributed DT&E Lab </li></ul><ul><li>Working Services, candidate Schemas </li></ul><ul><li>Web-based and Desktop Clients </li></ul><ul><li>Processes and Use Cases </li></ul><ul><li>Best Practices </li></ul><ul><li>Web-based Demos for NSDI Community </li></ul>
  69. 69. Questions?
  70. 70. Role-based Access Control Framework for Geospatial Cloud Services NSDI Cooperative Agreements Program (CAP) 2008 Best Practices in Geospatial Service Oriented Architecture (SOA) Project Contacts: Joel Schlagel, US Army Corps of Engineers, [email_address] Jeff Harrison, CubeWerx USA, [email_address] This work is 3.0

×