e-Idenity-and-e-Government_ELAK-Code-Camp-Lecture_I

i4M Lab1

ΕΛΛΑΚ Μονάδες Αριστείας (ΜΑ. ΕΛΛΑΚ)Σχολείο Ανοικτού Κώδικα ΕΛ / ΛΑΚ: e-Identity & e-Government

(Hλεκτρονική ταυτότητα στη Δημόσια Διοίκηση και Τοπική Αυτοδιοίκηση) UAegean Center of Excellence (CoE) – Open Source Software in Transport

and Shipping

University of the Aegean Dpt of Financial and Management Engineering & Dpt of Shipping and Transportation Services

Session: I

Stelios Lelis , i4M Lab, UAegeanHarris Papadakis, i4M Lab, UAegean

@ i-nformation M-anagement Labi4M Lab

i4M Lab

Ταυτότητα Σεμιναρίου

Το Πανεπιστήμιο Αιγαίου, στα πλαίσια του έργου Μονάδες Αριστείας Ελεύθερου Λογισμικού / Λογισμικού Ανοικτού Κώδικα (ΕΛ/ΛΑΚ)1, διοργανώνει Σχολείο Ανοικτού Κώδικα ΕΛ / ΛΑΚ με θέμα «e-Identity & e-Government (Hλεκτρονική ταυτότητα στη Δημόσια Διοίκηση και Τοπική Αυτοδιοίκηση)».

1 Το υποέργο Μονάδες Αριστείας ΕΛ/ΛΑΚ υλοποιείται στο πλαίσιο του έργου «Ηλεκτρονικές Υπηρεσίες για την Ανάπτυξη και Διάδοση του Ανοιχτού Λογισμικού» του Προγράμματος «Ψηφιακή Σύγκλιση». Το έργο συγχρηματοδοτείται από το ΕΤΠΑ.

2

i4M Lab

Σήμερα 03.11.2015

3

Introductory session: Electronic Identity: Organization and Fundamentals, STORK2.0, Interconnection Supporting Service

16:00 - 20:00 4 ώρες Στέλιος ΛέληςΧαράλαμπος Παπαδάκης

i4M Lab

Online tools και άλλα

Πολλά, θα σας ενημερώσουμε προοδευτικά Τώρα, η βασική αναφορά για την ύλη του μαθήματος

https://openeclass.aegean.gr/courses/OPENSOURCE102/ ... Και στην επικοινωνία

seminar e-mailing list: [email protected]

Ομάδα διδασκαλίας και συντονισμού Στέλιος Λέλης Χάρης Παπαδάκης Πέτρος Καβάσαλης

4

i4M Lab

INTRODUCTORY SESSION: ELECTRONIC IDENTITY: ORGANIZATION AND FUNDAMENTALS, STORK2.0, INTERCONNECTION SUPPORTING SERVICE

Session I

5

i4M Lab

Session I: agenda

Electronic Government – Electronic Identity: Organization and Fundamentals

STORK2.0

Interconnection Supporting Service

6

i4M Lab

Session I: agenda


STORK2.0


7

i4M Lab

e-Government

8

i4M Lab

electronic Identity

electronic Identity an “Electronic identity” is a means for people to prove electronically that they are who

they say they are and thus gain access to services. The identity allows an entity (citizen, business, administration) to be distinguished from any other.

It is the representation of an entity (or group of entities) in the form of one or more information elements which allow the entity(s) to be uniquely recognized within a context to the extent that is necessary (for the relevant applications).

a person’s (digital) identity comprises a set of attributes, and only a subset of these attributes are necessary to allow the person to be sufficiently recognized within a given context.

examples TaxisNet, University account, Facebook account, Google account

9

i4M Lab

needs and motives

Citizens and businesses need to have an electronic presence protected from abuse and misuse confirming unequivocally who they are in electronic transactions with different forms according to their wishes

o e.g. in certain circumstances, a person might wish to present himself as the CEO of a company and in a separate context as the beneficiary of a health insurance.

They need to have available descriptions of themselves. a citizen filling in an online administrative form, a business offering a service

or preparing a tender, or an administration wishing to share information… should all be able to dispense with the time wasting and cost involved in

forever answering the same questions in ever more forms the corresponding data should be trusted and considered authentic

10

i4M Lab

main benefits

