Set-up of the Testbed for Authentication, Authorization, Accounting

Transcription

1 Set-up of the Testbed for Authentication, Authorization, Accounting AAA Workshop, 17 March 2014 Andreas Matheus Serving society Stimulating innovation Supporting legislation

2 Short Definition of the Term AAA AAA = Authentication, Authorization, Accounting Authentication = Means of providing proof that a claimed identity is correct Authorization = Means of verifying rights / constraints to permit / deny access to / execution of protected resources / services Accounting = Means of tracking the access to protected (network) resources / services by users

3 Goal of the AAA Project Provide comprehensive overview of standards and technologies to achieve AAA across organizations distributed over Europe Evaluate the proposed concept of an Access Management in a Testbed Involve different organizations of different European member states and their INSPIRE compliant services to demonstrate the approach Stakeholders and testbed participants to gain a better understanding of the advantages / implications of the approach for productive use

4 Proposed Approach Establish an Access Management Source: SWITCH.ch

5 SWOT Analysis for OpenId Internal origin External origin Helpful to achieve the objective Strengths Simple Single-Sign-On Opportunities Simple to integrate into Web-based offering Self-organized (open) user registration Harmful to achieve the objective Weaknesses Missing method to model trust between parties and user attributes should not be trusted Simple Single-Sign-On not always sufficient for all kinds of clients using protected services Threats Phishing Spoof of attributes, e.g. address Not a standard of an accredited standardization body

6 SWOT Analysis for SAML Internal origin External origin Helpful to achieve the objective Strengths Model trust between participating parties using SAML metadata Single-Sign-On Scalability Opportunities Flexible to support solutions in different environments Harmful to achieve the objective Weaknesses Complexity of the SAML protocol Threats Single-Logout Missing user education that Single-Sign-On is in place and its implications

7 Access Management s in the Academia based on SAML Map of productive and pilot federations in the academia Source: refdes.org

8 Access Management s in the Academia based on SAML List of productive federations in the academia (selection) Source:

9 Access Management s in the Academia Resume for ARE3NA and AAA AAA architecture concept identical to Access Management in the academia AAA: We propose to use SAML (V2) It is a main stream IT Standard (OASIS) with existing implementations Based on Open Standards and Open Source Software AAA: We propose to use XACML (V2) or GeoXACML (V1) It is a main stream IT Standard (OASIS / OGC) with existing implementations Based on Open Standards and Closed Source Software AAA: We propose to use Web Server logging capabilities SAML attributes can be trusted (because we use SAML) and be used for associating a user with a request Apache CustomLog directive can be leveraged to create use metrics

10 Access Management Simplistic Example Max (JRC) wants to access protected resource at (GDI-DE) Max (JRC) Give me resource X Resource X Please authen3cate subject ( Max ) and give me his set of a?ributes Service (GDI-DE) Policy Is Max allowed to get X? The subject is (Max) from JRC and he has the role EO Division Expert un3l 31/12/2016 Authentication Identity (JRC) Authorization

11 The Separation of Duty Identity (authentication) is the asserting party Service (authorization) is the relying party Trusted rela3onship between relying and asser3ng party SAML metadata Service (BKG) Identity (JRC) XACML / GeoXACML Policy The subject is (Max) from JRC and he has the role EO Division Expert un3l 31/12/2016 SAML assertion (Geo)XACML request / response User attributes (plus other information) determine access rights The assertions about the user (attributes) must be known and trusted

12 The Implementation Approach (Testbed) Security as add-on: Web Services Endpoints for an IdP Where does this get deployed? Organizational User Management Testbed with other participants Endpoints for an SP IdP Proxy SP Proxy Organizational INSPIRE SERVICE(S) to be protected

13 Testbed Deployment Options In the PRODUCTION Network Most realistic approach but most difficult. Is it feasible in the context of the testbed? In the SANDBOX Network Realistic implications. Does each testbed participant have that? In another Network Least realistic approach but minimum impact to production network of participating organization. Conclusions and recommendations are still meaningful!

14 Deployment outside the Production Network Endpoints for an IdP Firewall Organizational User Management Testbed with other participants Endpoints for an SP IdP Proxy SP Proxy Testbed Network Organization Production Network Organizational INSPIRE SERVICE(S) to be proetected

15 Deployment inside the Production Network Endpoints for an IdP Firewall Organizational User Management Testbed with other participants Endpoints for an SP IdP Proxy SP Proxy Organization Production Network Organizational INSPIRE SERVICE(S) to be proetected

16 Deployment inside the Sandbox Network Endpoints for an IdP External Firewall Internal Firewall Organizational User Management Testbed with other participants Endpoints for an SP IdP Proxy SP Proxy Organization DMZ Network Organization Production Network Organizational INSPIRE SERVICE(S) to be proetected

17 Harvesting Use Case - Interactions Harvesting Application discover protected service interact with protected service

18 Harvesting Use Case - Details SP (GDI-DE) and IdP (JRC) must have trust rel. Harvester must understand service metadata MD_RestrictionCode = otherrestrictions authncodelist that indicate SAML2 (e.g. ECP) Harvester must indicate when invoking service (GetCapabilities() request) to accept SAML2 ECP Results in session with SP (GDI-DE) Harvester can execute GetMap() SP receives user attributes from IdP (JRC): id=harvester@jrc.ec.europa.eu SP determines access rights for harvester@jrc.ec.europa.eu SP returns Map (access granted) Access Denied (access no authorized)

19 Access Management How can the Harvester determine it has required access rights for executing protected GDI-DE (including GetMap() operation)? SP can advertise the access rights on the protected service by hosting an (Geo)XACML policy Publically, or Protected (can be obtained by harvester after login) Policy used with GDI-DE must consist access rights for harvester@jrc.ec.europa.eu Permit := {harvester@jrc.ec.europa.eu, /service/wms/1, getmap, Harvesting_Layer} Deny := {harvester@jrc.ec.europa.eu, /service/wms/1, getmap, HighRes_Layer} Permit := {staff@gdi-de.org, /service/wms/1, getmap, LowRes_Layer HighRes_Layer}

20 The Testbed To Do Catalogue metadata for protected services Which authentication protocol is supported by the service Set of Attributes IdP (JRC, GDI-DE, etc.) must provide attribute ID Access Rights SP (GDI-DE), SP (DOV), SP (Bavaria) must include access right(s) for Accounting / Accountability SP can log the user attributes (e.g. ID) with the request T10:45:32Z sp.gdi-de.org/service/wms/1 harvester@jrc.ec.europa.eu - PERMIT => Implications on the definition of additional user attributes, e.g. organization, name, role, etc.

21 Testbed (JRC Harvester) GDI-BY (Bavaria, Germany) SD (Germany) Identity Identity Service JRC Harvester Geosparc (Belgium) DOV (Belgium) JRC (EC) Service Identity Service Province of Limburg (The Netherlands) Identity Identity Service

22 Testbed Optional Extension (Citizen) SD (Germany) eid (Germany) Service Service Citizen Identity eid Service DOV (Belgium) eid (Belgium) Service Identity eid Service Service

23 Thank You It is important, not to stop being innovative... Secure Dimensions GmbH Holistic Geosecurity Dr. Andreas Matheus Waxensteinstr. 28 D München, Germany Web