set-up of the testbed for authentication, authorization ... · access management federations in the...

www.jrc.ec.europa.eu

Serving society Stimulating innovation Supporting legislation

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

AAA Workshop, 17 March 2014 Andreas Matheus

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

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 Federation” 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

Proposed Approach •  Establish an Access Management Federation

Source: SWITCH.ch

SWOT Analysis for OpenId Helpful to achieve the objective

Harmful to achieve the objective

Inte

rnal

origi

n Strengths

•  Simple Single-Sign-On 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

Exte

rnal

origi

n Opportunities •  Simple to integrate into

Web-based offering •  Self-organized (open)

user registration

Threats •  Phishing •  Spoof of attributes, e.g. email

address •  Not a standard of an accredited

standardization body

SWOT Analysis for SAML Helpful to achieve the objective

Harmful to achieve the objective

Inte

rnal

origi

n Strengths

•  Model trust between participating parties using SAML metadata

•  Single-Sign-On •  Scalability

Weaknesses •  Complexity of the SAML

protocol

Exte

rnal

origi

n Opportunities •  Flexible to support

solutions in different environments

Threats •  Single-Logout •  Missing user education that

Single-Sign-On is in place and its implications

Access Management Federations in the Academia based on SAML •  Map of productive and pilot federations in the academia

Source: refdes.org

Access Management Federations in the Academia based on SAML •  List of productive federations in the academia (selection)

Source: https://www.aai.dfn.de/en/links/

Access Management Federations in the Academia – Resume for ARE3NA and AAA •  AAA architecture concept identical to Access Management

Federation 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

Access Management – Simplistic Example •  Max (JRC) wants to access protected resource at (GDI-DE)

Service Provider (GDI-DE)

Identity Provider (JRC)

Policy

Give me

resource X

Please authen3cate subject („Max“) and give me his set of a?ributes

The subject is (Max) from JRC and he has the role „EO Division Expert“ un3l „31/12/2016“

Max (JRC)

Is Max allowed to get X?

Resource X

Authentication Authorization

The Separation of Duty •  Identity Provider (authentication) is the asserting party •  Service Provider (authorization) is the relying party

Service Provider (BKG)

Identity Provider (JRC)

XACML / GeoXACML

Policy

The subject is (Max) from JRC and he has the role „EO Division Expert“ un3l „31/12/2016“

The assertions about the user (attributes) must be known and trusted

User attributes (plus other information) determine access rights

SAML assertion

SAML metadata

Trusted rela3onship between relying and asser3ng party

(Geo)XACML request / response

The Implementation Approach (Testbed) •  Security as add-on: Web Services

Testbed Federation with other

participants

SP Proxy

IdP Proxy

Organizational User Management

Organizational INSPIRE SERVICE(S) to be protected

Federation Endpoints for an IdP

Federation Endpoints for an SP

Where does this get

deployed?

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!


participants

Deployment outside the Production Network

Firewall

Organization Production Network

Testbed Network

SP Proxy

IdP Proxy




Organizational INSPIRE SERVICE(S) to be proetected


participants

Deployment inside the Production Network


SP Proxy

IdP Proxy





Firewall


participants

Deployment inside the Sandbox Network

Internal Firewall


Organization DMZ

Network

SP Proxy

IdP Proxy





External Firewall

Harvesting Use Case - Interactions

discover protected

service

interact with protected

service

Authentication @JRC

Authorization @GDI-DE

Harvesting Application

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):

–  [email protected] §  SP determines access rights for [email protected] §  SP returns

–  Map (access granted) –  Access Denied (access no authorized)

Access Management

• How can the Harvester determine it has required access rights for executing protected service @ 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 SP @ GDI-DE must consist access rights for [email protected] §  Permit := {[email protected], /service/WMS/1, getMap, Harvesting_Layer} §  Deny := {[email protected], /service/WMS/1, getMap, HighRes_Layer} §  Permit := {[email protected], /service/WMS/1, getMap, LowRes_Layer HighRes_Layer}

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 [email protected]

• Accounting / Accountability §  SP can log the user attributes (e.g. ID) with the request §  2014-03-11T10:45:32Z – sp.gdi-de.org/service/WMS/1 –

[email protected] - PERMIT §  => Implications on the definition of additional user

attributes, e.g. organization, name, role, etc.

SD (Germany)

Testbed (JRC Harvester)

Identity Provider

GDI-BY (Bavaria, Germany)

Service Provider

Identity Provider

Province of Limburg (The Netherlands)

Service Provider

Identity Provider

DOV (Belgium)

Service Provider

Identity Provider

Geosparc (Belgium)

Service Provider

JRC (EC)

Identity Provider

JRC Harvester

SD (Germany)

Testbed Optional Extension (Citizen)

Identity Provider

eID (Belgium)

eID Service

DOV (Belgium)

Identity Provider

eID (Germany)

eID Service

Service Provider

Service Provider

Service Provider

Service Provider

Citizen

Thank You

It is important, not to stop being innovative...

Secure Dimensions GmbH Holistic Geosecurity Dr. Andreas Matheus Waxensteinstr. 28 D-81377 München, Germany Email [email protected] Web www.secure-dimensions.de

set-up of the testbed for authentication, authorization ... · access management federations in the...

Documents