Supporting e-services Improving security in terms of accountability Generating economies of scale Increasing administrative efficiency and reducing costs Reducing the burden when engaging with the administration Limiting possibilities for fraud, identity theft and phishing Supporting mutual recognition of documents and certificates in cross-

sector and cross-border situations.

11

i4M Lab

concerns

Costs and Benefits Interoperability Privacy

12

i4M Lab

identity management systems

Identity Management The whole process of managing of users identity information

Identity Management Systems A set of functions and capabilities (e.g. administration, management and

maintenance, discovery, communication exchanges, correlation and binding, policy enforcement, authentication and assertions) used for:

o assurance of identity information (e.g., identifiers, credentials, attributes);o assurance of the identity of an entity (e.g., users/subscribers, groups, user

devices, organizations, network and service providers, network elements and objects, and virtual objects)

o enabling business and security applications.

13

i4M Lab

separating identity and service provider

Identity Provider (IdP) Responsible for (a) providing identifiers for users looking to interact with a

system, and (b) asserting to such a system that such an identifier presented by a user is known to the provider, and (c) possibly providing other information about the user that is known to the provider

14

i4M Lab

advantages of having separate IdPs

For the service providers (SP): They can focus on products and services, not on identity management A higher number of potential users. Users are demanding federated services. No more sign-in processes.

For the identity providers (IdP): They are becoming key entities on the Internet They can specialize on providing several authentication mechanisms and

privacy policies They obtain a lot of information about user activities and user profiles.

15

i4M Lab

adding attribute providers

Attribute Provider (AP) Responsible for (a) providing identity information for users looking to interact

with a system, and (b) asserting to such a system that such information presented by a user is known to the provider

16

i4M Lab

need to federate identity

How many different user accounts do you have? University, Enterprise, Google, Facebook, Twitter, LinkedIn…

How many different passwords? This is a usual “sign in” process:

You choose a username, a password and provide additional data The account is activated through clicking on a link received by mail

Now you can access to the service providing your credentials Repeat these steps for all the services you want to be part of.

There is a need to federate and to manage the identity

17

i4M Lab

identity federations

An identity federation is a collection of organizations that agree to interoperate under a certain rule set.

The rule set typically consists of legal frameworks, policies and technical profiles and standards. It provides the necessary trust and security to exchange identity information to access services within the federation

Supported by a set of technologies and processes that let computer systems dynamically distribute identity information and delegate identity tasks across security domains.

Users are distributed among several identity management systems There are different IdPs and APs The existing IdPs and APs can be based on different technologies internally,

but they must agree on a common language for external communication

18

i4M Lab

an example identity federation

19

i4M Lab

organization and function

20

i4M Lab

organization and function II

8 different steps:1. The resource is requested to the SP2. User is redirected to the SSO service3. User is authenticated by the IdP at the SSO Service4. Response containing the Authentication Statement5. The response is forwarded to the assertion consumer service6. Once the assertions are verified the user is redirected7. New request to the SP including authorization assertions8. The user obtains the requested service

21

i4M Lab

a practical example

Shibolleth Shibboleth is among the world's most widely deployed federated

identity solutions, connecting users to applications both within and between organizations. Every software component of the Shibboleth system is free and open source.

https://shibboleth.net/ Accessing content on Springer web site with a University Account…

http://link.springer.com/chapter/10.1007/3-540-45636-8_4

22

https://shibboleth.net/

i4M Lab

Session I: agenda


STORK2.0


23

i4M Lab

Ηλεκτρονική Ταυτοποίηση Βασισμένη σε Χαρακτηριστικά

24

Πολίτης, Εκπρόσωπος

Εξουσιοδοτήσεις (πχ. Εταιρίας)

Ρόλος (πχ. Δικηγόρος, Ιατρός)

ΑΦΜ, ΑΜΚΑ

Οντότητες Στοιχείο Ταυτοποίησης

Αναγνωριστικά

Ημερομηνία Γέννησης

Επώνυμο

Όνομα

Αναγνωριστικός Αριθμός

Ιδιότητες, Χαρακτηριστικά

Ακαδημαϊκοί Τίτλοι

Βασικά Χαρακτηριστικά

i4M Lab

Ηλεκτρονική Ταυτοποίηση (Διαδικασίες)

25

Πολίτης, Εκπρόσωπος

ΠάροχοςΥπηρεσιών

Διαδικασίες

Πάροχος Ταυτοποίησης

Αυθεντικοποίηση

Μεταφορά Χαρακτηριστικών

Ψηφιακή Υπογραφή

ΑΣΦΑΛΗΣ ΕΠΙΚΟΙΝΩΝΙΑ ΣΕ ΕΜΠΙΣΤΟ ΠΕΡΙΒΑΛΛΟΝ

i4M Lab

Ηλεκτρονική Ταυτοποίηση (Εμπλεκόμενα Μέρη)

26

Πολίτης, Εκπρόσωπος, Φοιτητής κα.

Οντότητες Πάροχος Ταυτότητας

Πάροχοι Ιδιοτήτων, Χαρακτηριστικών (AP)

ΕΡΜΗΣEu eIDs

ΓΓΠΣ (αναμ) ΕΔΕΤ (αναμ)

i4M Lab

LoA eIDAS

27

Assurance level Elements needed

Low - The electronic identification means shall utilise at least one authentication factor. - The electronic identification means shall be designed so that it can be assumed to be used only if under the control of the subject to whom it belongs.

Substantial - The electronic identification means shall utilise at least two authentication factors from different authentication factor categories.- The electronic identification means shall be designed so that it can reasonably be assumed to be used only if under the control of the subject to whom it belongs.

High - The electronic identification means shall utilise at least two authentication factors from different authentication factor categories and protect the electronic identification means against duplication and tampering.- The electronic identification means shall be designed so that it can be reliably protected by the subject to whom it belongs against use by others.

Electronic identification means characteristics and designCommission Implementing Regulation (EU) 2015/1502

i4M Lab

Επίπεδα Διασφάλισης Ποιότητας Ηλεκτρονικής Ταυτοποίησης (eidas QAA)

28

STORK QAA eIDAS Assurance level

Elements needed

2 Low Χαμηλή αξιοπιστία (πχ. username/password – one authentication factor )

3 Substantial Σημαντική αξιοπιστία (πχ. ψηφιακά πιστοποιητικά - two authentication factors )

4 High Υψηλή αξιοπιστία (πχ. έξυπνες κάρτες/usb token – i.e. dynamic two authentication factor )

i4M Lab

Παροχή Ηλεκτρονικής Υπηρεσίας

29


Εξου/τηση

Πάροχος Υπηρεσιών

Πάροχος Αυθεντικοποίησης

Ρόλος

Ακαδημαϊκοί Τίτλοι

Πάροχοι Χαρακτηριστικών /

Ιδιοτήτων

i4M Lab

eIDAS – STORK interoperability framework Commission Implementing Regulation (EU) 2015/1501

30

PEPS MS A

PEPS MS B


Εκπρόσωπος

mandate



Πάροχος Χαρ/στικών

Πάροχος Χαρ/στικών

i4M Lab

Χώρες συνδεμένες στο STORK2.0

31

Austria BelguimCzech RepublicEstonia FranceGreeceIcelandItalylithuania

luxembourgNetherlandsSloveniaEnglandTurkeySlovakia PortugalSwedenSchweizlandSpain

i4M Lab

Κύκλος Εμπιστοσύνης

Κάθε PEPS διαχειρίζεται αρχεία καταγραφής java keystore

Δημιουργία σχέσεων εμπιστοσύνης με τρίτους συμπεριλαμβάνοντας τα πιστοποιητικά τους (ή και τα πιστοποιητικά της αντίστοιχης Αρχής Πιστοποίησης (CA authority)) στο δικό τους αρχείο keystore

Κάθε PEPS διαχειρίζεται τρία τέτοια αρχεία keystore δύο εκ των οποίων επικεντρώνονται στην υλοποίηση του κύκλου εμπιστοσύνης ενώ το τρίτο χρησιμοποιείται για την αποθήκευση κρυπτογραφικού υλικού

32

i4M Lab

STORK packages

PEPS / VIDP SAML engine Signature & DTL Anonymity Version Control

MS package SP package AP package

33

i4M Lab

STORK functionality

StdIDP -standard authentication AUB - authentication on behalf of PV- Powers Validation VIDP - Virtual IDP (for

authentication of Austrian citizens in portals from other MS)

XHTMLSign - for authentication of users in Austrian Portals

VC - Version Control Anonimity (for eAcademia pilot) DocSign - Digital signature of pdf

documents (indicate the solution chosen)

DTL - Document Transport Layer DomSpecAtt - Domain Specific

Attributes (eAcademia Pilot) Data aggregation/ multiples

values

34

i4M Lab

eID - Data model (not extented)

35

i4M Lab

eID - Data model Description

36

Field Type Values and comments

eIdentifier StringNC/NC/xxxxxxxxx… NC=NationalityCode, the first one the country of the eIdentifier, the second one the destination country.

givenName String surname String inheritedFamilyName / adoptedFamilyNameinheritatedFamilyName String adoptedFamilyName String gender String(1) F (Female) / M (Male)nationalityCode String(2) ISO 3166-1 alpha-2

maritalStatus String(1)S (Single) / M (Married) / P (Separated)

D (Divorced) / W (Widowed)dateOfBirth Date (basic format of ISO 8601) YYYYMMDD / YYYYMM / YYYY

countryCodeOfBirth String(4)

ISO 3166-3. Please note that this code is equal to ISO3166-1 alpha-2 in the majority of countries, but includes 4 letter abbreviations for disappeared countries. E.g. DDDE for the DDR or YGCS for Yugoslavia.

……

i4M Lab

Academic Attributes

37

i4M Lab

Legal Person Attributes & e-Mandate

38

i4M Lab

Timeline

39

Timeline

Workshop agreement

17-07-15

1st eIDAScompliantCEF eID version

18-09-15

STORK ends

30-09-15

eIDASMW

Adapter

01-12-15

eIDASProxy

Adapter

01-03-16

eSENSends

30-03-16

STORK 2.0 Governance

& Maintenance

handover

State of play(Organisation and name)

1

2

STORK 2.0 knowledge

transfer

3

Dissemination plan

4

Press release future of

STORK 2.0

6

eIDAS MW adapter

7

STORK 1.0 phase out

Define technical solution

STORK 2.0 features analysis and prioritisation

9

Press release future of eSENS

eIDAS technically compliant version go live

8

Knowledge transfer

13

5

18-09-18

MandatoryeID

recognition

eIDAS node with STORK 2.0 features

eIDAS node with other features

12

14 15

10

CEF eID packaged

16

eIDAS proxy adapter

11

i4M Lab

Ελληνικό Δίκτυο STORK 2.0

40

STORK 2.0

ΓΕΜΗ ΑΙΓΑΙΟΥ ΕΡΜΗΣ

ΕΔΕΤ

WorldBridge

NBG

eProcurement

ΔΟΑΤΑΠ

ΓΕΕΘΑ

ΑΣΕΠ

Αρχαιολογικό Κτηματολόγιο

Παρατηρητήριο Η/Μ

Ακτινοβολιών

i4M Lab

Session I: agenda


STORK2.0


41

i4M Lab

The STORK 2.0 Interconnection Supporting Service

STORK 2.0 Supporting Service (SS) is a middle man between the STORK 2.0 system and any Domain Application does not want to implement the STORK 2.0 protocol.

Essentially it translates STORK 2.0 requests back and forth into any other protocol used by the DA.

STORK2.0 is free / open source available at JoinUp https://joinup.ec.europa.eu/node/137745

i4M Lab

The STORK 2.0 Interconnection Supporting Service

Up to date, SS provides support for Json-based and Web Service based communication with DAs

Its modular design makes it easy to add support for other protocols-methods.

i4M Lab

JSON vs. STORK2.0 SAML - Request

Json STORK2.0 SAML

… x 3 pages

i4M Lab

WebService vs STORK2.0 SAML - RequestSTORK2.0 SAML

i4M Lab

WebService support - Response

i4M Lab

Supporting Service Architecture

The following diagram illustrates how the Supporting Service handles all STORK 2.0 complexity

i4M Lab

Supporting Service Architecture

Authentication process flow diagrams using the Supporting Service

i4M Lab

Supporting Service configuration

The Supporting Service is a Java EE Web Application. It has been tested in Tomcat 7.0 and can be co-hosted with the Service Provider or in a separate server.

All the configuration information is available in the file: sp.properties. There are a number of options to set:

The list of available C-PEPS for the Supporting Service (country.number with the number of known C-PEPS and for each country: country<X>.name, country<X>.url)

Configuration information to identify the Supporting Service as a STORK2.0 service provider (provider.name, sp.sector, sp.aplication, sp.country).

The QAA that the Service Provider is accepting (sp.qaalevel). Finally, the URLs to communicate with all the required modules:

o speps.url: The URL where the S-PEPS is running.o sp.return: The URL to return to this SP when STORK finishes the identification and attribute

gathering.o ds.url: The URL of the Service Provider API to retrieve the requested Attribute List.o ss.url: The URL of the Service Provider API to send the gathered Attribute Values.o sr.url: The URL to redirect the user once the Supporting Service has completed its task.

i4M Lab

STORK 2.0 PHP API for the Supporting Service

The PHP API includes the following files: database.sql for creating the two tables required by the PHP API index.html to demonstrate how a web site will utilize the PHP API private.php to demonstrate how a private page works (in our example

we just check that the user has a valid session and the $_SESSION["user_logged"] variable is set).

stork2-common.php contains functions shared among the scripts. For example how to generate a random token and how to open a database connection.

stork2-config.php is the file included by all scripts. It contains all the configuration information and additional includes that are required.

i4M Lab

STORK 2.0 PHP API for the Supporting ServiceRequest

stork2-request.php creates a new token, stores the attributes to request in the database and redirects the user to the STORK 2.0 Supporting Service.

stork2-attributes.php provides a JSON output of the Attribute List. Accesed by the Supporting Service to retrieve the requested Attribute List.

i4M Lab

STORK 2.0 PHP API for the Supporting ServiceReply

stork2-values.php is accessed by STORK2.0 to decodes the JSON object that contains the response and stores the values in the database.

stork2-login.php will check the credentials provided by STORK2.0 and redirect the user to the private section of the service provider or to an error page accordingly.

i4M Lab

STORK 2.0 PHP API for the Supporting Service

stork2-specific.php is the file that contains the functions to be implemented by the service provider in order to define its specific functionality. The functions are:

get_attribute_list that returns an array with the attributes to be requested (name and if it is required).

assign_user_roles that receives an array of attributes with their values. It must process this array, start a session and set the proper session variables. Then if everything was OK it must return TRUE and if NOT it must return FALSE. For example return FALSE if a required attribute contains no value.

authenticate_supporting_service is used to authenticate API calls from the Supporting Service. The two API calls are stork2-attributes.php and stork2-values.php. Since the service provider and the Supporting Service will be running on the same network we assume that the communication channel with them can be trusted (if not we can apply VPN). So a plain username/password authentication is sufficient. But more authentication methods can be supported if required (ie. Certificate based authentication).

i4M Lab

Extending the Supporting Service

The SS has a modular design and care has been taken in order to be easily adapted to specific DA needs. If a DA requires a specific communication protocol (for example Web Services) then we only need to extend the following two classes:

1. RetrievePersonalAttributeList, in order to retrieve the Attribute List from the DA2. SavePersonalAttributeList, in order to save the Attribute Values to the DA.

The RetrievePersonalAttributeList has only one abstract method that need to be implemented for the DA specific functionality. The signature of the method is:protected IPersonalAttributeList retrievePersonalAttributeList(String token)

For the storage of the Attribute Values the SavePersonalAttributeList class must be extended that contains only one abstract method: savePersonalAttributeList. The signature of the method is:protected String savePersonalAttributeList(String token, IPersonalAttributeList pal)

i4M Lab

The STORK2.0 Attribute Provider

The STORK2.0 Attribute Provider (AP) is the system providing Attribute Information

APs come from different domains (e.g. Academic, Business, Health) and provide associated attributes (e.g. Academic AP provides ‘isStudent’, ‘hasDegree’ etc.)

Multiple APs are connecting to the STORK2.0 infrastructure through the PEPSes

i4M Lab

The Demo AP

STORK2.0 provides a free/open source DemoAP DemoAP allows organizations to quickly deploy their own APs There are more than 20 APs in several European Countries based on the

DemoAP DemoAP – STORK2.0 Communication

STORK2.0 SAML protocol An Interconnection Supporting Service for APs?

i4M Lab

Example AP – University of the Aegean

An adaptation of DemoAP Deploys both

Identity Linking with Shared Identifiers (for quick attribute retrieval) Connection with UAegean LDAP

Retrieves Attribute Information from several Systems of the University (Data Bases)

i4M Lab

Thank You

Λέλης Στέλιος Χάρης Παπαδάκης

Αύριο, 04 Νοεμβρίου 2015 @ 16:00 «STORK2.0 Interconnection Supporting Service Architecture, Aplication

Protocol Interfaces, hands-on experience»

58

e-Idenity-and-e-Government_ELAK-Code-Camp-Lecture_I

Government & Nonprofit

Transcript of e-Idenity-and-e-Government_ELAK-Code-Camp-Lecture_I